開発の日常

kome:ルート分岐はあまり多くないようにしたいと思います。

takech:ループとか分岐が重なったりはします？

l_eye:しません

kome:分岐は1ダンジョン中10くらいですまそうと思います

takech:え？大丈夫？

kome:え？

l_eye:2の10乗だけゴールがあるよ？

kome:......(30秒後)......無しですわ！

スクリプト仕様を作る

ダンジョンスクリプトの設計をします。

プランナーがダンジョンのフロアを設計してプログラマーが実装するようなワークフローにすると、細かいゲームや特殊仕様を入れたりできるので、大変バラエティ豊かなダンジョンにはなるのですが、それやっちゃうと多分ゲームで遊べるダンジョンが1つとか2つとか、大変しょぼい数になっちゃいます。

あとバランスデザインするのにプログラマーさんの手を煩わせてしまうので、何かと面倒くさいし、多分つまらないゲームになります。

なのでゲームではステージデザインをするのにスクリプトが必要となります。

プランナーは自分で設計したダンジョンをスクリプトを使って自分で書きます。

プログラマーさんにはスクリプトを渡すだけなので、プログラマーさんは何もしなくていいので楽です。プランナーさんはテストプレイして勝手にバランスを試行錯誤できるのでとても楽です。

強いて言うなら、特殊仕様てんこ盛りなバラエティ豊かなダンジョンはできない事でしょうか。

例えば、強制バトル&負け確定の感動ストーリーが始まったりパズルゲームが始まったりとか。(まあ、そういうスクリプト仕様を作ればいいんですが、スクリプトの仕様が巨大になってプランナーさんが扱えないものになってしまう事も多々)

スクリプトはプログラマーさんではなく、プランナーさんが扱うってところがミソでして、ゲームデザインしやすい言語や構造にする事が大切ですです。

たまに「C言語が使える事必須」とか「アセンブラが使えれば扱えるスクリプト」とかを見たりしますが、「そんなだったら素直にプログラム組みますわ」となりますです。

WizBookでのスクリプト

今回はcsvファイルの組み合わせによるスクリプトシステムです。

takech_[prd]:csvの組み合わせにした理由は何でだぜ？

kome[pln]:プログラマーさんとやりとりしやすいのと、デザインしやすいようにしました

takech_[prd]:ほむほむ。プログラマーさんにとってはほぼデータそのものみたいなもんだしね。カラム加えれば追加仕様も楽ちんってとこか。関数作って記述するスタイルだと、追加仕様の時に手間がかかるもんね。

スクリプトもゲームの仕様や開発様式によってスタイルがかなり違うですね。

正直WizBookのスクリプトは初見はただのデータじゃね？って気がするんですが、実際のゲームと開発に最適化されたスタイルだとするならばcsvオンリーなんて、なかなかスパルタンなスクリプトだなと思いますですよ。