ユーザーはコードに金を出さない、商品に金を出す
著者: 増野 宏之これから説明する内容は、私の過去の経験と私見に基づいた、きわめて実践的なお話です。おそらく、総製作費が億の桁になるような巨大なプロジェクトチームで制作される大規模なゲームには、当てはまらないと思います。でも、最近注目されている、インディーゲームのように、小規模・少人数でゲームを制作するときには、心にとめてもらえると嬉しい内容だったりします。
ゲーム制作におけるプログラマーとしての心得
最近のゲーム制作は、豊富なフレームワーク、便利なツールあるいは、多機能なミドルウェアの登場によって、絵描き屋さん（グラフィッカー）や、音屋さん（サウンドデザイナー）が、ゲームの演出を制御することが多くなり、プログラマー自身がゲーム制作作業の全体に占める割合は段々少なくなってきています。
しかしながら、実際の製作現場において、ゲームの最終的な流れを決定するのは、やはりプログラマーであり、その結果、プログラマーが作品制作の上で大きな権限を持っている場合が少なくありません。プログラマーは、いまだ極めて重要な立場にあるのです。そもそもゲーム制作における、プログラマーの仕事は何でしょうか？
それは、あらかじめ決まった（時には自分で決めた）仕様に従って、ゲームの流れをプログラムし、ゲームを完成させることです。ところがその目的を忘れ、自分の技巧を凝らしたプログラムを書きたいだけの自己満足プログラマーになってしまうと、いろいろと不幸なことが起こってしまいます。
@@ プログラマー起源のデスマーチはなぜ発生するのか？
私は過去約25 年にわたり、音楽作曲・メインプログラマー・プロジェクト管理・海外渉外・契約業務など、おおよそゲーム制作に関わるほぼ全ての職種をこなしてきました。その経歴の中で、一時期「炎上中のゲームプロジェクトの火消し係」を担当していた時期がありました。いわゆる、「炎上中のプロジェクトのメインプログラマーのアシスト（代替）」という仕事です。そんな経験から、「炎上しやすいプロジェクト」の特徴というのが、わかってきました。それは……* マルチプラットフォーム対応（3 機種以上）* 仕様変更にも柔軟に対応できるゲームシステム* 高度に抽象化されたオブジェクト指向プログラミングによる、多人数での効率的なゲーム開発。
これ、ゲーム制作としては理想的ですよね！
でも、今まで「炎上したプロジェクト」全てに共通する謳い文句だったのです。
素晴らしい理想も、完遂しなければただの瓦礫
上記の3 つの謳い文句、ちゃんと実現できれば、素晴らしいゲームが完成するでしょう。
ところが、これを完遂しようと思うと、特にプログラマーには、並々ならぬ努力が強いられることになります。* あまりにゲームシステムを柔軟に作ってしまったがために、仕様変更の嵐で、プログラムの中身がぐちゃぐちゃになっちゃった……* マスター前の徹夜続きのため、プログラマー自身が、自分のクラスが何を抽象化したのかわからなくなっちゃった……* いつまでも部品ばかりを作り、ゲーム全体の設計が全然できないまま、納期まであと1 ヶ月になっちゃった……という悲しい状況に陥ったプロジェクトをいくつも見てきました。
まさに「理想は高かったけど、出来上がったものは、ただの瓦礫」という状態です。いや、瓦礫でも出来上がれば良いですが、瓦礫すら出来ない状況も、多数見かけました。
プログラマーの人数が増えるとバグが指数的に増える
複数人のプログラマーでゲームを作る場合、お互いの役割分担を明確にしないと、最終的にバグのオンパレードになります。ほとんどのバグは、違う人が書いたプログラムの間で発生します。こういっては元も子もないのですが、結局プログラムは1 人で書くのが一番早いのです。「最初から1 人で作っていたほうが、結局早くできていたよね～」というプロジェクトもたくさんありました。
命名規約や抽象化などのルールを決める前に、どんなに汚く、第三者から見たら笑われるようなコードであっても、早く実装して動かし、完成させた人の勝ちなのです。
年寄りからの格言
特にインディーゲームの製作の方に：規模にもよりますが、チーム内のプログラマーはできるだけ1 人にして、その上で制作スケジュールを組みましょう。
プログラマーの方に：コードに凝る前に、汚く幼稚なコードでもいいから、まず書いて動かしてみましょう。どんな汚いコードでも、コンパイルしてしまえばわかりません。
お客さん（ユーザー）はあなたの書いたソースコードに金を出さないのです。
あなたの作った商品（ゲーム）に金を出すのですから。