http://www.nintendo.co.jp/wii/interview/smnj/vol2/index4.html
初代スーパーマリオ作成中の逸話。
いろいろすげーな、と思わされる。
最近ゲーム作ってて、特に気をつけてるトコロは、
「いかにはやく企画者にリターンを返すか」って部分で、
設計的にそこが上手くやれると
いろいろ作業上楽になる、って思ってたりする。
「作りかけのゲーム」って、たいていの場合、相当つまんねーし、
それを「どうやれば面白くなるか」ってのは、なかなか正解が出ない。
以前、ちょっと書いたけど 、ゲームデザインって物自体、
ほんのわずかな修正で一気に面白くなることもあるものだ。
だけど、その「カギ」となるポイントを見つけるのは相当難しい。
「その修正で問題は解決するのか？」
「もっといろいろいじったほうがいいんじゃないのか？」
は、調整中ずっとついてまわる問題だし、
実際、その疑問に完全に対処する方法はない。
だから、企画者が「こうしたい」っていったことに、
可能な限りリターンを早く返す。
実機でみないとわからんことなら、
なるべくはやく、それがわかるラインまで実装して、
企画者にみせる。
可能なら、そもそもプログラマが関わらずとも
プランナーが数字をいじるだけで
結果が確認できるようにしておく。
そもそも発注の時点で穴だらけなら、それを指摘し、
実装する前に直させる。
「企画とプログラムの間のこのサイクルを、開発中に何回まわせるか」が
ゲームシステムの設計をするプログラマの勝負のポイントで、
レベルデザインとかそういうゲームデザイン論が出てきたからこちらの
ゲームデザインの王道、といってもいいことだと思っている。
で、それが、一日一回しかデータが直せない、というサイクルだった、
というのも隔世の感があるし、
実際に動かす前から１ステージの画面がどれぐらいになるかが
おおよそつかめてた、ってのも「神業」の類だよなあ、とおもう。
もちろん、そんなことができたのは、作業期間そのものが長くとれる
ハードメーカーの強みだし、
その「神業」ができるひとでさえ、「ちゃぶ台返し」の伝説が
いくつも残ってるわけなんだから、
現状のデザイン方法は正しいんだ、ともおもうけど、
やっぱりすげーなー、と思わざるとえないなあ。ホント。