5.1さらうどんスマートフォン用の表示で見る5.1さらうどん@giginetの技術ブログ。ゲーム開発、iOS開発、その他いろいろこの広告は、90日以上更新していないブログに表示しています。5.1さらうどんAmazonからの発送はまだなのですが、すでに先行販売しているお店に並んでいたり、僕の手元にも見本が届きました。2014本の内容については、前回の記事を見て貰うとして、今日は「技術書執筆って一体どうやって行われているの?」ということについて、突っ込んで記事にしてみたいと思います。きっかけはゲームジャムきっかけは、今年1月に行われた、GlobalGameJamというゲーム開発イベントの参加レポートを技術評論社さんに書かせてもらったことでした。紹介で上のような記事を寄稿したのですが、それが運良く目に留まり、2月ぐらいに執筆の話が来ました。2ページ目にいろいろ開発の話を盛り込んだのが良かったようですね。きっかけは些細なモンです。書く予定だったけど、入門者ってどういう人なんだろう。入門者と一口に言っても、手厳しい話だけど、全くの素人がゲームを作れるようになるのは非常に難しい。今回、扱ったcocos2d-xはC++を実装言語としているため、誰でも簡単に、というわけにはいかない。ゲームを一本作るには、CUIの知識とか、実際にデプロイするところまでとなると、完全な初心者にとっては覚えることが多すぎる。同じゲーム開発でも、HSPやUnityとかと比べると遙かに取っつきづらいでしょう。人にモノを教えることは、読者がある程度の前提知識を持っていると仮定しないとすぐにフレーム問題に陥ってしまう。わけだし、C++の文法など、プログラミングの基礎知識はバッサリとカット。僕は、Kawazというゲーム開発者向けのコミュニティに出入りしていて、大学の新入生や専門学校生にプログラミングに触れて貰う機会が多かったので、まずは身近なところで、そういったレベルの人でも自分でゲームを出せるぐらいの中身にしようと決めました。この本では、「学校でプログラミングは習っているけど、自分でアプリを出したことがない」「プログラミングの心得はあるけれど、スマートフォン開発は初である」ぐらいの客層を目指しています。完全に初心者向けにすると、既に使っている人が買っても面白くないので、外部ツールを盛り込みまくって浅く広くとにかく網羅性を広めようというコンセプトも最初から決まっていました。おかげで、GUIツールの紹介なども増えて、見た目も華やかになりました。この本でしか扱っていない最新情報も盛り込めたので、誰が買っても新たな発見があると思います。テーマ:ゲーム作りのエッセンスを伝えるスマートフォン開発の世界はドッグイヤーで、cocos2d-xでのゲーム開発を付け焼き刃で覚えても、おそらく1年以内に環境は変わるだろうし、もっというと3年後には全く使い物にならなくなっていると思います。作者の僕が言うのもおかしな話だけど、僕の本も1年後には、大分環境が変わっていて、そのまま写しても動かないと言うことが多発しそう。苦労して本を書いても、すぐに使えなくなってしまうのは悲しいので、末永く使えるように、なるべく陳腐化しない知識をたくさん盛り込もうと考えました。そこで、僕が中学生ぐらいの時、独学でゲームプログラミングを学ぶのに使ったサイトを思い出しました。Flashゲーム講座&アクションスクリプトサンプル集ここで取り上げられているのは、ActionScript1.0という、もはや完全に死に絶えた言語なんだけど、ゲームアルゴリズムとか、当たり判定の計算、フラグ管理の方法、シューティングゲームの弾幕の実装と言ったような、ゲーム開発のエッセンスが詰め込まれていて、今読んでもおもしろい。ゲーム開発は始めるためにプログラミングスキル以外に知らなくてはいけないことが多すぎて、なかなかこういう知識を体系的に学べるようなサイトや書籍がないなあと日頃から感じていたのもあってこういった内容を盛り込んでいくことにしました。結果的に、ステージのレベルデザインの方法や設計とデータ構造、乱数といった話など、盛り込みきれなかった話は多いけれど、ゲームアルゴリズムや、ゲームフレームワークの基本構造といった話を割としっかり書けたと思います。Request(PR)でレビューすると言ったいわゆるGitHubフローで行っていました。今回出版した技術評論社さんは、社内にソフトウェア開発に近いフローを使った執筆スタイルの知見が蓄積されていて、エンジニアとしては非常に仕事しやすかったです。技評さんのGitHubを使った執筆方法については、以下の資料がわかりやすい。Inaoこういう感じにMarkdownで書いたものがこうなります編集者さんによるレビューもPRで行えたので、修正も簡単。コミットログはこんな感じ。最終的に450コミットほど。編集者さんとのやりとりもたまにメールは交わすけれど、ほとんどはSkype。僕は札幌に住んでいて、結局一度も編集部にお邪魔することはできなかったけれど、適切にツールを運用できれば、リモートワークでもまったく問題ありませんね。今回、GitHubフローを導入してみて、「むしろこれを使わないでどうやって本を書くんだろう」というレベルで不可欠なことを感じました。レビューとかの度にいちいち朱入れして、PDFをメールで送ってというのはマシな方で、技術書以外だったら、未だに手書きで書いて封筒に入れて運んで、みたいなことを行っている業種もあるだろうし、もはやこれなしでの執筆は考えられない。なんとなくの執筆スケジュールどういうスピード感で書けばいいのか見当も付かなかったので、なるべく急いで書きました。4月後半ぐらいから作業を始めて、9月ぐらいにはサンプルゲームの実装含めて一通り全て揃ってるという進捗でした。全原稿が揃ってから、ようやっとゲラができてきて、その後に何度も読み返したり、最新情報をチェックして古い情報はその都度書き換えると言った大変な作業が続き、全原稿が終わってからの方が大変でしたね。本当はもっと早く出る物だと思ってた。作業は、なるべく平日の日中にやるようにして、土日はほぼ作業しなかったですが、基本的に書きたいときに書くというのが一番進みます。2」というMac用のMarkdownビューワーを使いました。Marked2は、1500円ぐらいして、ちょっとお高く感じられるけど、まずMarkdownのプロセッサを自前で実装できるため、GFMと全く同じような見た目でレンダリングさせることができる。CLIも付属していて、全ての文章をスクリプトで一括でPDF化する、なんてことが簡単にできて、執筆には大活躍でした。Drivenこの本の特徴として、実際にアプリストアで配付されている3本のゲームが付属しています。Driven"な学習法の考えに基づいていて、「自分が何を作るか最初に提示されないとやる気が出ない」ということ。一本のゲームとしてもちゃんと遊べるようなクォリティを目指したかったのだけど、結局サンプルゲームの域を出ない規模感になってしまいました。Japan」という、Unityの技術者向けカンファレンスでUnityのエヴァンジェリストの方が話していた話。以下の資料に凄く感銘を受けたのでオススメ。japan.unity3d.com/unite/unite2014/files/DAY2-1800-room1-Carl.pdfサンプルゲームの開発フローサンプルゲームは、普段一緒にゲーム開発をしている仲間に手伝ってもらって開発できたので混乱はありませんでした。サンプル特有の作り方として、普段と着想の方法が逆と言うこと。普段は、他と被らない独創的なゲームを作って、世界観などを練り込み、コードの綺麗さは犠牲にして面白さを優先というフローで作るのに対し、今回は、最初に章ごとに説明したいことを決め、ゲーム性よりもコードの見通しの良さを優先し、読者が理解しやすいように、なるべく既存ゲームに似せるという作り方をしました。そのため、どのゲームもどこかで見たことのあるような感じのゲームになってます。cocos2d-xをリリース前に提供して頂き、執筆にあたって、レビューの協力や、ADX2の質問などにも答えて頂けました。おかげでリリースされたばかりのライブラリの内容を紹介することができました。本の校正作業などは、ゲームプログラミングをやってみたい初心者の学生を中心に何人かに手伝って貰いました。ここでもGitHubが役に立って、バグがあったり、疑問点があったらissueに書き込んで貰うというスタイルを取ったことで、多くの記述ミスを潰せました。気をつけててもミスって大量に発生するんですね、という感想です。レビュアーのレベルはかなり幅があって、自分で興味持って全て試してくれた子もいるし、環境構築で躓いてしまった子まで様々です。協力の甲斐あって、最低レベルとして、「全く理解せずとも写せば動く」という質は到達できたとおもいます。使ってるフレームワークとか、要求してるレベルとか、分量とか、どれも初心者には荷が重い感じだったけど、今は実際にそのうち何人かが自分のゲームを作りだし始めていてくれて、書いて良かったなあと実感できる一件でした。近場の人に見て貰って反応を貰うのは何を作ってても超重要ですね。