読者です 読者をやめる 読者になる 読者になる

5.1さらうどん

@giginetの技術ブログ。ゲーム開発、iOS開発、その他いろいろ

Global Game Jam5年目ガチ勢の僕がGGJ2015に参加してきた話(事前準備編)

Global Game Jamだ!!!

今年もやってきました、48時間でゲーム開発をするイベント「Global Game Jam」の札幌会場。

今年は過去5年で初めてオーガナイザー・運営メンバーではない一般参加での参戦。

今年の札幌会場は、なんと国内最大の会場に。ありがたい。

国内最大会場、札幌 | Global Game Jam JAPAN

過去の参加録は以下を参照してみてください。

GlobalGameJam札幌で48時間でゲーム10本開発した話 - 5.1さらうどん

ソーシャルゲーム,ボードゲーム,ファミコンまで!? Global Game Jam 2014参加レポート:レポート|gihyo.jp … 技術評論社

事前準備

札幌会場の特徴として、1週間前にはチーム分けを発表し、「事前ミーティング」と称して1週間前に簡単なミーティングを持っていることです。

基本的にチーム毎に打ち合わせる内容は自由ですが、主にチームメンバーとの顔合わせや、開発環境のすりあわせを目的としています。

僕のチームは、ここで企画会議を始めてしまったらせっかくのジャムが勿体ないので、基本的に一切の企画会議は行っていません。

何度も参加しているとわかるのですが、48時間で初めてのことを挑戦するのはとても難しいので、メンバーの力を出し切るために事前の打ち合わせや準備を入念にやっておくことをオススメします。

この記事では、GGJ前にできる準備事項について、来年への備忘録も兼ねて詳しく書いてみました。

こういう記事は本番前に書けよって感じですが、来年参加する方の参考になれば幸いです。

チーム編

メンバーの確認

簡単に自己紹介とやりたいことを確認します。過去に作ったものがあればそれも共有し合いましょう。

また、以下の点について詳しく確認しておきます。

SNSアカウントの補足

SNSアカウントを事前にチェックしておき、どのような方か把握しておきます。過去の制作物があればそれもチェックしておきます。

使用環境

チームメンバーがMac/Windowsどちらで作業するかといったことを確認しましょう。

作業環境が異なる場合は、使用するソフトウェアの選別などを行う必要があります。

また、PCゲーム以外のゲームを作る場合もデバイスを所持しているかを確認しておくべきです。場合によってはチームメンバーに貸し出しを行いましょう。

ちなみに、今年の札幌会場では事前アンケートの時点で、スマートフォン開発を行うことが決まっており、所持しているデバイスなども考慮されてチーム分けがされていたので、全員がiOSを所持していました。

スキルセット

メンバーそれぞれがどれぐらいの製作経験があって、どういったことができるのか正確に把握しておくと良いと思います。 予めスキルセットを把握できていないと、実際に企画が決まってから作り出して、想定していたクォリティにならないと言うことが避けられます。

また、技術的に挑戦したいことなども事前に聞いておくと、タスクの割り振りなどに役立ちます。

プログラマ

GGJの場合は、基本的に同じゲーム開発環境が使える人同士でチームが編成されることが多いので、皆、共通のスキルを持っていることが前提です。

プログラマ同士は以下について確認しあうと良いでしょう。

  • その環境での製作経験、ポートフォリオ
  • 過去に書いたコード
  • バージョン管理への習熟度

これらを考慮してメインプログラマを決めましょう。

製作経験が極端に少ない人の場合、当日ハマることが多いので、ゲームの企画の規模は一人ででもできる分量に留めておいた方が無難です。

チームメンバーがいるからと、自分の見積もりギリギリのところで設定してしまうと大抵は上手く行きません。

グラフィッカー

グラフィッカーについては以下の点を確認しておくと良いと思います。

特に、趣味でイラスト書いてるだけ、という人の場合は、UIの作業などはできないことが多いので、その辺の認識を聞いておいても良いでしょう。

また、2Dアニメーションをゲーム中で使う場合もFlashなどで作成して組み込んだり、連番画像で組み込んだりとノウハウが違うので、製作経験も確認しておきます。

コンポーザー

チームに音を作る人がいる場合、下記の点を確認しておきます。

  • BGMが作れるか
  • 効果音が作れるか
  • ミキシングなどができるか
  • ゲーム用のオーディオツール製作経験(WWise、ADX2、Unityなど)
  • ポートフォリオ

また、例年、サウンド担当は時間が余りがちになるので、他のパートを任せられそうであれば、そういうことが可能かの確認を取っておくべきだと思います。

好きなゲーム

好きなゲームや、最近遊んだゲームをメンバー全員から簡単に聞いておくと、企画会議やチームビルディングに便利です。 実際にシステムに落とし込むときに遊んだことのないゲームはイメージしづらいので、なるべくチームメンバーがイメージを共有している題材を選びましょう。

GGJ公式サイトへの登録、チーム登録

  • GGJのアカウントを取得する
  • 会場への登録を行ってもらう
  • チームを作成して追加する

GlobalGameJamのサイトは非常に使いづらく、会場への参加登録が面倒なので、上手くできてないメンバーがいればサポートしましょう。

チームも予め作っておくと当日慌てなくてすみます。

Dropboxなど、共有ストレージの用意

  • クラウドストレージを選定する
  • アカウントを取得する。持っていないメンバーがいる場合は招待する
  • 作業用のマシンにクライアントをインストールする
  • 共有フォルダを作る
  • フォルダ構成などの運用を決める

クラウドストレージのアカウントを交換して共有フォルダを作ります。

DropboxやBox、OneDriveなどいろいろあると思いますが、僕らはDropboxを使ってます。

ゲームを作ってる人なら大抵アカウントを持ってると思いますが、もし、持っていない人がいたら忘れずに招待して容量を増やしましょう。(忘れがち)

後述のようにバージョン管理を導入する場合でも、簡単なファイルのやりとりに使ったりするので、とりあえず共有フォルダは作っておきましょう。

素材をどこにいれるか、フォルダ構成など、運用面のすりあわせもできると理想的です。

Skype, HipChatなどのコラボレーションツールの用意

  • Skypeなどのアカウントを交換する
  • 会話を作成して招待する
  • 音声通話が可能かどうかを確認する

これも開発中は必須。利用者の数的にSkypeを利用するのが良いと思います。音声通話ができるかどうかも確認しておくと、帰宅後の作業に便利です。

その他、開発に使うアカウントの取得

その他、必要に応じてアカウントを取得、交換しましょう。

僕らのチームはiOS/Androidの開発で、テストプレイに必要なため、TestFlightのアカウント取得と、デバイス登録、チーム参加なども事前に済ませておきました。

ツール類のすりあわせ

事前に使う予定のグラフィックツールなどを決めておきましょう。

例えば今回は、アニメーション作成には「SpriteStudio」、音の組み込みには「ADX2」を使うことにしました。

また、「Live2D」も使う予定があったのですが、デザイナーとの打ち合わせでなしになりました。

作業者がツールに習熟していない場合は、初心者用の資料を共有し、当日までに準備しておいてもらいます。

睡眠、帰宅スケジュール

以下の点を予め聞いておくと良いでしょう。

  • 家の位置(終電の時間)
  • 帰宅予定
  • 作業不可時間

基本的に、睡眠時間は多めに取れるようにスケジューリングすることが大事です。

可能であれば睡眠時間や、会場にいれる時間はあわせた方がスムーズに作業ができます。

本人の希望を聞いて、上手い具合に工数を見積もりましょう。

また、一人だけ無理して徹夜して、皆で作業したいときに寝ていて連携が取れない、みたいなことがGGJではよく起こりがちなので、その辺も調整しておく方が良さそうです。

読んでおくべき書籍の共有

技術書など、本番までに読んでおくべき本や資料を共有します。

特に、自分の著書がある方は「こういう方法でやるよー」というのをチームメンバーに共有するために配っておくと良いです。

今回のうちのチームでは、音屋の方にADX2の使い方本、デザイナーの方にSpriteStudioのチュートリアル動画などを共有しました。

プログラマ

ここからは、プログラマが当日までにやるべき事前準備を紹介します。

コードネームを決める

まず、プログラマにとって名前が決まらないとプロジェクトを作れなくて困るので、適当なコードネームを決めましょう。 かといって、「Team1」とか「GGJ2015」とかだと、扱いづらく、字面も悪いので、適当な英単語で付けることをオススメします。

例えば、僕は毎回アルファベット順に食べ物の名前を付けることにしました。昨年は「Oyster」で今年は「Pretzel」でした。

ここで決めた名前はゲームの企画には一切関係ないので、雑談で出てきた単語を使うなど、ゆるく設定しましょう。

リポジトリを設置する

プログラマのレベルにもよりますが、おそらくバージョン管理を使うことになると思うので、当日までにリポジトリは作っておきましょう。 今回はgitを選択しました。

GitHubやBitBucketでプロジェクトを作成し、鍵の登録や共有設定などもすませておきましょう。

また、Unityを使う場合は、GGJの場合は無償でプロライセンスが使えるので、アセットサーバーが利用できます。

エンジニア以外にバージョン管理を使ってもらう場合はGUIツールの使い方のレクチャーなども済ませておきます。

リポジトリの運用ポリシーを決める

ブランチなどを使う場合の運用ポリシーをプログラマ間で簡単に決めます。例えば今回の場合は

  • master / Deploy用。CIが走るので、キリの良いタイミングでのみdevelopに追従させる
  • develop / 開発用ブランチ。各機能をどんどんmergeしていく
  • featureブランチ / その他、機能ごとにdevelopから生やしていく

のような運用にしました。ある程度熟達したプログラマ同士の場合は以上のように運営すれば良いでしょうし、そうではない場合は混乱を招くため、ブランチを分けずに運用しても良いと思います。

ケルトンプロジェクトを作る

予め新規プロジェクトを作って、細かな設定はしておきましょう。 例えば、今回はcocos2d-xを使ったので以下のような設定をしました。

  • 新規プロジェクトを作る
  • 画面解像度を設定する
  • アプリ名や画面サイズなどアプリケーションの設定をする
  • リソースの読み込み元などを設定する

GGJはイベントの性質上、どこまで仕込みOKなのか微妙なところなのですが、個人的には「ゲームロジックに関与しない部分」というのは事前に作っておいて良いのかなあという感じがしています。

ここまで作成した空プロジェクトを予めリポジトリにコミットしておくと良いでしょう。

ビルドスクリプトの実装

当日、作業する段階になって、ある特定の人のマシンでビルドが通らない、とかはよくあることなので、開発に参加するエンジニアのマシンで最低限ビルドが通ることだけは確認しておきましょう。

Unityなどを使う場合はこの辺はハマりづらいですが、そうじゃない場合は以下の点について確認します。

  • IDEツールのバージョンを合わせる
  • iOSの場合、証明書などのインストールがちゃんとできているかを確認する
  • 必要に応じてMakefileやGradleなどのタスクも作成しておき、コマンド一発でビルドができるようにしておく
  • ビルドしたものを自動デプロイできるような環境を作っておく

ライブラリ類の選定、組み込み

外部のライブラリや、秘伝のタレ的な俺俺ライブラリを使いたい場合、予めスケルトンプロジェクトに組み込み、サンプルが実行可能かどうかをテストしておきます。

今回は前述したとおり、ADX2やSpriteStudio、CocosStudioを使うことが決まっていたので、これらのライブラリの組み込みを終わらせていました。

パッケージ管理ツールを使いたい場合も、この段階で初期設定だけは済ませておくと良いです。

CI環境やデプロイ方法を用意する

f:id:gigi-net:20150127182323j:plain

ここまでやるかはチームによると思いますが、うちのチームは、会場でビルド作業に追われなくて良いように昨年同様、ビルドサーバーも準備しておきました。

  • masterにpushするとビルドが走る
  • TestFlightやDeployGate、Dropboxで最新版がチームメンバー全員に配信される

詳しくは去年の記事を見ると良いです。

cocos2d-x 3.0でクロスプラットフォームなインディーゲームを開発した話 - 5.1さらうどん

この仕組みは用意できるなら絶対に用意しておいた方が良くて、いちいちチームメンバーがゲームで遊ぶのにプログラマが何もしなくて良いので非常に強力です。

いつも言ってることですが、ゲームのクォリティを上げるには遊びまくるしかないので、遊ぶための敷居を下げておくのが重要です。

特に最終日は、細かな変更ごとに最新のビルドが欲しくなるので、こういう仕組みを事前に用意しておくと作業効率がかなり上がります。

当日持って行くと捗るもの

付箋

f:id:gigi-net:20150123191840j:plain

企画会議の時、当日はKJ法的なブレーンストーミングを行いました。

作業が始まってからもカンバン方式のようなタスク管理に利用できるので便利だと思います。

今年はカンバン方式のタスク管理を考えていたのですが、結局マネージャー的な人を置く余裕がなく、気付いたら導入されないまま終わっていました。

カメラ

ブログ記事書くときに捗ります。同じく今年は忙しかったため全然写真を撮っていませんでした。

電源タップ

会場では全員のマシンと、場合によってはディスプレイ、スマートフォン開発の場合は検証機の充電などに電源が使われ、コンセントが足りなくなるので絶対に持って行った方が良いです。

ディスプレイ

会場で借りられる場合は良いですが、借りられない場合はディスプレイを持ち込むと作業効率が一気に数倍になるので、エンジニアは絶対にもって行った方が良いです。

最終日は懇親会などでバタバタしてる可能性があるので、帰りにどうやって持って帰ってどこに置くか、というフローも決めておくと良いでしょう。

マウス、キーボード

普段の慣れた作業環境を持ち込みましょう。

参考書籍

リファレンスとして使えそうな本を数冊スーツケースに入れて持ち込みました。ただし読んでる時間はあまりないので、何が書いてあるか覚えていて、リファレンス的に使う場合限定といった感じです。

結局一度も使わなかった本もありますが、なくて後悔するよりはもって行った方が良いです。

携帯ゲーム機

企画会議の時に他のメンバーが遊んだことのないゲームを紹介したり、逆に自分が知らないゲームを他の人から紹介されたときにすぐ遊べるように準備しておきましょう。

もちろん、全てのゲームが遊べるわけではないですが、最近のゲーム機3DS/PS Vitaなどは、ダウンロード版で大量のソフトを持ち運べるようになったり、古いゲームを買えたりするので、必要に応じて会場で購入するのもアリです。

予備の検証用端末

チームメンバーにデバイスを持っていない人がいた場合、検証用の予備端末を用意しておきましょう。手の空いてるメンバーにバグ探しや問題点の洗い出しをしてもらいたいときなど、端末は多ければ多いほどよいです。

風呂道具

GGJと言ったら風呂だ!!!

まとめ

如何でしたでしょうか?

ここまで盤石に準備しても大体当日は混乱を極めるので、準備は可能な限り入念に行っておいた方が良いです。

ここに書いた例は今年僕らのチームが行ったものを元に書いていますが、実際にどの程度行うかはチームメンバーのレベルや、モチベーションと相談してください。

来年GGJに参加する方は是非参考にしてみてください!

近々当日のレポート記事を書きます。

「cocos2d-xではじめるスマートフォンゲーム開発 」の発売と今後の展開

祝発売

『cocos2d-xではじめるスマートフォンゲーム開発』という本を出版します - 5.1さらうどん

単著でゲーム開発の技術書を執筆しての製作秘話と思ったこと - 5.1さらうどん

ありがとうございます!!!

各地からの承認の声

ありがたさしかない。今のところ反応も上々でホッとしております。

電子書籍

よく質問を頂くのですが、電子書籍版についてアナウンスしておきます。

現在、技術評論社さんの電子書籍ストアでPDF版を併売しています。

cocos2d-xではじめるスマートフォンゲーム開発 [cocos2d-x Ver.3対応] for iOS/Android | Gihyo Digital Publishing

また、年明け1月中旬をメドにAmazonKindle版、楽天ブックスKobo版、Googleブックスでも販売されるようですので、読みたい形式のものがある場合は、発売まで待つと良いと思います。

楽天ブックス: cocos2d-xではじめるスマートフォンゲーム開発 [cocos2d-x Ver.3対応] for iOS/Android - 三木康暉 - 4774170550 : 本

ちなみに、お値段は全て書籍版と同じになっております。

サポートページと今後

Android Studio対応について

Twitterでこのようなつぶやきを頂いたのですが、12月にAndroid Studioの正式版がリリースされた関係で、書籍の記述通りにAndroid環境を構築しようとすると、上手く行かないという問題が起こっています。

Google、アプリ統合開発環境「Android Studio」正式版をリリース - ITmedia Mobile

この発表があったのが、校了が完了したあとで、どうがんばっても書籍に反映できませんでした。 前回の記事でも書いたのですが、こういう突然の変更には為す術がないし、書籍の限界を感じさせられる一件です。

この点につきましては、年明けをメドにサポートページを出して、そこで対応させて頂く予定です。お手数をおかけいたしますが、ご理解をよろしくお願いします。

取り急ぎ、この年末年始に作業したい!という方は以下のURLから書籍で紹介しているものと同じものがダウンロードできます。

http://dl.google.com/android/adt/adt-bundle-windows-x86-20140702.zip
http://dl.google.com/android/adt/adt-bundle-windows-x86_64-20140702.zip
http://dl.google.com/android/adt/adt-bundle-mac-x86_64-20140702.zip
http://dl.google.com/android/adt/adt-bundle-linux-x86-20140702.zip
http://dl.google.com/android/adt/adt-bundle-linux-x86_64-20140702.zip

その他、ミスなど

既に、書籍の間違いを見つけてTwitterで呟いたり、メールでお知らせしてくれた方がいらっしゃいます。ありがとうございます。

単純な誤植やスペルミスがあったり、サブモジュールの関係でGitHubで配付しているサンプルコードのビルドが通らなかったりしているので近日修正予定です。

また、ご意見や質問大歓迎です。下記メールアドレスまでお寄せください。

giginet.net@gmail.com

まとめ

初めての経験でいろいろ戸惑っておりますが、実際に発売されて、数々の反応を頂け、非常に幸福なことだなあと思っております。ありがとうございます。

お手にとって頂けた方は、Twitterで一言呟いて頂けるだけでも非常に嬉しく思いますので、是非ともご意見をお寄せください。

単著でゲーム開発の技術書を執筆しての製作秘話と思ったこと

本出します!!!

先月告知しましたが、この度「cocos2d-xではじめるスマートフォンゲーム開発 [cocos2d-x Ver.3対応] for iOS/Android 」という本を出させて頂くことになりました!!!

『cocos2d-xではじめるスマートフォンゲーム開発』という本を出版します - 5.1さらうどん

Amazonからの発送はまだなのですが、すでに先行販売しているお店に並んでいたり、僕の手元にも見本が届きました。

本の内容については、前回の記事を見て貰うとして、今日は「技術書執筆って一体どうやって行われているの?」ということについて、突っ込んで記事にしてみたいと思います。

きっかけはゲームジャム

きっかけは、今年1月に行われた、GlobalGameJamというゲーム開発イベントの参加レポートを技術評論社さんに書かせてもらったことでした。

ソーシャルゲーム,ボードゲーム,ファミコンまで!? Global Game Jam 2014参加レポート:レポート|gihyo.jp … 技術評論社

元々、友人の紹介で上のような記事を寄稿したのですが、それが運良く目に留まり、2月ぐらいに執筆の話が来ました。 2ページ目にいろいろ開発の話を盛り込んだのが良かったようですね。きっかけは些細なモンです。

ペルソナとテーマ設定

ペルソナ:入門者って誰?

執筆を始めるにあたって非常に困ったのが、対象読者。入門書を書く予定だったけど、入門者ってどういう人なんだろう。 入門者と一口に言っても、手厳しい話だけど、全くの素人がゲームを作れるようになるのは非常に難しい

今回、扱ったcocos2d-xはC++を実装言語としているため、誰でも簡単に、というわけにはいかない。さらにゲームを一本作るには、CUIの知識とか、実際にデプロイするところまでとなると、完全な初心者にとっては覚えることが多すぎる。 同じゲーム開発でも、HSPやUnityとかと比べると遙かに取っつきづらいでしょう。

人にモノを教えることは、読者がある程度の前提知識を持っていると仮定しないとすぐにフレーム問題に陥ってしまう。変数とは何か、とか、オブジェクト指向とは何か、といったことを書き始めると、入門書を書くだけでも鈍器ができてしまう わけだし、C++の文法など、プログラミングの基礎知識はバッサリとカット。

僕は、Kawazというゲーム開発者向けのコミュニティに出入りしていて、大学の新入生や専門学校生にプログラミングに触れて貰う機会が多かったので、まずは身近なところで、そういったレベルの人でも自分でゲームを出せるぐらいの中身にしようと決めました。

この本では、「学校でプログラミングは習っているけど、自分でアプリを出したことがない」「プログラミングの心得はあるけれど、スマートフォン開発は初である」ぐらいの客層を目指しています。

また、完全に初心者向けにすると、既に使っている人が買っても面白くないので、外部ツールを盛り込みまくって浅く広くとにかく網羅性を広めようというコンセプトも最初から決まっていました。

おかげで、GUIツールの紹介なども増えて、見た目も華やかになりました。この本でしか扱っていない最新情報も盛り込めたので、誰が買っても新たな発見があると思います。

テーマ:ゲーム作りのエッセンスを伝える

f:id:gigi-net:20141104001452j:plain

スマートフォン開発の世界はドッグイヤーで、cocos2d-xでのゲーム開発を付け焼き刃で覚えても、おそらく1年以内に環境は変わるだろうし、もっというと3年後には全く使い物にならなくなっていると思います。作者の僕が言うのもおかしな話だけど、僕の本も1年後には、大分環境が変わっていて、そのまま写しても動かないと言うことが多発しそう。

せっかく苦労して本を書いても、すぐに使えなくなってしまうのは悲しいので、末永く使えるように、なるべく陳腐化しない知識をたくさん盛り込もうと考えました。

そこで、僕が中学生ぐらいの時、独学でゲームプログラミングを学ぶのに使ったサイトを思い出しました。

Flashゲーム講座&アクションスクリプトサンプル集

ここで取り上げられているのは、ActionScript1.0という、もはや完全に死に絶えた言語なんだけど、ゲームアルゴリズムとか、当たり判定の計算、フラグ管理の方法、シューティングゲーム弾幕の実装と言ったような、ゲーム開発のエッセンスが詰め込まれていて、今読んでもおもしろい。

ゲーム開発は始めるためにプログラミングスキル以外に知らなくてはいけないことが多すぎて、なかなかこういう知識を体系的に学べるようなサイトや書籍がないなあと日頃から感じていたのもあってこういった内容を盛り込んでいくことにしました。

結果的に、ステージのレベルデザインの方法や設計とデータ構造、乱数といった話など、盛り込みきれなかった話は多いけれど、ゲームアルゴリズムや、ゲームフレームワークの基本構造といった話を割としっかり書けたと思います。

GitHubフローによる執筆作業

実際の執筆は、GitHubのプライベートリポジトリを使い、Markdownで執筆、Pull Request(PR)でレビューすると言ったいわゆるGitHubフローで行っていました。

今回出版した技術評論社さんは、社内にソフトウェア開発に近いフローを使った執筆スタイルの知見が蓄積されていて、エンジニアとしては非常に仕事しやすかったです。

技評さんのGitHubを使った執筆方法については、以下の資料がわかりやすい。

こういう感じにMarkdownで書いたものが

f:id:gigi-net:20141222154520p:plain

こうなります

f:id:gigi-net:20141222154526p:plain

編集者さんによるレビューもPRで行えたので、修正も簡単。

f:id:gigi-net:20141222153722p:plain

コミットログはこんな感じ。最終的に450コミットほど。

f:id:gigi-net:20141222153356p:plain

編集者さんとのやりとりもたまにメールは交わすけれど、ほとんどはSkype。 僕は札幌に住んでいて、結局一度も編集部にお邪魔することはできなかったけれど、適切にツールを運用できれば、リモートワークでもまったく問題ありませんね。

今回、GitHubフローを導入してみて、「むしろこれを使わないでどうやって本を書くんだろう」というレベルで不可欠なことを感じました。レビューとかの度にいちいち朱入れして、PDFをメールで送ってというのはマシな方で、技術書以外だったら、未だに手書きで書いて封筒に入れて運んで、みたいなことを行っている業種もあるだろうし、もはやこれなしでの執筆は考えられない。

なんとなくの執筆スケジュール

どういうスピード感で書けばいいのか見当も付かなかったので、なるべく急いで書きました。 確か4月後半ぐらいから作業を始めて、9月ぐらいにはサンプルゲームの実装含めて一通り全て揃ってるという進捗でした。

全原稿が揃ってから、ようやっとゲラができてきて、その後に何度も読み返したり、最新情報をチェックして古い情報はその都度書き換えると言った大変な作業が続き、全原稿が終わってからの方が大変でしたね。 本当はもっと早く出る物だと思ってた。

作業は、なるべく平日の日中にやるようにして、土日はほぼ作業しなかったですが、基本的に書きたいときに書くというのが一番進みます。

Markdownの執筆方法

蛇足ですが、文章の執筆はvimで、プレビューは「Marked 2」というMac用のMarkdownビューワーを使いました。

Marked2は、1500円ぐらいして、ちょっとお高く感じられるけど、まずMarkdownのプロセッサを自前で実装できるため、GFMと全く同じような見た目でレンダリングさせることができる。

また、CLIも付属していて、全ての文章をスクリプトで一括でPDF化する、なんてことが簡単にできて、執筆には大活躍でした。

サンプルゲームとGoal Driven

Goal Driven

f:id:gigi-net:20141126181116p:plain

この本の特徴として、実際にアプリストアで配付されている3本のゲームが付属しています。

サンプルゲームを作るというのは、"Goal Driven"な学習法の考えに基づいていて、「自分が何を作るか最初に提示されないとやる気が出ない」ということ。

これから学習を始める人に気軽にダウンロードしてもらって、挙動の確認や目的意識のアップに使って頂ければ良いなあと・・・・・・。

本当は、一本のゲームとしてもちゃんと遊べるようなクォリティを目指したかったのだけど、結局サンプルゲームの域を出ない規模感になってしまいました。

元々、この話は今年4月に行われた「Unite Japan」という、Unityの技術者向けカンファレンスでUnityのエヴァンジェリストの方が話していた話。以下の資料に凄く感銘を受けたのでオススメ。

japan.unity3d.com/unite/unite2014/files/DAY2-1800-room1-Carl.pdf

サンプルゲームの開発フロー

f:id:gigi-net:20141126181101p:plain

サンプルゲームは、普段一緒にゲーム開発をしている仲間に手伝ってもらって開発できたので混乱はありませんでした。

サンプル特有の作り方として、普段と着想の方法が逆と言うこと。

普段は、他と被らない独創的なゲームを作って、世界観などを練り込み、コードの綺麗さは犠牲にして面白さを優先というフローで作るのに対し、今回は、最初に章ごとに説明したいことを決め、ゲーム性よりもコードの見通しの良さを優先し、読者が理解しやすいように、なるべく既存ゲームに似せるという作り方をしました。 そのため、どのゲームもどこかで見たことのあるような感じのゲームになってます。

いろいろな方に協力して頂いた

各種ツール類の提供

f:id:gigi-net:20141126175843p:plain

一番大きかったのは、CRI・ミドルウェアさんにADX2 LE for cocos2d-xをリリース前に提供して頂き、執筆にあたって、レビューの協力や、ADX2の質問などにも答えて頂けました。ありがたい限りです。

おかげでリリースされたばかりのライブラリの内容を紹介することができました。

初心者目線によるレビュー

本の校正作業などは、ゲームプログラミングをやってみたい初心者の学生を中心に何人かに手伝って貰いました。 ここでもGitHubが役に立って、バグがあったり、疑問点があったらissueに書き込んで貰うというスタイルを取ったことで、多くの記述ミスを潰せました。気をつけててもミスって大量に発生するんですね、という感想です。

f:id:gigi-net:20141222153230p:plain

レビュアーのレベルはかなり幅があって、自分で興味持って全て試してくれた子もいるし、環境構築で躓いてしまった子まで様々です。 協力の甲斐あって、最低レベルとして、「全く理解せずとも写せば動く」という質は到達できたとおもいます。

使ってるフレームワークとか、要求してるレベルとか、分量とか、どれも初心者には荷が重い感じだったけど、今は実際にそのうち何人かが自分のゲームを作りだし始めていてくれて、書いて良かったなあと実感できる一件でした。

やっぱり、近場の人に見て貰って反応を貰うのは何を作ってても超重要ですね。やる気も出るし。

表紙の作り方

f:id:gigi-net:20141222151952j:plain

最後に表紙。表紙を担当してくれたイラストレーターの@さんが記事を書いてくれたので、ご興味があれば是非。

Kawaz - 『cocos2d-xではじめるスマートフォンゲーム開発』表紙メイキング【KawazAdventCalendar12/19】

気をつけたこととしては、「技術書のタイトルって誰も覚えない」ということで、見た目一発でインパクトのあるデザインにしてもらいました。

参考にした物として、例えば、このUnityの技術書は凄く秀逸だと思ってて、めちゃくちゃインパクトがある。初学者にオススメするときも「ヒヨコの本」とか言って勧めやすい。

Unity4入門 最新開発環境による簡単3Dゲーム制作

Unity4入門 最新開発環境による簡単3Dゲーム制作

技術書ってニッチな物なので、口コミが凄く重要だと思っていて、口に出して特徴を言いやすい表紙が大切だと思います。

すでに校了数日前という段階になっていたにもかかわらず、デザインは納得できずに何度も直しをお願いして、非常にいろんな人にご迷惑をおかけしましたが、おかげで良いモノができあがったと思います。

書いてて大変だったこと

環境変わりすぎ問題

執筆中に一番頭を悩まされたのは、「執筆中に環境変わりすぎ」問題です。

まず、スマートフォン開発特有の問題として、毎年何かしらアップデートされるので、執筆期間が延びれば伸びるほどあらゆる情報が古くなると言うこと。

特に、今年はかなり変化が激しく、Yosemiteがリリースされて、全てのスクリーンショットが古くなってしまったり、iOS8+Xcode6の登場で動作確認が必要になったり、iPhone6, 6+の発表で解像度周りの記述を変えることになったりと、非常に苦労しました。

この手の本は、変化が多い9月10月辺りを跨ぐような発売日に設定するのは危険ですね。

Apple製品などは、ある程度リリーススケジュールが予測できてまだマシでしたが、cocos2d-xはそうは行きません。 アップデート頻度が高すぎる上に、ロードマップがあるのかないのか微妙な感じで、片っ端からPRが取り込まれていくので、前あった機能が非推奨になったり、挙動が変わったり、バグが潰されてたりは日常茶飯事。

具体的には、3.0βぐらいから執筆を開始して、β版、RC版も含めて4~5回アップデートが繰り返され、今に至っています。 特に土壇場で更新が入ったり、間違いに気付いたりと言うことが多く、最後の最後まで情報収集に余念がない感じでした。

本で取り上げられている『CocosStudio』のメジャーバージョンアップ2.0が10月末に出てしまって、情報が古くなってしまったことは悔しい。 執筆時点では大丈夫だったのに、いつのまにかAndroid NDKがバージョンアップしていて、最新版と互換性がなくなっていたミスを印刷の前日に発見したりと散々な感じでした。

残念なのが、完全に校了してから、発売までのわずか2週間弱の間にcocos2d-x 3.3がリリースされてしまったこと。

これで発売時点から既に最新版対応じゃなくなったのだけど、これはタイミングが悪かったと言うことで仕方ないとしか・・・・・・。

どれぐらい書いているか全くわからない問題

f:id:gigi-net:20141222160903p:plain

今回担当してくださった編集者さんは、テーマ設定から、分量から、全て僕の裁量でやらせていただいて、やりたいと言ったことを全て実現できるように手厚くサポートして頂きました。 その点では非常にやりやすかったのですが、反面、あまり情報やフィードバックが来ないので、その点は苦労しました。

例えば、Markdownで執筆された物のゲラが始めて上がってきたのが全て執筆が終わっていた9月末ぐらいで、それまで一体どうやって本になるのか全くわからないまま執筆していました。

分量もどれぐらいの量を書いて良いのかわからなかったので、適当に書きたいだけ書いたという感じで全く規模感が掴めなかった。 結果、何とか押し込めても370ページという大ボリュームになってしまったのだけど、削るハメにならなくて良かったです。

いくら直しても不安問題

お客さんからお金を取る以上はウソを書いたり、間違った知識を伝えてしまうことはやってはいけないと思っていて、間違い探しに躍起になってました。

特にコードの実装は「写しても動かない」という場所を何カ所か見つけて貰ったりして、直しても直しても不安。 大分取りきったと思うけど、まだあるかもしれない・・・・・・。

さらに、趣味で作ってる僕よりも仕事で実際にゲーム開発に携わっている人や、C++の恐い人の方がどう考えても知識量はあるだろうし、さらに効率の良い実装や綺麗な書き方があると、突っ込まれてたらイヤだなあと、何を書いても不安でした。 正直、今もAmazonの星1個付かないといいなあ、ぐらいのことは思っている。

また、C++的なお作法とcocos2d-x的なお作法が結構違っていて、どっちで書いたらわかりやすくて綺麗なんだろう、と拘ってしまって悩みまくっている時期がありました。

例えば、C++的には圧倒的にSTLを使うべきだけど、cocos2d-xの内部実装をみたら、ゴリゴリと処理を書いていた、みたいな場所も多かった。

結局、cocos2d-xの内部実装自体があんまり良くないし、他の書籍やサンプルコードを見ても結構僕が突っ込めるレベルの質だったりするので、まあそんなに拘らなくて良いか、と最終的には一皮むけて妥協することにした。

結果的には、不安だから、調べ物しまくったり、cocos2d-xの内部実装をかなり読むことになったり、C++について再度勉強する機会が得られて良かったです。

以下、参考にした書籍

C++ ポケットリファレンス

C++ ポケットリファレンス

Effective C++ 第3版 (ADDISON-WESLEY PROFESSIONAL COMPUTI)

Effective C++ 第3版 (ADDISON-WESLEY PROFESSIONAL COMPUTI)

新訂版MORE EFFECTIVE C++ (ADDISONーWESLEY PROFESSIONAL CO)

新訂版MORE EFFECTIVE C++ (ADDISONーWESLEY PROFESSIONAL CO)

なんか間違いや大嘘書いてたら本当にごめんなさいって感じ。

技術書というメディアに思うこと

技術書は以下の2点で執筆者にとって完全にWebでのメディアに劣っています。

  • 情報の速報性
  • 情報の再利用性

前者は先ほど書いたような、今回のようにバージョンアップが早すぎる環境に書籍は向かないと言うこと。 後者に関しては、Webの記事はハイパーテキストなので、他のページにリンクを貼って解説を省略すれば済むことを、本では基本的に外部にポインターを貼ることは許されず、リンクを貼れば済むことをまたもう一度書く必要があります。

というわけで、本を書く前は、技術書ってメディアは時代遅れだなあ、なんてことを何となく考えていました。

その一方で、本を書いた後で思ったのは、人にモノを教えるというのはコストがかかりすぎるということ。 技術書のレベルぐらい、しっかりと下調べをして、見やすく整形して、間違いがないか添削して、というのはとてもじゃないけどお金を貰わないとやってられない労力がかかる。

最近はQiitaなんかで、誰でも簡単に技術情報を発信、収集することはできるようになったけど、結局は有志で書かれている物だから、ちゃんと品質を担保する必要はないし、技術書のクォリティを、現状のWebメディアで創出するのは難しいと思います。

かといって、品質の高いモノをWebで有料配信するというビジネスモデルは確立されていないし、まだまだ受け入れられなさそう。

まとめ

そんなこんなで、書きたいこと書いてたら長文になってしまいました。

まだまだ語りたいことはあるけれど、このぐらいにしておこう。

書いてみて思ったのは、本書くの本当に大変すぎと言うことで、僕は学生だから良いけど、仕事しながら書いてる人は化け物だなあと思いました。 仕事もしながら執筆もしてたら、完全にプライベート破壊されそう。

あと、ユーザーでいるうちは誤字脱字が目に付いたけど、実際に書く立場になってみると、どんだけ気をつけて書いても間違いが発生するし、印刷物のミスに寛容になりそうな精神力が付きました。

本の中身については、もうちょっとわかりやすくできたとか、この情報も盛り込みたかった、ってのは無数にあるけど、現実的な規模としてはやりきった感がありますね。

しかし、1冊若いうちに書き上げることができたというのは、今後の人生にとってプラスになりそうだし、名前も売れたり、名刺代わりになったり、実績もできたりと、お金以上に得られた物は多かったと思います。

本を書くって実は凄いことらしく、周りから「凄い!!!」と言って貰えるのですが、本を書くに足る能力を持ってる人は五万といると思っているので、凄く違和感を感じます。

多くの場合は、本を書ける知識量や経験値は持っていたとしても、たまたま話が来なかったり、書くために捻出する余裕がなかったり、そもそも書く気がなかったりといったところでフィルタリングされているのに過ぎないのかと。 僕が筆を取ることになったのも、たまたまご縁があったからと、暇で余裕があったことの2点に尽きると思ってます。

買ってね!!!

そんなこんなでできあがった書籍です。是非とも多くの方の目に触れ、「神ゲー」が生まれてくれればこれ以上にない幸せはありませんね。 本屋で見かけたら是非ともお手に取ってみてください。

それと、どうやら本を書いた後恒例らしいのでウィッシュリストを貼っておきます。

Amazon.co.jp: ぎぎねっと: ウィッシュリスト

Thanks to WPZOOM about nice icon sets.