1.3面倒なこと
1.3
面倒なこと
ゲームコーディングを流動的で予測不可能な仕事にする要素はたくさんある。ゲームの開発中、開発チーム内外のいろいろな要素か要因となり、設計か大きく変わることは珍しいことではない。実裝スケジュールのずれや制作上のプレッシャーがつのると、ゲームプロジェ外トの世界で旨にいう「クランチモード」に階る。Directxのような開発時に飲存するソフトウェアツールは絶えず变化し、ソフトウェアチームはついていくのに苦労する。またソフトウェアプロジェクトとは達って、ゲームはきまざまなOS、グラフィックスAPI、プラットフォームをサポートしなければならないこ
とか多い。
1.3.1 動く標的を附る
産業用ソフトウェアプロジェクトは慎重に設計され計画されることが多い。システムアナリスト
は、コードの1行目が書かれる何力月も前から、顧客の要望、以前のバージョンのソフトウェアの事例研究、有望なアーキテクチャについて研究する。だが「ウルティマVIUのアーキテクチャは、ある日の午後、7人のプログラマがホワイトポードを囲んで話し合って決めた。
アーキテクチャについては、「面白さ」で設計することはできない。面白いものとは「微調整できる」(tweakable)ものであって、設計文書とは相 容れない。最初の設計で面白いゲームができればそれに越したことはないか、最初に出来上かったゲームからは、チリパウダーがもう少しとコン口にかける時間ももう少し必要だという印象をはっきりと持たせられることが多い。つまり、まだまだ調整が足りないのだ。
設計全体をやり直すこともある。「ウルティマIX」のアーキテクチャとゲーム設計は開発中に少なくとも3回は変更された。私はそのうちの2回には関わったが、3回目は関わらなかった。ゲーム開発か何年にもわたる場合、 その間に新しいハードウェア技術か次から次へと出てくることはよくある。「ウルティマIX」の場合、これまで書かれた中で最高のソフトウェアラスタライザになるはずだったラスタライザの最終仕上げ段階に入ったとき、3Dアクセラレーテッドビデオカードか登場した。結局私たちのソフトウェアラスタライザは日の目を見ることはなかった。
週なだけのゲームになることもある
「ウルティマVI」のマップ設計には、ハプアンドスポーク方式を採用した。ハプは他のすべてのマップに整がる地下牢にした。ゲームをQAに渡すと、まったくつまらないという言業が選ってきた。その犯人は弱な中心マップだった。あたりを数人の悪党がうろつく地下の迷路にすさなかったからた。2人のテザイナーが髪夜働き、中心マップを変更した。新たに加えたバズル、買、t物などがちよっとしたスバイスになって、中心マップは結局ゲーム全体の中でも最も優れた部分の1つになった。
17