FC2ブログ

工房瓦版

創作関係の趣味ブログ

テストプレイをやりやすいように

 そろそろシステムとか、素材とかが揃いだしてきて、メインイベントだのサブイベントだのという実際に表立って演出される部分を作りはじめる段階に来た感じの昨今。
 イベント数が増えれば増えるほど、テストプレイが大事になると思うので、よりテストプレイをしやすくする機能はなんだろか?ってなことを悩み始めた。

 悩ましいのは、セーブデータの互換性をどうやって保ったらいいのだろう?という問題。
 ストーリーの途中まで自分で進めたデータをセーブしていても、次のテストプレイまでにいっぱいゲーム内のデータを弄ってしまうと、このセーブデータでロードしたらバグってしまう。
 そうすると、中盤のイベントを確認したいのに、そこが本当にちゃんと動作するかを見るためには、何回も一番最初から自分でプレイしなおさないといけないようになるのではないか?

 これは、いかにも余計な手間を踏んでいるように感じられる。
 長編作品作ってる現場はどういう風にテストプレイやってるんだろうなぁ。

 ☆☆☆
 例えば、ゲーム中のイベントフラグをいつでも任意にオンオフできる機能を作っておけば、最初から終盤状態でプレイできそうな気はする。
 しかし、あるイベントが実行される際に変更されるのはイベントフラグだけじゃないから、この部分から問題が生じかねない。例えば、イベント中にキーアイテムの「聖なる石を手に入れた」なんてのが挟まれる場合、イベントが起こったという情報だけじゃなくて、アイテムの所持状態も適当な物に変えないといけない。
 イベント中に変動が起こる変数には、色々なバリエーションがあり得る以上、単にフラグオンオフ機能だけつけても不十分な気がする。

 ☆☆☆
 あるいは、途中までプレイしたあるセーブデータをロードする際には、データセーブ時点からロード時までの間にゲームデータの変更ポイントがあるかどうかをチェックして、セーブデータを現行のゲームバージョンにそうように組み変える機能を挟む。
 これは作ってしまえば万事解決な気がするが、そうそううまく作り上げるのは難しい気がする。

 もしこの機能が本当にうまく作れたならば、ゲーム公開後に修正パッチ出した場合のセーブデータの互換性の問題もまとめて解決できそうではあるが……うーん。

コメント

セーブデータに互換を持たせてbuild跨いでもセーブデータを使えるようにする・・・というのはマスター候補製作時、開発後期であらゆる仕様がFixした状態の時には必ずやります。
仰っているとおり、修正パッチなどにも対応できますので。

マスター候補を製作する段階よりも前では仕様が二転三転することがあるため毎回調整している労力が無駄になりかねないですから、α~βの開発期間ではセーブデータの互換を持たせるようなことをしないのが定石ではないかなと思います。(うちでは定石です)

ただし、そうなると仰っている通り毎回一からプレイするのは時間がかかるため、デバッグコマンドの実装でα~β期間のチェック時は対処します。
進行系でしたら、仰っているように開放フラグのON/OFFをいつでも行えるようにしておき、進行度のフラグ開放だったり、クエストの部分開放/全開放だったり、アイテムだけ部分開放/全開放したりなど、様々な種類のものをチェックに時間を要するものから優先して実装していきます。


>例えば、ゲーム中のイベントフラグをいつでも任意にオンオフできる機能を作っておけば、最初から終盤状態でプレイできそうな気はする。
 しかし、あるイベントが実行される際に変更されるのはイベントフラグだけじゃないから、この部分から問題が生じかねない。例えば、イベント中にキーアイテムの「聖なる石を手に入れた」なんてのが挟まれる場合、イベントが起こったという情報だけじゃなくて、アイテムの所持状態も適当な物に変えないといけない。
 イベント中に変動が起こる変数には、色々なバリエーションがあり得る以上、単にフラグオンオフ機能だけつけても不十分な気がする。


実装用途によっては関連部分との整合性まで考慮した上で実装する場合もあります。
ただ、例えば使用目的がただ単にステージ内のチェック(オブジェクトやグラフィックなど)だけがしたい場合でしたらその他の整合性などを考慮せずに、ステージの開放フラグのみ管理したデバッグコマンドを実装したりして対処します。
デバコマを用意するにもあれこれ対応していると時間がどうしてもかかってしまいますので、スケジュールとの戦いをやっている以上は無駄な作業を極力削るためにこのような形になる場合があります^^;

  • 2013/08/31(土) 17:54:56 |
  • URL |
  • #-
  • [ 編集 ]

なるほど。やはりセーブデータに互換性をもたせるのは、全部固まってから最後にやるべきなのですね。
となると、今の所は、フラグのオンオフ機能とかを少しずつ実装していく方がよさそうですね。

>使用目的がただ単にステージ内のチェック(オブジェクトやグラフィックなど)だけがしたい場合でしたらその他の整合性などを考慮せずに、ステージの開放フラグのみ管理したデバッグコマンドを実装したりして対処します。

そのデバッグで何を確認したいかをしっかり決めてから機能作るのが大事ということですね。
もう少し案を練ってみます。

参考になる情報ありがとうございます。

  • 2013/09/01(日) 10:38:52 |
  • URL |
  • 獅子堂久遠 #NkHPR.Kc
  • [ 編集 ]

◆ コンソールについて
ttp://devdoc.kikyou.info/tvp/docs/kr2doc/contents/Console.html

開発時はコンソール開いておけばプレイ中にtjsを実行できて楽になります。
変数の操作、デバッグ用のアイテムコンプ関数の実行程度ならこれで良いかも

Shift + F4 でコンソールの表示、非表示は出来ますが、
それも面倒なので自分は
Debug.console.visible=true;
みたいなのをOverride.tjsに書いてテストプレイしてます

if(Debug.console.visible) の判定は操作による切り替えが楽で、kag未使用でも参照でき、
リリース直前にデバッグ関連の箇所を修正する手間も省ける、という利便性があるので
CGモードでの閲覧条件やキャンプメニュー内でのデバッグメニュー等の表示・実行条件の判定などで便利です

  • 2013/09/02(月) 13:45:04 |
  • URL |
  • #-
  • [ 編集 ]

>変数の操作、デバッグ用のアイテムコンプ関数の実行程度ならこれで良いかも

なるほど。
なんかそういうもんがあるってのは漠然と知りつつも全然使ってこなかったんですが、うまく活用すれば作業効率アップしそうですね。
もっと活用を考えてみます。

  • 2013/09/02(月) 21:51:35 |
  • URL |
  • 獅子堂久遠 #NkHPR.Kc
  • [ 編集 ]

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://kuonkobo.blog82.fc2.com/tb.php/746-7f62e3d0
この記事にトラックバックする(FC2ブログユーザー)