本出します！！！
![cocos2d-xではじめるスマートフォンゲーム開発 [cocos2d-x Ver.3対応] for iOS/Android](https://m.media-amazon.com/images/I/51hAFW9oDOL._SL500_.jpg "cocos2d-xではじめるスマートフォンゲーム開発 [cocos2d-x Ver.3対応] for iOS/Android")
先月告知しましたが、この度「cocos2d-xではじめるスマートフォンゲーム開発 [cocos2d-x Ver.3対応] for iOS/Android 」という本を出させて頂くことになりました！！！
『cocos2d-xではじめるスマートフォンゲーム開発』という本を出版します - 5.1さらうどん
Amazonからの発送はまだなのですが、すでに先行販売しているお店に並んでいたり、僕の手元にも見本が届きました。
12/18 先行販売『cocos2d-xではじめる スマートフォンゲーム開発 [cocos2d-x Ver.3対応]for iOS/Android』 技術評論社 (978-4-7741-7055-8) 三木康暉 著 10冊入荷 pic.twitter.com/wQ57B9VKin
— 書泉ブックタワーコンピュータ書売り場 (@shosen_bt_pc) December 18, 2014本の内容については、前回の記事を見て貰うとして、今日は「技術書執筆って一体どうやって行われているの？」ということについて、突っ込んで記事にしてみたいと思います。
きっかけはゲームジャム
きっかけは、今年1月に行われた、GlobalGameJamというゲーム開発イベントの参加レポートを技術評論社さんに書かせてもらったことでした。
ソーシャルゲーム，ボードゲーム，ファミコンまで!? Global Game Jam 2014参加レポート：レポート｜gihyo.jp … 技術評論社
元々、友人の紹介で上のような記事を寄稿したのですが、それが運良く目に留まり、2月ぐらいに執筆の話が来ました。 2ページ目にいろいろ開発の話を盛り込んだのが良かったようですね。きっかけは些細なモンです。
ペルソナとテーマ設定
ペルソナ：入門者って誰？
執筆を始めるにあたって非常に困ったのが、対象読者。入門書を書く予定だったけど、入門者ってどういう人なんだろう。 入門者と一口に言っても、手厳しい話だけど、全くの素人がゲームを作れるようになるのは非常に難しい。
今回、扱ったcocos2d-xはC++を実装言語としているため、誰でも簡単に、というわけにはいかない。さらにゲームを一本作るには、CUIの知識とか、実際にデプロイするところまでとなると、完全な初心者にとっては覚えることが多すぎる。 同じゲーム開発でも、HSPやUnityとかと比べると遙かに取っつきづらいでしょう。
人にモノを教えることは、読者がある程度の前提知識を持っていると仮定しないとすぐにフレーム問題に陥ってしまう。変数とは何か、とか、オブジェクト指向とは何か、といったことを書き始めると、入門書を書くだけでも鈍器ができてしまう
僕は、Kawazというゲーム開発者向けのコミュニティに出入りしていて、大学の新入生や専門学校生にプログラミングに触れて貰う機会が多かったので、まずは身近なところで、そういったレベルの人でも自分でゲームを出せるぐらいの中身にしようと決めました。
この本では、「学校でプログラミングは習っているけど、自分でアプリを出したことがない」「プログラミングの心得はあるけれど、スマートフォン開発は初である」ぐらいの客層を目指しています。
また、完全に初心者向けにすると、既に使っている人が買っても面白くないので、外部ツールを盛り込みまくって浅く広くとにかく網羅性を広めようというコンセプトも最初から決まっていました。
おかげで、GUIツールの紹介なども増えて、見た目も華やかになりました。この本でしか扱っていない最新情報も盛り込めたので、誰が買っても新たな発見があると思います。
テーマ：ゲーム作りのエッセンスを伝える
スマートフォン開発の世界はドッグイヤーで、cocos2d-xでのゲーム開発を付け焼き刃で覚えても、おそらく1年以内に環境は変わるだろうし、もっというと3年後には全く使い物にならなくなっていると思います。作者の僕が言うのもおかしな話だけど、僕の本も1年後には、大分環境が変わっていて、そのまま写しても動かないと言うことが多発しそう。
せっかく苦労して本を書いても、すぐに使えなくなってしまうのは悲しいので、末永く使えるように、なるべく陳腐化しない知識をたくさん盛り込もうと考えました。
そこで、僕が中学生ぐらいの時、独学でゲームプログラミングを学ぶのに使ったサイトを思い出しました。
ここで取り上げられているのは、ActionScript1.0という、もはや完全に死に絶えた言語なんだけど、ゲームアルゴリズムとか、当たり判定の計算、フラグ管理の方法、シューティングゲームの弾幕の実装と言ったような、ゲーム開発のエッセンスが詰め込まれていて、今読んでもおもしろい。
ゲーム開発は始めるためにプログラミングスキル以外に知らなくてはいけないことが多すぎて、なかなかこういう知識を体系的に学べるようなサイトや書籍がないなあと日頃から感じていたのもあってこういった内容を盛り込んでいくことにしました。
結果的に、ステージのレベルデザインの方法や設計とデータ構造、乱数といった話など、盛り込みきれなかった話は多いけれど、ゲームアルゴリズムや、ゲームフレームワークの基本構造といった話を割としっかり書けたと思います。
GitHubフローによる執筆作業
実際の執筆は、GitHubのプライベートリポジトリを使い、Markdownで執筆、Pull Request(PR)でレビューすると言ったいわゆるGitHubフローで行っていました。
今回出版した技術評論社さんは、社内にソフトウェア開発に近いフローを使った執筆スタイルの知見が蓄積されていて、エンジニアとしては非常に仕事しやすかったです。
技評さんのGitHubを使った執筆方法については、以下の資料がわかりやすい。
こういう感じにMarkdownで書いたものが
こうなります
編集者さんによるレビューもPRで行えたので、修正も簡単。
コミットログはこんな感じ。最終的に450コミットほど。
編集者さんとのやりとりもたまにメールは交わすけれど、ほとんどはSkype。 僕は札幌に住んでいて、結局一度も編集部にお邪魔することはできなかったけれど、適切にツールを運用できれば、リモートワークでもまったく問題ありませんね。
今回、GitHubフローを導入してみて、「むしろこれを使わないでどうやって本を書くんだろう」というレベルで不可欠なことを感じました。レビューとかの度にいちいち朱入れして、PDFをメールで送ってというのはマシな方で、技術書以外だったら、未だに手書きで書いて封筒に入れて運んで、みたいなことを行っている業種もあるだろうし、もはやこれなしでの執筆は考えられない。
なんとなくの執筆スケジュール
どういうスピード感で書けばいいのか見当も付かなかったので、なるべく急いで書きました。 確か4月後半ぐらいから作業を始めて、9月ぐらいにはサンプルゲームの実装含めて一通り全て揃ってるという進捗でした。
全原稿が揃ってから、ようやっとゲラができてきて、その後に何度も読み返したり、最新情報をチェックして古い情報はその都度書き換えると言った大変な作業が続き、全原稿が終わってからの方が大変でしたね。 本当はもっと早く出る物だと思ってた。
作業は、なるべく平日の日中にやるようにして、土日はほぼ作業しなかったですが、基本的に書きたいときに書くというのが一番進みます。
Markdownの執筆方法
蛇足ですが、文章の執筆はvimで、プレビューは「Marked 2」というMac用のMarkdownビューワーを使いました。
Marked2は、1500円ぐらいして、ちょっとお高く感じられるけど、まずMarkdownのプロセッサを自前で実装できるため、GFMと全く同じような見た目でレンダリングさせることができる。
また、CLIも付属していて、全ての文章をスクリプトで一括でPDF化する、なんてことが簡単にできて、執筆には大活躍でした。
サンプルゲームとGoal Driven
Goal Driven
この本の特徴として、実際にアプリストアで配付されている3本のゲームが付属しています。
サンプルゲームを作るというのは、"Goal Driven"な学習法の考えに基づいていて、「自分が何を作るか最初に提示されないとやる気が出ない」ということ。
これから学習を始める人に気軽にダウンロードしてもらって、挙動の確認や目的意識のアップに使って頂ければ良いなあと･･････。
本当は、一本のゲームとしてもちゃんと遊べるようなクォリティを目指したかったのだけど、結局サンプルゲームの域を出ない規模感になってしまいました。
元々、この話は今年4月に行われた「Unite Japan」という、Unityの技術者向けカンファレンスでUnityのエヴァンジェリストの方が話していた話。以下の資料に凄く感銘を受けたのでオススメ。
japan.unity3d.com/unite/unite2014/files/DAY2-1800-room1-Carl.pdf
サンプルゲームの開発フロー
サンプルゲームは、普段一緒にゲーム開発をしている仲間に手伝ってもらって開発できたので混乱はありませんでした。
サンプル特有の作り方として、普段と着想の方法が逆と言うこと。
普段は、他と被らない独創的なゲームを作って、世界観などを練り込み、コードの綺麗さは犠牲にして面白さを優先というフローで作るのに対し、今回は、最初に章ごとに説明したいことを決め、ゲーム性よりもコードの見通しの良さを優先し、読者が理解しやすいように、なるべく既存ゲームに似せるという作り方をしました。 そのため、どのゲームもどこかで見たことのあるような感じのゲームになってます。
いろいろな方に協力して頂いた
各種ツール類の提供
一番大きかったのは、CRI・ミドルウェアさんにADX2 LE for cocos2d-xをリリース前に提供して頂き、執筆にあたって、レビューの協力や、ADX2の質問などにも答えて頂けました。ありがたい限りです。
おかげでリリースされたばかりのライブラリの内容を紹介することができました。
初心者目線によるレビュー
本の校正作業などは、ゲームプログラミングをやってみたい初心者の学生を中心に何人かに手伝って貰いました。 ここでもGitHubが役に立って、バグがあったり、疑問点があったらissueに書き込んで貰うというスタイルを取ったことで、多くの記述ミスを潰せました。気をつけててもミスって大量に発生するんですね、という感想です。
レビュアーのレベルはかなり幅があって、自分で興味持って全て試してくれた子もいるし、環境構築で躓いてしまった子まで様々です。 協力の甲斐あって、最低レベルとして、「全く理解せずとも写せば動く」という質は到達できたとおもいます。
使ってるフレームワークとか、要求してるレベルとか、分量とか、どれも初心者には荷が重い感じだったけど、今は実際にそのうち何人かが自分のゲームを作りだし始めていてくれて、書いて良かったなあと実感できる一件でした。
やっぱり、近場の人に見て貰って反応を貰うのは何を作ってても超重要ですね。やる気も出るし。
表紙の作り方
最後に表紙。表紙を担当してくれたイラストレーターの[twitter:@berunu]さんが記事を書いてくれたので、ご興味があれば是非。
Kawaz - 『cocos2d-xではじめるスマートフォンゲーム開発』表紙メイキング【KawazAdventCalendar12/19】
気をつけたこととしては、「技術書のタイトルって誰も覚えない」ということで、見た目一発でインパクトのあるデザインにしてもらいました。
参考にした物として、例えば、このUnityの技術書は凄く秀逸だと思ってて、めちゃくちゃインパクトがある。初学者にオススメするときも「ヒヨコの本」とか言って勧めやすい。
技術書ってニッチな物なので、口コミが凄く重要だと思っていて、口に出して特徴を言いやすい表紙が大切だと思います。
すでに校了数日前という段階になっていたにもかかわらず、デザインは納得できずに何度も直しをお願いして、非常にいろんな人にご迷惑をおかけしましたが、おかげで良いモノができあがったと思います。
書いてて大変だったこと
環境変わりすぎ問題
執筆中に一番頭を悩まされたのは、「執筆中に環境変わりすぎ」問題です。
まず、スマートフォン開発特有の問題として、毎年何かしらアップデートされるので、執筆期間が延びれば伸びるほどあらゆる情報が古くなると言うこと。
特に、今年はかなり変化が激しく、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がリリースされてしまったこと。
これで発売時点から既に最新版対応じゃなくなったのだけど、これはタイミングが悪かったと言うことで仕方ないとしか･･････。
どれぐらい書いているか全くわからない問題
今回担当してくださった編集者さんは、テーマ設定から、分量から、全て僕の裁量でやらせていただいて、やりたいと言ったことを全て実現できるように手厚くサポートして頂きました。 その点では非常にやりやすかったのですが、反面、あまり情報やフィードバックが来ないので、その点は苦労しました。
例えば、Markdownで執筆された物のゲラが始めて上がってきたのが全て執筆が終わっていた9月末ぐらいで、それまで一体どうやって本になるのか全くわからないまま執筆していました。
分量もどれぐらいの量を書いて良いのかわからなかったので、適当に書きたいだけ書いたという感じで全く規模感が掴めなかった。 結果、何とか押し込めても370ページという大ボリュームになってしまったのだけど、削るハメにならなくて良かったです。
いくら直しても不安問題
お客さんからお金を取る以上はウソを書いたり、間違った知識を伝えてしまうことはやってはいけないと思っていて、間違い探しに躍起になってました。
特にコードの実装は「写しても動かない」という場所を何カ所か見つけて貰ったりして、直しても直しても不安。 大分取りきったと思うけど、まだあるかもしれない･･････。
さらに、趣味で作ってる僕よりも仕事で実際にゲーム開発に携わっている人や、C++の恐い人の方がどう考えても知識量はあるだろうし、さらに効率の良い実装や綺麗な書き方があると、突っ込まれてたらイヤだなあと、何を書いても不安でした。 正直、今もAmazonの星1個付かないといいなあ、ぐらいのことは思っている。
また、C++的なお作法とcocos2d-x的なお作法が結構違っていて、どっちで書いたらわかりやすくて綺麗なんだろう、と拘ってしまって悩みまくっている時期がありました。
例えば、C++的には圧倒的にSTLを使うべきだけど、cocos2d-xの内部実装をみたら、ゴリゴリと処理を書いていた、みたいな場所も多かった。
結局、cocos2d-xの内部実装自体があんまり良くないし、他の書籍やサンプルコードを見ても結構僕が突っ込めるレベルの質だったりするので、まあそんなに拘らなくて良いか、と最終的には一皮むけて妥協することにした。
結果的には、不安だから、調べ物しまくったり、cocos2d-xの内部実装をかなり読むことになったり、C++について再度勉強する機会が得られて良かったです。
以下、参考にした書籍
なんか間違いや大嘘書いてたら本当にごめんなさいって感じ。
技術書というメディアに思うこと
技術書は以下の2点で執筆者にとって完全にWebでのメディアに劣っています。
- 情報の速報性
- 情報の再利用性
前者は先ほど書いたような、今回のようにバージョンアップが早すぎる環境に書籍は向かないと言うこと。 後者に関しては、Webの記事はハイパーテキストなので、他のページにリンクを貼って解説を省略すれば済むことを、本では基本的に外部にポインターを貼ることは許されず、リンクを貼れば済むことをまたもう一度書く必要があります。
というわけで、本を書く前は、技術書ってメディアは時代遅れだなあ、なんてことを何となく考えていました。
その一方で、本を書いた後で思ったのは、人にモノを教えるというのはコストがかかりすぎるということ。 技術書のレベルぐらい、しっかりと下調べをして、見やすく整形して、間違いがないか添削して、というのはとてもじゃないけどお金を貰わないとやってられない労力がかかる。
最近はQiitaなんかで、誰でも簡単に技術情報を発信、収集することはできるようになったけど、結局は有志で書かれている物だから、ちゃんと品質を担保する必要はないし、技術書のクォリティを、現状のWebメディアで創出するのは難しいと思います。
かといって、品質の高いモノをWebで有料配信するというビジネスモデルは確立されていないし、まだまだ受け入れられなさそう。
まとめ
そんなこんなで、書きたいこと書いてたら長文になってしまいました。
まだまだ語りたいことはあるけれど、このぐらいにしておこう。
書いてみて思ったのは、本書くの本当に大変すぎと言うことで、僕は学生だから良いけど、仕事しながら書いてる人は化け物だなあと思いました。 仕事もしながら執筆もしてたら、完全にプライベート破壊されそう。
あと、ユーザーでいるうちは誤字脱字が目に付いたけど、実際に書く立場になってみると、どんだけ気をつけて書いても間違いが発生するし、印刷物のミスに寛容になりそうな精神力が付きました。
本の中身については、もうちょっとわかりやすくできたとか、この情報も盛り込みたかった、ってのは無数にあるけど、現実的な規模としてはやりきった感がありますね。
しかし、1冊若いうちに書き上げることができたというのは、今後の人生にとってプラスになりそうだし、名前も売れたり、名刺代わりになったり、実績もできたりと、お金以上に得られた物は多かったと思います。
本を書くって実は凄いことらしく、周りから「凄い！！！」と言って貰えるのですが、本を書くに足る能力を持ってる人は五万といると思っているので、凄く違和感を感じます。
多くの場合は、本を書ける知識量や経験値は持っていたとしても、たまたま話が来なかったり、書くために捻出する余裕がなかったり、そもそも書く気がなかったりといったところでフィルタリングされているのに過ぎないのかと。 僕が筆を取ることになったのも、たまたまご縁があったからと、暇で余裕があったことの2点に尽きると思ってます。
買ってね！！！
そんなこんなでできあがった書籍です。是非とも多くの方の目に触れ、「神ゲー」が生まれてくれればこれ以上にない幸せはありませんね。 本屋で見かけたら是非ともお手に取ってみてください。
それと、どうやら本を書いた後恒例らしいのでウィッシュリストを貼っておきます。
