25 歳くらいのゲームプログラマの人がやる
Adobe AIR を使った比較的真っ当なゲーム開発

Created: 2012-10-23
Modified: 2012-10-23
Written by Tatsuya Koyama

このページは

この文書は平行世界における 16 歳の僕へ向けたメッセージだ。

平行世界における 16 歳の僕は、恐らくゲームを作りたいと思っているだろう。 夢見る少年である君は、自分の頭の中に溢れるイメージを形にしたくて仕方がない。 絵を動かすこと、音を鳴らすこと、プログラムを書くことに興味を抱いてやまない、 でも何から手をつけていいかわからない、そういう年頃だ。

君に朗報がある。25 歳の僕も、まだゲームを作りたいという信念を持ち続けている。 そして運良く、ゲームを作るという職業にもついている。 コンソールライクなスマートフォンのソーシャルゲームを作って運用するという、 現代らしくて面白い領域の仕事だ。 そんな 25 歳の僕は、16 歳の君に向けてアドバイスを送ろう。 君が本当にゲームを作れるようになるための、近道を与えるアドバイスだ。

Mr.WARP が作れるようになるまで

僕は最近、仕事とは別に趣味でちょっとしたゲームを作った。 Mr.WARP というアクションゲームだ。 画面はこんな感じだ:

このゲームは iPhone でも Android でも Windows のブラウザでも Mac のブラウザでも動く、 マルチプラットフォームなゲームだ。それなりに滑らかに動くし、敵や弾などもたくさん出てくるし、 効果音や BGM も鳴る。これくらいのものが作れれば、ひとまずゲームが作れたと言っても差し支えないだろう。

ここでは職業プログラマの僕が趣味でこれを作った過程を示すことで、 「大人がやる比較的真っ当な」ゲームづくりの概要をつかんでもらう。 もちろんこれは僕流のやり方であって、万人のための教科書にはなりえない。 だが、君にはそれで十分だろう。

1. 覚悟を決める

1.1 時間を覚悟する

ゲームづくりには時間がかかる。プログラミングを学ぶのにもツールに慣れるのにも何かと時間がかかる。 そして実際にゲームの中身を作り始めてから、それを完成に持っていくまでにも相当な時間がかかる。 君は天才ではないから、この「とにかく時間がかかる」ということは覚悟しておかなければならない。

目安としては、

・20 歳くらいの頃に作った GENETOS1200 時間以上
・25 歳の今作った Mr.WARP70 時間程度 (+ 共通フレームワークに 80 時間程度)

ざっくりこれくらい開発に時間がかかっている。 熟練によってこの時間は減らしていけるが (Mr.WARP は 20 歳の頃だったらもっと時間がかかっていただろう)、 少なくとも現状の僕の能力ではこんなものだ。

なお、ここで言う「開発」とはプログラムのコーディング、画像アセットの制作、 BGM の制作、ゲームバランスのチューニングなどが含まれるが、 『プログラミングの勉強』は含まれていないことに注意されたい。

他でもない君のためだ、はっきり言おう。 何かを完成させるためには、それ相応の時間と労力を費やさなければならない。 ゲームを作るための道具や、ゲームづくりを学ぶための環境は昔よりも圧倒的に良くなっているが、 それでもまだ「誰でも一瞬で」「完成された」ゲームが作れるような魔法は存在していない。

銀の弾丸などは期待しない方がいい。 何かを完成させるためのたったひとつのライフハックは、「いいからやれ」だ。

1.2 完成するまでやる

「完成させること」はとても難しい。 同人ゲームは 9 割が完成されないまま終わる という話もあるくらいだ。 仕事の現場ですら、いくつものプロジェクトが完遂されず消えていく。

君に知っておいてほしいことは、『何かを完成させている人』は君が思っているよりも少ない ということだ。 優秀なエンジニアはたくさんいる。だけどその数だけ、その人をその人たらしめる作品があるわけではない。 言われなくても何かを作ろうとして企画書を書く人や、 ちょっとしたプロトタイプを作って人に見せて回っているような人は時々いて、 そうした人を僕は純粋にリスペクトしているのだけど、 悲しいことにそれが完成にまで至ったケースはあまり見たことがないんだ。

これは逆にチャンスでもある。 何かを完成するまで作ることができれば、君は何者かになりえるかもしれない。 全部は無理だろう。1つでもいいからやりきればいい。

2. 知ることは簡単ではないことを知る

「ゲームの作り方」を学ぶにあたってだが、 これをやっておけば OKというものは残念ながら、なかなか存在しない。 ゲーム開発に関係する技術やノウハウは多岐にわたるし、 そもそもゲームというもの自体が複合的で複雑なアートだからだ。

勉強が足りないうちは、そもそもどう勉強したらいいのかが分からない ものだ。 本を読めばいいと言っても、何をどの順番で読んでいったらいいのかは読んでみないと知り得ない。 好奇心旺盛な君はすぐに「ゲームプログラミング 入門」などと Google で検索したりするだろうが、 ネットにある情報は基本的に玉石混淆だと思った方がよい。 本でさえも「これは名著だ!」と思える専門書があれば、「なんだかしょうもないな」 と思ってしまうような内容のものもあるくらいだ。

幸い、僕が 16 歳だった頃とは違って、 今では日本語のゲームづくり系の書籍でも品質の高い知識が手に入りやすくなっている。 Web の情報や勉強系サービスも、信頼に足るものが多くなった。 一番いいのはその道のよく知っている人に、何がオススメかを聞いてみることだ。

今回は僕がその道標の1つとなれることを願う。

3. プログラミングを覚える

何にしても、ビデオゲームを作るならプログラミングは勉強する必要があるし、 ある程度の数学も避けては通れない。 まあとりあえず高専の情報工学科に 3 〜 4 年くらい通うといい。

プログラミング言語はたくさんある。 今時ならカジュアルに JavaScript から入るとか、 Flash ゲーム を作るとかでもいいかもしれない。 JS ゲームの投稿サイト 9leap とか、ブラウザ上でコードを書いて Flash が動かせてしまう wonderfl などは知っておくといい。

だが君はもっと手堅くやりたい、 将来もゲームプログラマとして生きていきたいと思っていることだろう。 その場合は C 言語から初めて、C++ とか Java とかをさわりつつ、 Perl, Python, Ruby あたりのライトな言語にも手を伸ばしていくのが無難だ。 結局のところ C 言語というやつは避けては通れない。 こいつをやることでコンピュータがメモリ上で何をしてるかとか、 原始的なアルゴリズムのこととかを理解しやすくなる。 データ構造とか動作原理とかそういうところは泥臭くて ゲームのコンテンツ作りからは遠いのだけど、 ちゃんとしたものを作るためにはこのあたりを知っておく必要がある。

まあこの辺はいつか分かればよいところだ。 まずは手を動かしてゲームを作ってみるのでいい。

4. プラットフォームを選ぶ

4.1 どこで動く何をつくるか

勉強をする前にやっておくといいことがある。 「誰が使う、どんなものを作りたいのか」というゴールを決めておくことだ。 そうすればプログラミングも目的を果たすための手段でしかなくなる。 その勉強も楽しいものになり、方向性がブレることもなくなるだろう。

25 歳の僕が趣味でゲームを作るにあたって考えるのは、 どのプラットフォームで動くゲームにするか ということだ。 GENETOS は Windows 専用のゲームとして作ったが、 昨今ホットな市場と言えばやはり スマートフォン、とりわけ iPhone と Android だから、そこで動くゲームにしたい。 「ゲーム作ったんだ」と言ってすぐにさわってもらえるのは、 やはり現代の携帯電話デバイスだろうからね。

4.2 どうやって作るか

普通、必要な技術要素はプラットフォームごとに異なる。 例えば iPhone アプリだったら Objective-C という言語でプログラムを書く必要があるし、 Android なら Java だ。 だが両方で動くゲームを作りたいときに、 Objective-C で書いたものを Java で書き直すというようなことは面倒なのでしたくない。 1つプログラムを書いたらそれが全部の場所で動いてほしい。

みんな考えることは同じで、最近はこうした「複数のプラットフォームに対応するためのソリューション」 がいくつも出てきている。 Titanium とか Cocos2d-x とかで検索してみるとよいだろう。 中でも盛り上がっているのが Unity という 3D ゲームの統合開発環境だ。

だが今回僕は Adobe AIR という選択肢をとった。 AIR とは何か、は説明が面倒なのでここでは省くが、 要はこいつも iPhone, Android, ひいてはブラウザの Flash Player で動くゲームが作れるような代物だ。言語は ActionScript3.0 を使う。

4.3 何故 Adobe AIR か

なぜ他でなく AIR を選んだかというのは僕の好みによるところが大きい。 ActionScript3.0 という言語自体も僕は好きだしね。 AS3 は JavaScript の軽やかさに型やクラスやネームスペースといった安心感を加えたような言語だ。 Flash や AIR 界隈でしか使われることのない言語だが、 ゲームを書く言語としてはちょうどいいものだと思う。

また、何気に ブラウザでも動かせるというのも大きなアドバンテージ だ。 スマフォと PC ブラウザを押さえておけば、大体どんな人にでも遊んでもらえそうだ。 Unity も Web 用のプレイヤーがあるけれど、 ブラウザで使うということに関してはやはり Flash の方が馴染みが深い。

モバイルで動く Adobe AIR は数年前から存在していたが、全然注目されてはいなかった。 僕も前から様子を見てはいたが、AIR で作られた iPhone アプリなどは数も少ないし、 あっても動作が重くて話にならない感じだった。 だけど最近(2012 年の 3 月くらい)になって、 AIR でもゲームに耐えうるくらいの画面の描画ができるように なった。 Flash 11 で導入された Stage3D という描画技術が iPhone / Android の AIR でも使えるようになったんだ。

このニュースを見てからは、土日にちょっと時間を使って Adobe AIR を調べたり試したりしていた。 適当に絵を表示させるようなものをビルドして、 それを iPod touch に入れたり Android に入れたりして実行速度とかを見ていた。 だらだら2ヶ月くらいそんなことをして、これは実用に耐えるなと判断できた。 ここから僕は、AIR でゲームをつくることを決心したんだ。

5. 道具を揃える

5.1 Mac を買う

ビデオゲームを作るには、少なくとも PC は必要だ。 バイトをするなり小遣いを節約するなりして 10 万円くらい貯めたら、 悪いことは言わないから MacBook Pro を買うといい。

学生時代の僕は、Mac なんてオシャレ気取ってる人が使ってるだけだろ と吐き捨てながら、 Visual Studio で DirectX を使ったゲームのプログラムを書いていた。 だが今は ちょっと Mac しか考えられない 体になっている。 インタフェースが心地よかったりターミナルで Linux 系のコマンドが打てたりと理由は色々あるが、 くどくど語るのは野暮だからやめておこう。 どちらにせよ、iPhone 向けのアプリを世に出すためには Mac OS のマシンが必須 だということは、1つのファクトだ。

5.2 エディタにこだわる

プログラマであれば、ツールにもこだわった方がいい。 特にプログラマにとってのテキストエディタというやつは、料理人にとっての包丁のようなものだ。 自分に合ったものをカスタマイズして使い込めば、日々のコーディングが楽しくなるだろう。

ちなみに世のプログラマには Emacs派Vim派それ以外 という3つの流派が存在するのだが、 ウェブというパブリックな場でこの話題に振れることは 不毛な宗教論争を生み出すだけ なので注意されたい。
僕かい? 僕は Emacs 派だ。

5.3 その他の制作環境とコスト

ひとまず Mac を一台確保すれば、Adobe AIR によるゲームプログラミングは無料でできる。 それ以降はやりたいことに応じてお金をかけるか、かけないで乗り切るかを判断することになるだろう。 以下に得られるものと、かかる費用の例を示す。

項目 コスト【参考】
リッチな統合開発環境で開発を行うために、
Flash Builder を買う
10万円くらい
音楽制作のために Cubase Elements を買う 18000 円
音楽制作のために SonicCell を買う 75000 円
画像編集のために PhotoShop Elements を買う 12000 円
データのコンバータとか細かいツールを揃える 各種数千円くらい(ものによる)
検証端末用に iPod touch 32GB を買う 25000 円
検証端末用に Android に機種変する 50000 円(ものによる)
iOS アプリを開発するために
iOS Developer Program に登録する
8400 円 / 年
Android アプリをマーケットに出すために
Google Play のデベロッパ登録をする
25 ドル

ゲームを作るのにはお金もかかるんだ。

6. アーキテクチャの選定

僕は Adobe AIR を使うと決めた。あとはゲームを作ればいいだけだが、 全てのプログラムを自分で書くというのは懸命なやり方じゃない。 世の中にはたくさんのライブラリやフレームワークがある。 こうしたものを利用すれば労力を削減できるし、 コードやドキュメントを読むことでソフトウェア設計の勉強にもなるから積極的に活用すべきだ。 特に Adobe AIR の Stage3D を扱う場合には、 自分でコードを書くのは面倒なので大抵は世にあるフレームワークを利用することになる。

Stage3D 用のフレームワークは色々あって、2D ゲーム向けでは Starling FrameworkND2D 、3D 向けでは Away3DAlternativa3D あたりが有名どころだ。 僕は色々調べた後に、Starling Framework を使うことに決めた。 初めは ND2D を使うつもりで進めていたのだが、 使っていて色々と自分の要件には合わない部分が出てきたので途中で乗り換えた。 これには少し時間を無駄にしてしまったが、エンジニアとして生きていたらこういうことは時々あるものだ。

Starling を使うことで「どうせやらなきゃいけないような仕事」はかなり人任せにすることができる。 それでもまだ完璧じゃない。世のゲームフレームワークという奴は、 フレームワークというよりも便利ライブラリ集といった側面が強く、 使い手にある程度の自由を残している。 だから僕はこの上に、さらに自分用のフレームワークである tkFramework を構築した。 これは僕がゲームを作るときに楽をするためのもので、どのゲームを作るときでも役に立つ。

最終的に、僕のゲームのソフトウェア・アーキテクチャは以下のように決まった:

  • Adobe AIR
    • + Starling Framework
      • + tkFramework
        • + ゲームのコード

7. 曲をつくる

さあ、いよいよゲームの中身を作り出す段階まで来た。 変わってると思われるかもしれないが、僕はゲームを作るときにまず曲から入る。 PC 上でやる音楽制作(DTM)は必要なソフトとか機材のつなぎ方とかが分かりにくくて、 学生時代の僕は何度も心が折れそうになったものだが、最終的には Mac で Cubase Elements というソフトと Roland SonicCell というハードウェア音源を用いて曲を制作する環境を整えた。

音楽の厄介なところはお金がかかることだ。 Cubase の方は 18000 円くらいかかるし、 SonicCell に至っては 75000 円くらいしてしまうので、 この辺をやるのは社会人になってからにしよう。

ソフトと音源に加えて、僕には姉からもらった電子ピアノがあったので、 音の入力にはこいつを使っている。 曲を作ってるときの画面のイメージはこんな感じだ:

学生時代の頃は Windows PC で、XGWorks ST という安いソフトを使って マウスで1つ1つ音符を置いていく という涙ぐましい音楽制作をしていたが、 Mac と Cubase とハード音源と電子ピアノで作るようになってからは非常に快適だ。

8. 絵を描く

8.1 ツール

音はともかく、画像はゲームには不可欠だ。 自分で絵を描かずに素材を使うにしても、 画像のリサイズなど加工を行うために手頃な画像編集ソフトは用意しておいた方がよい。 まあぶっちゃけ PhotoShop が使えればそれでいい。 ただ PhotoShop はまともに買うと 10 万円くらいするので注意。 機能制限版の Elements なら 1 万円台、学生ならアカデミック版もあった気がする。

無償の PhotoShop 的なものとしては GIMP が有名だ。そんなに凝ったことをしないなら、これで十分事が足りるだろう。 ただ、Windows 版も Mac 版も使ってみたことはあるが、 少し重かったり動作が不安定だったりする感は否めない。

8.2 ゲームのための画像制作

8.2.1 画像のパッキング

ゲームに使う画像はゲーム用に最適化すべきだ。 代表的なのは画像のパッキングだ。メモリと処理の効率化のために、 複数の画像を 512 x 512 px の画像とか 1024 x 256 px の画像とか (1辺が2の累乗であることに意味がある) にまとめるなどということはよくやる。 例えば、Mr.WARP で使ってる画像は最終的に以下のような形になっている:

こうしたものは スプライトシート とか テクスチャアトラス などと呼ばれる。 ツールも色々あって、 Texture Packer あたりがポピュラーだ。 僕の場合はお金をかけたくなかったので、Starling Framework の姉妹作である Sparrow Framework の中に入っていたスクリプトを利用した。 こうしたスクリプトは自分でもちょっと書いたことがあるが、 やってみるとアルゴリズムなど色々奥が深くて面白い。

8.2.2 ファイルサイズの削減

また、ファイルサイズを小さく抑える という観点もある。 最近はゲームもダウンロードして手に入れることが主流になってきたが、 ファイルサイズを落とせば、単純にそれをダウンロードする人の待ち時間を短くしてあげることができる。

png 画像などの劣化しないような画像形式はファイルサイズが大きくなりがちだが、 そうしたものには 減色 が効果的だ。減色ツールは OPTPiX というやつが優秀だと会社のデザイナーさんは評価していたが、これは有料で 3 万円くらいかかる (しかも Windows 専用だ)。 お金のかからないオープンソースのものでも pngquant などのコマンドラインツールは十分実用に耐えるレベルなので、覚えておくといいだろう。 余分なメタデータを削除する ImageOptim というのもある。

8.2.3 ビットマップフォント

ゲームを作るときに、英数フォントを画像で用意しておいてそこから切り出して使うというのもよくやる。 Mr.WARP のゲーム内のフォント表示には、以下のような画像を利用している:

この辺はさすがにちゃんとしたツールを使わないと面倒なので、僕は Glyph Designer というソフトを買った。30 ドルくらいだった。 GENETOS の頃は世間知らずだったので地道に1文字1文字置いていって画像を作ったりしていた が、 これは非常に面倒だし不毛だった。こういうことをやっていいのは学生のうちまでだね。

君の時間は有限だ。大切に使ってほしい。

9. コードを書く

いよいよコーディングの話だ。 だが、ゲームコーディングの話はまた奥が深いところなので、それはまた別の機会に教えよう。 こればかりは、たかだか1セクションで概要を示せるようなものではない。

ここではプログラマらしく、コードで語ることにする。 僕は君のために、Mr.WARP のソースコードとアセット(画像とか音声のリソースファイル)を全て公開しよう。


きっと今の君には理解できないことがたくさんあると思うが、 いつか分かるときが来る。

10. 人に見せる

ゲームができたら知人や友人に見せてドヤっとするといい。 ただしろくにゲームになっていないうちに見せると、何となくやった気になって終わってしまいがち なので、ある程度完成してから見せるようにすることをオススメする。

実際に人にプレイしてもらってその様子を肩越しに眺めると、 多くの気付きが得られる。例えば Mr.WARP では最初に「タップで移動」と文字で表示してやっても、 実際に Android でやってもらったら 10 人中 10 人くらいがスワイプでキャラを移動させようとした。 結局 Mr.WARP の場合はブラウザでも遊べるようにするためにクリックゲーと割り切ったのだが、 大事なのは こうしたことが作者本人には意外と気づきにくかったりする ということだ。

君がゲームを作るのは自己満足のためだろうか? きっと違うだろう、最後には誰かに楽しんでもらいたいから作るはずだ。 それを忘れないためにも、人に見せることは躊躇せずやっていい。

11. 世に出す

ここまで来たら後はもう世に出すだけだ。作ったからには公開をしよう。 世に出すまでがゲーム開発だって、エラい人も言っていた。 Adobe AIR で作ったものは、そのまま普通の iOS アプリや Android アプリにしてマーケットに出すことができる。 また、このサイトで公開しているように Flash 形式でブラウザで動かすことも可能だ。

Android は 25 ドル払って Developer 登録をすれば、サクっと公開できる。 iOS は審査があったり面倒な Provisioning まわりの作業が必要だったりして気が重い。 両方に出す場合は、それぞれの解像度のスクリーンショットを用意したり、 複数サイズのアイコンを作成したりもしなきゃいけない。 ただ、マーケットに並べる絵や説明文を考えている時間というのは結構楽しいものだ。

このあたりの作業も色々あるが、ネットで検索すればまとめてくれている人がたくさんいるだろうから、 ここで詳しく書くことはしない。

12. 最後に

こうしていつか君は、それなりに真っ当な感じでゲームが作れるようになる。 ゲームをつくることの大方のあらましや、全体観はつかめただろうか。

ひとまず、僕の話はこれで終わりだ。 平行世界における 16 歳の僕が、僕ならではのゲームを完成させてくれることを、 僕は祈っている。