説明しよう!ゲームプログラマーになるにはッ!

=前置きの前置き=

 久しぶりの「昔の自分が知りたかった情報」のゲームプログラマー版。

 まだちょっと体調が微妙なので個人のゲーム作成はもうしばらくお待ちを。

=前置き=

 昔の自分は「ゲームプログラマーになりたい!」と思っても具体的に何をすれば良いのかが分からなかった。

 「どの言語を選べば良いの?」「ゲーム業界ではどの言語を使ってるの?」「ゲームライブラリは使って良いの?」「新人に任される作業って何?」などなど事前に知りたい情報が多すぎたし、そこで間違ってしまうと時間がムダになりそうで結局ゲーム作成に乗り出すのには時間がかかってしまった。

 さらにいざゲーム作成に乗り出しても「WindowsAPIからゲームライブラリを自作」みたいな困難な作業に直面し、「本当にこれは必要なんだろうか?」と懐疑的になり挫折しそうになった。そして実際にWindowsAPIからやるのは結構な時間と労力のムダだった。

 というわけで、昔の自分(のような人)がムダな事をしなくて済むように、あるいは不安を少しでも減らせるように「昔の自分が欲しかった情報」について今の自分が示せる範囲で示そうと思う。

 ちなみに今の自分はゲームのプロジェクトに9つ(コンシューマ7つ、スマホ2つ+α)くらい関わった程度のゲームプログラマー

=Unityで慣れよう=

 今ならまずはUnityに慣れよう。

 プログラミングそのものの初歩の学習としてもちょうど良いし、ゲーム開発の初歩の学習としてもちょうど良い。スマホゲームであればUnityを扱えればそのまま職に就く事もできるし、場合によってはそのまま個人開発者として食っていく事もできる。さらにコンシューマでもエディタとして使われる会社もあるから、Unityに慣れておけばどう進むにせよムダにはならないと思う。

 ちなみにUnity内で使う言語はC#が望ましい。スマホゲームの開発も基本はC#の方が多いし、コンシューマをやる予定があるならC++に近いC#の方が良い。

=できるだけ小さいゲームを作ろう=

 で、まずはUnityでできるだけ小さなゲームを作ろう。

 意外と小さいゲームを考えるのは難しい。「ゲームを考える」というのはそもそも企画(プランナー)の範疇だし、コンパクトにまとめるのは相応のテクニックが必要になる。なので、まずは別に「面白いものを作ろう」などと思わなくて良い。最初はどっかで見たゲームでも良いし、ゲームと呼べない単純なものでも良い。

 それで実際に作ってみると、かなり小さくしたつもりでも考える事が結構出てくるのが分かる。まずはここらへんの作業に慣れていくのが肝心。

=色んなパートに慣れよう=

 ある程度慣れたら「タイトル画面」や「メニュー画面」などの一般的なゲームに存在するものを一通り作ってみよう。これも想定よりかなり面倒な事がわかる。場合によっては「今まで作ったものでは上手く追加できない」という事もあるだろう。こういった問題は大抵のゲームで起こるから、これも早めに慣れておいた方が良い。

 また、最初のゲームができたら次は別のジャンルのゲームを作ってみよう。これによって「どのゲームでも応用できそうな部分」と「ゲーム固有で考えないといけない部分」が分かってくる。

 いくつかゲームが作れたら、その後はどう進むつもりかによって対応が変わる。

 スマホゲーム方面に進むつもりなら、このままUnityを使ってあれこれしよう。特にプラグインまわりを作れるようになると良い。

 コンシューマ方面に進むつもりなら、次の項のC++以降の実践に進もう。コンシューマでの作業は基本的にC++になる。

C++を使おう=

 コンシューマ業界(大雑把に言えば3DSとかPS4とかのゲームを作る業界)で働く場合、C++を使えるようになっておこう。

 最近は普通のCを使う必要性はかなり薄いし、必要だったとしても新人に回ってくるタイプの仕事ではない。
 また、Unityで使うC#は特に携帯ゲーム機などではオーバースペックでまだ使いづらいのでC++がもうしばらくは基本になるだろう。

 一応、ツールとしてRubyPerlが使えると嬉しい場面はある。ただ、これも新人にそれほど期待されるものではないから「個人でゲームを作っててツールが欲しくなった時」に調べて作るくらいで十分だろう。(軽く言ってるけど実際に個人でやろうと思うと結構重い作業になる)

 あとはMakefileの書式を知っていると良いのだが、個人開発の規模だと使っても効率はそれほど上がらないので会社に入ってからでも十分だと思う。

 なので、基本的にはC++さえ使えればそれで良いと思う。必要とされるレベルは「C++と既存のゲームライブラリで一人で小さいゲームが作れる」くらい。C++そのもののレベルで言えば以下の書籍で「書かれている意味が分かる」くらいのレベル。欲を言えば実践もできて欲しいが、constとかをちゃんと使うのはゲームライブラリの制作時とかだったりするし、全部ちゃんと実践する機会を個人で得るのはわりと難しいのでそこまでムリする必要はない。


 一応、最新版は下のものらしいけど、自分は確認してないし上の本でもひとまずは十分だと思う。



=ゲームライブラリは使おう=

 C++でゲームを作るならゲームライブラリはできるだけ使おう。

 DirectXを直接使っても良いが、基本的には「ゲーム用のコードを他の人が代わりに書いてくれたもの=ゲームライブラリ」の方を使おう。間違っても自分みたいにWindowsAPIを直接使うような事は避けた方が良い。OSに近い部分の動作を理解する事も多少は重要だが、新人に期待される分野ではないしWindows固有の問題などが多かったりして効率は良くない。

 大抵のゲーム会社は内製のゲームライブラリを持っているから、直接的な画像表示の操作よりもゲームライブラリを扱う事の方が多い。なので、ゲームライブラリに慣れておく事もそれなりの重要度がある。

 ゲームライブラリの導入もそれなりに最初はコストが高い作業だが、ライブラリを自作するよりはずっとマシだと思う。それでも複数のライブラリを導入するとコストが高くなると思うので、「画像の表示」や「サウンドの再生」などが一つにまとまっているライブラリを探すと良い。

 C++でやるならまずは2Dのゲームを作るのが良い。3Dだと「XXが表示されない」といった場合に2Dと比べてカメラの設定やシェーダまわりなどの要素が入ってくるためプロでもわりとめんどくさい。

 ある程度慣れたら自分でもゲームライブラリを作れるようになると良いが、最初は「ゲームライブラリを作れる<ゲームライブラリに慣れる」という優先度の方が良いと思う。

 ゲームに必要な基本要素に関しては以下の本が役に立つかもしれない。内容としては「C++で2Dゲームと3Dゲームを作るための最低限の知識と実践」についての本。最低限のわりにとても分厚いので色々と注意。この内容を一通り網羅するゲームライブラリを探すか、これを元にゲームライブラリから作っていく感じで使えると思う。

=フリー素材も使おう=

 ゲームを作る場合、最初は画像や音声などのデータはできるだけフリー素材を使おう。

 「画像を自分で作ってグラフィッカーの人の作業を想定できるようになる」という成長パターンを考える事もあるかもしれないが、少なくとも最初はそこまで考える必要はない。新人にはそこまで期待されていないというのもあるし、ここらへんの作業は素人がやると本当に時間がかかるのでゲーム作成の時間自体が圧迫されてしまう。だからまずはできるだけフリー素材でゲームを組み立てよう。素材を入れて「自分が考えたゲームとはなんか雰囲気が違う」となってもまずはフリー素材で我慢しよう。

 その他にもラクできる部分はできるだけラクをしよう。実際に会社でやる作業も画像などは他の人が用意するものだ。企画の人に何か提案したりグラフィッカー用のツールを用意するために相手の作業を理解する必要はそれなりに出てくるが、少なくとも最初のゲームを完成させるまでは考える必要はない。相手の事を考える前に、まずは自分に求められている作業をちゃんとこなせるようにしよう。(ちゃんとこなせるようになったら考えていきたいところだが)

=できればVisualStudioも使おう=

 コンシューマではVisualStudioを使うのが一般的なので、無料ので良いからできれば慣れておこう。

 特に慣れておきたいのは「VisualStudio上でのコーディング〜ビルドのやり方」と「VisualStudioでのデバッグの仕方」あたり。デバッグの方は「ブレイクポイントをおいて値をチェックする方法」や「ハングした時のコールスタックや変数の見方」あたり。

 自分はコンソールでのビルド上がりの人間なのであまり詳しい事は言えないけど、コンソールよりはVisualStudioに慣れておいた方が良いと思う。(コンソールも使うのでコンソールの方も余裕があれば慣れておきたい)

=新人に期待されるもの=

 基本的には新人には大した事は期待されていない。場合によってはゲーム開発の経験自体も期待されてなかったりするし、大手であればゲーム開発の基礎から教えてもらえるところもある。ただし、プログラミング言語自体は前述のレベルくらいにはC++に慣れている事が期待されていると思う。

 具体的に割り振られる作業としては「量産」的なものが多いんじゃないかと思う。アクションゲームでいえば「色んな種類のザコ敵」とか「色んな種類のギミック」とか。RPGでいえば「ストーリーの一部」とか「色んな種類のギミック」とか。1〜2年目でも「アクションゲームのボス」を任される事は珍しくない。

 そういう「ゲームの目立つ部分」を任されるのは少々意外かもしれないが、そういう目立つ場所だからこそ上の人がチェックしやすかったり、量産する部分だから慣れによって新人でも品質の向上が見込めたりするのでむしろ妥当な割り振りになる。だから例えば面接とかで「ゲームのどの部分を作りたいですか?」と言われて「(ギミックとか作りたいんだけど目立つ部分だから競争が激しいかなぁ)」などと遠慮する必要はない。むしろ「システムをやりたいです」と言われても新人にいきなり影響の大きい部分は任せづらいからそっちの方が採用されづらかったりする。なので、そこらへんは素直にやりたいパートを言おう。

 あとは新人に対しては「わからない事は訊く」というのがわりと期待されている。別の言い方をすれば「早く使い物になる」事が期待されている。確認のために他のプログラマーの時間が数分奪われる事より、わからない部分でダラダラされて数日とか数ヶ月とか成長が遅れる方が全体としては困る。しかし「わからないから訊く」というのは言うほど簡単ではないだろう。とりあえずの目安としては「10分考えてもわからなかった」時に訊くと時間のバランス的には良いし、時間を決めておけばふんぎりもつきやすいのではないかと思う。ただ、考えるだけじゃなくてコードを実際に見て調査する事もあるかと思う。その場合は10分では足りないかもしれないが、それでも1時間以上はかけない方が良いと思う。質問するための文章を事前に考えるようにすると、質問もスムーズにできるし質問を考える過程で答がわかったりするのでお勧め。

 これは新人に限らない事ではあるが、「ユーザとしての感覚」はできるだけ大事にして欲しい。初心者の時は「これは使いづらい」「これはわかりにくい」という感覚をちゃんとユーザとして認識しやすいが、会社でプログラマーとして働くにつれてこの感性は劣化していく。本当にびっくりするくらい劣化していく。だから意識して「ちゃんと自分はユーザとしての感覚を持てているか」というのは定期的に確認して欲しいし、一番ユーザに近い新人としてその感覚をできれば開発の方にも役立てて欲しい。

=会社での担当の分担について=

 会社でのプログラマーの担当は大まかに「ゲーム」「UI」「システム」「ネットワーク」に分かれると思う。

 「ゲーム」はアクションゲームであればさらに「ギミック」「ザコ敵」「ボス」あたりで担当が分かれる(兼任もわりとある)。
 「UI」はいわゆる「メニュー」まわりの対応を行い、ゲームに応じて「ゲーム中のゲージ表示」や「ステータス確認」など2Dでの情報表示まわりの対応を一通り担当する。
 「システム」は簡単に言えばゲームライブラリを作る。上記のようなゲーム・UIとゲーム機の両方に精通している必要があるため、ある程度の経験者が割り当てられる事が多い。
 「ネットワーク」はその名の通り通信まわりを担当する。ゲームのマルチプレイであったり、ゲーム機によっては「すれちがい通信」なども担当するかもしれない。

 新人が割り当てられるのは「ゲーム」か「UI」が多いと思う。経歴(大学とか独学とかで学んだ量)によっては他の分野になるかもしれないが。

=コミュニケーション能力の測られ方について=

 よく言われる事ではあるが、プログラマーでもコミュニケーション能力はある程度求められる。渡された仕様に沿って作業するだけでなく、モデル・モーション・エフェクト・SE・BGMなどを組み込む都合でグラフィッカーやサウンドの人とやりとりする事がそれなりにある。

 そのため、採用の際はここらへんの能力も考慮されるのだが、これは面接でのやりとりだけでなく「集団でゲームを作成した事があるか」や「(ゲームなどに限らず)バイトをした事があるか」も考慮される。自分は「バイトをした事がないから」という理由で落とされかけた事があるので、接客業とかでなくても良いのでなんらかのバイトは経験しておいた方が良いかもしれない。(理想は集団でのゲーム制作経験だが)

 ちなみにここでいうコミュニケーション能力とは「明朗快活に自ら話しかける能力」などではなく、「相手が伝えたい事を理解し、相手が欲している内容を理解し、こちらが伝えたい事を的確に伝える能力」を指す。雑談の能力ではなく、「伝わる文章」とかそういう方向の能力。

=その他の細かい事について=

 ブラインドタッチとかは別にできる必要はない。毎日プログラミングする事になるから、そこらへんの能力は勝手に上がっていく(3年もすれば普通にできるんじゃないかと思う)。それよりはデバッグなどでムダに時間を取られないように設計能力の方を上げておく方が望ましい。ただ、プロでもバグがそれなりに出るものなので神経質に「バグが0じゃない時があるからダメだ」とか思わなくても良い。あくまで優先順位が「タイピング速度<設計能力」というだけの話。

 テキストエディタはだいたい自由なものを選べる。会社によっては秀丸などの購入も検討してくれる。体感的にはEmacsを使ってる人が多い。ちなみに自分はサクラエディタを使っている(マクロの設定や文字コードの変換などがラクで良い)。

 仕事してる人の99%は私服。なので面接時に「スーツでなくて良い」と言われたら本当にスーツじゃなくて良いと思う。それでも新卒だとスーツで来る人が多いので、心配でしょうがないなら別にスーツでも良い。ただ、その場合は「次は私服で来ていいからね」と言われるし、転職の際はまずスーツを着ないので「面接の時にしか使わないスーツにお金を払う余裕があるか?」とかで考えても良いかもしれない。

=面談について=

 面談で訊かれるのは基本的に「今まで何をしてきたか(大学なら研究内容、開発経験があればその内容や担当パート)」「その会社に応募した理由」「ゲームのどのパートをやりたいか(ゲーム本体、UI、ネットワークなど)」「どのゲーム機での開発がしたいか」「得意な事・不得意な事」「趣味(土日にやる事や興味を持っている事など)」あたり。後は最後に「何か訊いておきたい事はあるか」という質問があったり。

 プログラマーを雇う側として期待しているのは「ゲームを作る能力がどの程度あるか」と「一緒に仕事ができるか(コミュニケーション能力に支障がないかなど)」がメイン。あとは実際に雇う時のために「どのパートを希望するか〜どのパートに向いていそうか」あたり。質問は基本的にここらへんを確認するために行われる。

 特に新卒であれば「緊張していて当たり前」なので「緊張してロレツが回らない」というのはそれほど悪印象にはならない。ただ、「ロレツが回らないから伝える事そのものを諦める」となると前述のコミュニケーション能力がないと判断されるかもしれないので、どんなに不格好でもちゃんと情報を伝えようとはしよう。


=会社の合う・合わない=

 ゲーム会社は転職の多い業界である。なので、「今の会社は合わない」と感じたら普通に転職して良いと思う。だから入る際もそこそこ気軽にいって良いと思う。

 「合う・合わない」という言い方だとわかりづらいかもしれないので別の言い方をすると、「今のような働き方をずっとしていく自信があるか?」「上の人達のような生き方を将来する気があるか?」という問いにYesと答えられるか?という事。

 新人が転職する場合、「最初のプロジェクト」だけは完遂しておいた方が良いかもしれない。就職情報を見てるとわかるかと思うが、「経験者のみ」という条件はかなり多く、転職を考えるとプロジェクトを途中で放り出すのは結構リスクが高い。
 それでも「プロジェクトの終わりまでもたない」と思ったなら転職をお勧めする。肉体的・精神的な負荷で働けなくなっては意味がない。ハズレのプロジェクトはまだ存在し、それで鬱になったり体を壊す人間も居る。新人だとそこらへんの区別は難しいかもしれないが、そういう場合はさっきのように「プロジェクトの終わりまでもつか」「今のような働き方をずっとやっていけるか」とか「他の人達が鬱や不調で離脱してないか」などに気をつけていれば区別できるようになっていくかと思う。
 ゲーム関係の人材は慢性的に不足しているので、転職そのものにはさして困らないと思う。(需要と供給の内容=担当パートが一致しない可能性はあるが、それは後からの学習で埋める事もできるし)

 一応、ブラックっぽい会社かどうかの見分け方としては「発売延期をするゲームが多い会社か」というのが多少は参考になるかもしれない。「その会社で発売延期が多い」というのは「その会社はマネジメントが上手く設計されていない」という可能性が高いからだ。あくまで目安にすぎないが。他には「離職率が他より高い(継続年数が短い)」とか「大規模リストラがある」とかもあるが、これもまたあくまで目安。実際のところは入ってみないとわからない。(自分もまだそんなに多くの会社を見たことがあるわけではないし)

 ちなみに残業そのものは珍しくないが、聞いてた話よりはずっと良いし、そもそも新人はあまり残業するものではない。というか「新人が残業してるのに自分(他の先輩プログラマー)が帰るのは精神的にキツい」とかあるので、急ぎの作業がないなら早く帰ろう。新人の段階で残業が要請されるならブラックを疑おう。

 参考までに自分はいま4つ目の会社で、ここ2年くらいは(ROMとかで忙しい時期以外)ほぼ定時で帰宅している。(定時帰宅の方は珍しいかもしれない)

=改めて最低ラインと優先度について=

 ここまでの話をまとめると、(コンシューマ向けの)新人に求められる中で一番優先度が高いのは「C++を前述の本の内容が理解できる程度には使える事」。その次にこちらもそこそこ高い優先度で「ゲームを一つでも完成させた経験がある事」。個人的にはこの2つが新人に求められる現実的な最低ラインだと思う。

 その次が「コミュニケーション能力」、具体的には「他の人とゲームを作った事がある or バイトをした事がある」という部分。これは最低ラインとまでは言えないが、これらの経験がないと落とされる可能性もあるので注意が必要。

 それ以外はほぼ同程度の優先度と言って良い。なので、上記以外の学習は「これはラクにできる」とか「これは楽しめる」とかそういう判断基準で決めて進めていって良いと思う。具体的には「2つ以上ゲームを作る」「ゲームライブラリを作る」「ツールを作る」「VisualStudioが使える」「グラフィックや企画などの作業をした事がある」などは優先度の差異が大してないので、やりやすいもの・やりたいものをやっていけば良い。「やりやすい事をやるのは怠けなのでは?」と思うかもしれないが、「やりやすい事」はわりと「その人の得意な事」である事が多いのでそこまで気にしなくて良い。むしろ「これがやりやすいって事は自分が得意なのはこれなのか」という風に考えて応用していくのが良いと思う。


=それでも不安な人へ=

 ここまで色々と書いてきたが、まだ不安な事は多いだろう。というより、情報だけで不安が解消されるのはレアケースとも言える。

 ここらへんは経験を重ねていくしかない。前述の通りゲーム業界の人間は転職が多いが、その転職の際もまだこの手の技量の不安はつきまとう。それでも「自分はこれができる」というものを積み重ねていく事で少しずつ不安がマシになっていくのだと思う。

 特に「ゲームを一本完成させる」というのは他でも言われている通りとても重要だ。たとえばUnityで一本ゲームが作れれば、それを個人で売る事もできる。つまり「ゲームを一本完成させる」というのは「ゲームを売るまでの最低限の作業が一通りできる」という事だし、「会社に行かなくても食っていける可能性がある」という事だ。まずはこの状態になるのが重要だし、この状態になれれば不安はそこそこマシになるんじゃないかと思う。

=後書き=

 もともとはTwitterで「ゲームプログラマーになりたいならすでに行動を始めてるはずだ」という旨の文章を見かけたのが発端で、昔の自分は行動しようにもその方向の妥当性が検証できずにずっと右往左往したうえに紆余曲折していたなぁと思ったので今回みたいな情報を書いてみた。さっきの対偶は「行動を始めてないならゲームプログラマーになりたくない」という事になるが、少なくとも自分はこれに当てはまらなかったのでちゃんと反論的なものを書いておきたかった。

 特に自分の場合は作業の優先度が付けられず、何をすべきかの調査で時間がかかったうえ良い情報がなかったので結局迷走する事になってしまった。だから今回のエントリで迷走を避けられる人が一人でも増えれば良いなーと思っている。(WindowsAPIを触る方向は本当に遠回りだった)

 いまどきゲームプログラマーになりたいという人がどれくらい居るのかはわからないが、「行動ができない人はこういう事を考えててこういう風に方向を示して欲しいんだ」という意味でも文章は書いておきたかったのでこれはこれで良いのかな。たぶんワナビなら文章を書く人にせよ歌う人にせよ同じように「数をこなすのが良いのか質を考えるのが良いのか」「何か技法を学んだ方が良いのか」「そもそもどんな技法があるのか」「機材とかなんか揃えた方が良いのか」「求められる最低ラインは?」「それぞれの優先度は?」とか似たような感じで方向性や優先度が決められずに迷っている人が多いんじゃないかと思う。優先度や方向性は「すでにできてる人」からしたらわりと自明だけど、初学者にはさっぱりわからないし。他の分野でも「初心者ではわからない自明な優先度」の情報が増えると良いなーと思う。初心者は「どう訊けば良いのか」の段階で躓くものだし。