■ [開発][プログラミング]ゲーム開発における最適化の優先度 
ゲーム開発において最適化をどの程度優先して行うべきかという問題は，結論を出すことの難しい項目となっているように思える。 XP のような開発手法が最適化を「二の次」に回しているのは，単に，それが許されるという前提が存在しているからに他ならない。ゲーム開発の場合には，その前提が必ずしも成り立つとは思えないというのが，個人的な見解だ。
ゲームの場合は，プログラムの開発と平行して，素材の制作やゲームデザインの構築なども行わなくてはならない。その過程において，パフォーマンスの問題は非常に重要な検討項目となりうる。例えば，「ポリゴンが何枚出るか」などと言う項目は，アーティストにとって重要な項目であるし，また，「キャラクタが何体出るか」などと言う項目は，ゲームデザインにおいて重要な項目となる。
もうひとつ，ゲーム開発において最適化を前倒しにしなくてはならない理由として，最適化を後回しにすることによって生じるコストの問題がある。これまでに述べたように，ゲーム開発においては，プログラムの開発と平行してコンテンツの作成が行われる。そのため，これらのコンテンツに対して影響を与えるような変更が行われる場合，既に作成されたコンテンツの量に比例して追加のコストが発生する。したがって，最適化を制作工程の最後に回してしまう行為は，最適化に必要とされるコストを最大にまで高めてしまう危険性を伴っていると考えることができる。
以上のことをまとめると，試作の段階において最適化が完了しているという状態が，最も理想的な姿であるように思える。これは，実際にはほぼ不可能であるものの，ゲームのビジュアル・コンセプトやデザインの骨格を試作の段階において確定させなければならないとすれば，パフォーマンスはそれらの要素を裏付ける「根拠」として固まっていなければならないはずだ。そうでなければ，最終的に予想していたほどのパフォーマンスが得られなかったばかりに，ビジュアルやゲームデザインを大きく変動させなければならない事態へと陥ってしまうかもしれない。
最適化をするときにはチーム全体でかかるコストを最小限にし、クオリティを最大限に上げられるように優先度を考えて行う必要がある。
■ [開発]ゲームが「完成するまで完成に見えない」という現象 
このような「完成するまで完成に見えない」という現象は，プロジェクトの進捗の把握を難しくする働きを持っている。部品は確実に揃い始めているにもかかわらず，制作者達の視点から見てみれば，いつまでたっても終わりが見えてこない。そして，本当の「終わり」が実感できるような段階に達するまで，うっすらとした焦燥感にさらされ続けることになる。
この現象は，開発チームの規模が膨らめば膨らむほど，長く強いものとなる。一般に，規模の大きなチームほど作業の並列性が高くなるためだ。
「最後の瞬間に全てが揃う」という状態は，良いスケジューリングの徴候であると言うことができる。例えば，あるゲームに１２のステージがあるとしたら，それを完成させるための最も早い手立ては，１２人のステージデザイナを雇うことだ。これは，最も効率的な方法ではないけれど，最も早いのは事実だ。しかしこの方法では，その全てが出来上がるときまで，作業の進み具合を実感することはできないだろう。
この Dead Zone 現象に対して Fristrom 氏が述べている助言は，ひたすらスケジューリングを厳密に行うことだ。適切なマイルストーンを設け，定期的に進捗の確認を行い，製品の見た目から伝わってくる部分によって進捗を「感じる」のではなく，データとして進捗を「分析」できるようにしておかなければならない。それさえ上手く働いていれば，完成の時期に関して確信を持つことができるし，あるいは，間に合いそうもない部分の削り落としに着手することもできる。
実際のゲーム開発でも、小学生の夏休みの宿題のように最後のごく短い期間に一気に進捗が進むような作り方になってしまうことは多いのだろうけれど、個人的には『「最後の瞬間に全てが揃う」という状態は，良いスケジューリングの徴候である』という部分には賛成できない。
チームを運営するに当たって、完成を見越した厳密なスケジューリングも大切だけど、それ以上に各員のモチベーションを維持することも、作業を円滑に進めるための重要な要素であるように思う。
特に新規タイトルにおいて顕著な現象だけど、いつまで経ってもゲームの形が見えず、どんなものになるのかわからないままに暗中模索の状態でズルズルと時間だけが経ってしまう状況になると作業者のモチベーションも上がりにくく、チームの雰囲気も悪くなりやすい。逆に、チーム全体のモチベーションが高ければ驚くほどの短期間で一気にクオリティが向上することもある。
モチベーション高めるための方策はチームの運営者によってさまざまだろうけれど、「自分の作っているものが最終的にどんな風に使われるのかわからないけれど、とりあえずスケジュールどおりに進んでいる」という安心感よりも、できるだけ早い時期に小さいパッケージでもいいからゲームの基本的な流れをしっかり組み立てることによって、チーム全員が「このゲームはきっと面白いものになる！」と実感できるようにしていく方が、モチベーションを高め、最終的なそのゲームのクオリティを上げるための効果が高いのではないかと思っている。
■ はてなワンワンワールドのシステムを使った妄想ネタ 
http://b.hatena.ne.jp/entry/http://world.hatelabo.jp/
- 『はてなワンワンワールド大戦略（仮）』
- プレイヤーは東軍と西軍のどちらかに所属し、それぞれ東京と大阪を本拠地とする。
- 日本全国に数10Km間隔でそれぞれの陣営の砲台が設置されていて、名古屋あたりを境に、東軍の砲台は青、西軍の砲台は赤、と色分けされている。
- 砲弾を敵砲台に命中させることで、敵砲台を破壊できる。また、砲弾の爆風に巻き込まれたプレイヤーは、一定期間攻撃に参加できなくなる。
- 破壊されてしまった砲台は、翌日に本拠地近くに再セットされる。本拠地の近くでチャットすることによって、再セットまでの時間を加速することができる。
- 敵の本拠地を先に破壊したチームの勝利。
こんなルールで面白いかどうかはともかく、このくらいならワンワンワールドが実現可能なら比較的簡単に実装できそうな。たくさんチャットして話が弾むほど自軍が有利になるような仕組みにしていくのが好ましいのだろう。ZOCの概念や、人力で砲弾を運ぶ兵站の要素を追加してみるのはどうかとも思ったけど、話がややこしくなるだけか。
