今回はその中で成長要素をメインにすえます。収集要素はグラフィック負荷が滅茶苦茶高いんで、あまり推せません。ストーリー要素は......きっとうちのシナリオライターが喜んでサビ残参入してくれる事を期待するくらいしかありません(チラッチラッでもって最近の成長要素は「合成」「進化」なんてものがメインにありますが、絵の負担が大きいものは無し。魔法を強化プレイヤーキャラクターを強化ここらへんがメインになりますです。魔法を強化するのは、「ルーン合成」という仕様で表現。モンスターとかキャラクターを合成する仕様にすると、グラフィック工数が増えてしまうので「ルーン」でそこらへんを圧縮。仕様書を見る限り......すごく合成です。成長要素にゲーム性を加えるプレイヤーキャラクターの成長はレベルアップ。得られたスキルポイントを消費してスキルをゲットするタイプ。スキルはゲットすると分岐があらわれて次にゲットするスキルを選ぶ。所謂「スキルツリー」のシステム。レベルアップで何のスキルをとって次のステージに挑むかを悩むゲーム性。成長要素にゲーム性を組み込んでいるスキルツリーのシステムは、結構私は好きです。Tanks遊んでるんで、戦車の進化ツリーを見てワクワクするのが楽しみになっております。KV-1Sが強かろうがKV-2選ぶのがロマン。成長要素で選択要素を加えるシステムで装備のシステムがメジャーかな。どの武器や鎧を買うかで悩む。この場合、武器や鎧にはお金というリソースが必要。リソースを消費してコストに見合う成長を選ぶのが悩みどころ。購入しなくとも、装備スロットに限度があるから、スロット限度以内で装備をマネジメントするゲーム性が生まれますです。この装備のシステムはやはり膨大なデータが必要でして、グラフィックだけでなく装備の性能やフレーバーテキストに多大なデータが要求されます。選択肢も無限大なんでゲームバランスをとるのが一苦労だったりしますです。なんで結構スキルツリーはお財布に優しいシステムなのでは、と思ったりします。19:56)開発の日常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オンリーなんて、なかなかスパルタンなスクリプトだなと思いますですよ。20:12)開発の日常takech_[prd]:komeさんkome[pln]:なんでしょうかtakech_[prd]:何か面白い事言ってくださいkome[pln]:ないですtakech_[prd]:チッ......kome[pln]:舌打ちしないでください!うちは企画会社なんで、企画について色々と書きたいんですけどね。プランナーさんが非協力的なんですよ(チラッできれば「私はこんな事考えながら仕様書書いてます!」みたいな事が欲しいんですが。l_eye[dir]:まあ私が考えたゲームのイメージをほぼ忠実に書類に起こしてくれてますからね。いう事なんで、ディレクターにとってありがたい存在ではあるようです。各仕様についてのポイントとかも書きたいんですが、何か聞きづらい。このブログを書く為に色々聞きたいんですが、仕事の邪魔しちゃいけない気もするし。そもそもコミュ障だし私。ブログいいかもただ、このブログやっててよかったなと思う事は、プロデューサーなのに今作ってるゲームについて色々理解が深まる事ですね。してもプロデューサー目線だと「売り」について考えは行くんですが、コンテンツそのものの良さとかは二の次になりかねないし、あまつさえそのコンテンツの良さを売りにする事が出来ないようになっちゃうとかありかねないんですよね。してもキャスティングを売りにしたくなっちゃったりしますですよ。できればコンテンツの中身をちゃんとプロデュースできた方が良いに決まってますから。なんで、今WizBookの中身についてかなり目を通す毎日です。どこをアピールできるかを毎日探してます。ブログのネタにできますから。ブログのネタ欲しさにコンテンツの中身を漁るという効果がありますです。