ゲームプログラマーと企画の未来

column

ゲームプログラマーとゲーム企画の未来 †

RPGツクールと仕様デザイン †

社内セッション　芸者東京（GTE） 開発の勝ち方をきっかけにまとめた、コンテンツ開発についての私的メモ

このブログが面白かったのでそれに触発されて書いた。多分、これから、ゲームプログラマは、ゲーム本体ではなく、ゲームツクールを作っていくことになるだろうし、ゲーム企画はそのツクールを使って、ゲームの企画を考えていくことになるだろう。

ゲーム開発は他のソフト開発に比べて、パラメーター調整の比重が大きい。

たとえば、RPGを例に考えよう。戦士のヒットポイントはどのくらいが妥当か？魔法使いの攻撃力はどのくらいが良いのか？戦士の初期ヒットポイントはいくらで、レベルが上がるたびにどのように増えていくのか？そのようなパラメーターを、ゲーム企画は、実際に試行錯誤しながら決めていく。

いままでは、企画の意図を、ゲームプログラマが読み取りプログラムに落としていっていた。そのため、リンク先にあるように、プログラマの負担が大きかった。

メタプログラミング †

ゲーム企画がある程度、プログラムが出来るようになれば、プログラマーの負担を減らせる。たとえば、pythonであれば、メタクラスを使うことで(作例:human.py)、プログラマーではない人がパラメーターの調整で、ゲームバランスを買えることが出来る。

作例で言えば、

ChHash['Fighter']=type('Fighter',(Human,),{'job':'Fighter','ita':'3D6','itl':'10D6','itq':'2D6'})
ChHash['Thief']=type('Thief',(Human,),{'job':'Thief','ita':'2D6','itl':'6D6','itq':'4D6'})

と言う風に書いていけば、戦士と盗賊の職業が動的に生成できるようになれば、プログラマの負担が減らせる(例中の2D6とかは、6面のさいころを、2回振って合計値を出すと言う意味)。 後は、実際にその戦士と盗賊を戦わせて見て、バランスを見る。

企画が、テストケース=仕様を書く日 †

上に見た例に付け加えて、企画がテストケース=仕様を書くと言うのが本当は望ましいのだろう。なぜなら、一番仕様に精通しているのは企画だからだ。

たとえば、この例(human_test01.py)みたいに、企画が自分自身で、テストケースをかければ、プログラマの仕様理解漏れや、実装漏れを素早くチェックすることが出来るようになる。

アジャイル開発が、いままでTDD(テスト駆動開発)と言っていたものを、BDD(ビヘイビア駆動開発)と言い換えようとしている背景には、企画が、プログラミングの一翼を担うと言う意識の変化に基づくものなのだろうと思う。

まあ、理想論なんですけど。 †

まあ、そうなったら良いなって感じの理想論なのですが、ゲーム制作の工程が複雑化していくと、なんとなくかんに頼ったと言う感じではなくて、パラメーターを、ベースに話し合ってくる必要が出てくるだろうなって思う次第です。

トップ