0_0_64C

 obake   specification   version 

0_0_64B の実装計画が長くなったので、0_0_64C と改め

メニュー画面から各モード選択、ルーム移動など、実際のゲーム実装に沿った形でルームや各機能を実装していく。

0_0_64B ではメニューから移動する各ルームなどの設計・計画迄、実装はあまり行われていない。

  1. start - - - ● 実装済み
  2. game_menu - - - ■ 実装中
  3. Story_Mode- - - ▲ 実装開始
  4. Time_Attck- - - ▲ 実装開始
  5. omake_mode - - - ✕ 未実装
  6. game_setting - - - ✕ 未実装
  7. game_engine - - - ■ 実装中
  8. Grid_Editor - - - ● 開発者用：実装済み
  9. stage_A - - - ✕ 未実装(ROOM のテンプレート用)

優先的に Story_Mode と Time_Attck の実装を行う。再利用可能なテンプレの作成から行い、テンプレがある程度になったら他ルームにも着手する。

Room の階層構造

  • start
    • game_menu
      1. Story_Mode - - - Intro ／ Stages - - - → Intro は動的に作成されるROOM
      2. Time_Attck - - - Play ／ HighScore
      3. omake_mode - - - 未実装
      4. game_setting - - - Set ／ ?
      5. EXIT - - - 未実装（存在しない）

ROOM はこれ以上リソースエディタ上へ追加して増やすと管理が面倒なので、今後は GM:S の ROOM EDITOR を利用せずに GML から直接 room_add(); 関数を使って動的に ROOM を作成していく。

MMF／CF2.5 とは異なる点として、GM:S は GML を使って ROOM すなわち MMF／CF2.5 ではフレームに相当するものをゲーム実行中に任意のタイミングで作成することができる。ROOM を動的に作成できるメリットとしては、テンプレートを作っておけば ROOM の複製が容易になる点、複製された ROOM を個別にカスタム設定すれば大量の ROOM を ROOM Editor 無しで管理することができる点、など。

GM:S 1.4 の ROOM Editor は非常に粗末。もちろん必要最低限の機能は付いているが、使い勝手は良くない。リソースツリーからのアクセスも GM:S 1.4 には ROOM の親子関係は実装が無いので、グループで管理する方法しかない。一方、ROOM Editor を使っていれば設定を変えるのもインターフェースを使って容易だし、あらかじめ ROOM がリソースツリーに並んでいたほうが視覚的にも分かりやすい。Room の設定も慣れれば GML から全てできるようになるが、GML で全てを設定するのも少しコツがいるため最初は Room Editor を利用したほうが楽。

room_add 関数

実際に room_add(); でルームを作成して views の設定を行うと、オブジェクトインスタンスの配置位置がどうしてもずれてしまう問題が発生。HTML5 で動作を試したが、こちらでは spine のアニメーション挙動がまずおかしい。調べたら alarm_set 関数が単に HTML5 に対応してないだけ。そこを直したら HTML5 における spine アニメーションの動作が適切に戻った。

インスタンスの初期位置が狂っている問題は、room_height を利用していた Y 位置の指定部分を view_hport[0] の利用へ変更することで解決。

Objects の実装と階層構造

  1. Transitions( Group Root )
    • MenuCommon ( Group )
      • tr_button - - - ボタン ( 汎用ボタン )
      • tr_return - - - 戻るボタン ( Start Manu 画面へ戻る )
      • tr_da - - - 画面遷移用のアニメーションファイル (暫定)
    • StoryMode ( Group )
      • trn_intro - - - イベント管理用（ROOM は global.ROOM_INTRO で管理中）
      • trn_0 - - - イベント管理用オブジェクト
    • TimeAttakMode ( Group )
      • trn_1 - - - イベント管理用オブジェクト
    • OmakeMode( Group )
      • trn_2 - - - イベント管理用オブジェクト
    • SettingMode ( Group )
      • trn_3 - - - イベント管理用オブジェクト

メッセージ表示機能

以前から計画のあったメッセージ表示機能の実装に着手。room の intro に実装を試みる。

メッセージ表示機能：試作版

メッセージ表示機能といってもノベルゲームみたいな本格的な機能を必要としてないため簡易版である。

MMF2 の頃に XLua を使って本格的なメッセージ表示機能を作成したことがある。今回は GM:S ＋ GML なので、機能的には GPU にアクセスできる分 MMF2 ＋ XLua 構成よりも機能的には充実したものを作成することもできる。

GM:S もアセットを購入すればノベルゲーム用のシステムを手っ取り早く実装できるはずだが、人が作ったものは仕様を覚えるまで少し時間かかる、汎用として作られているだろうから不要な機能などもあるだろうし、自分の用途に合わせたコンパクトなものは自分で考えてフルスクラッチで作るのが性に合っている。

仕様とか

1024 ✕ 1024 pixel size の Surface を二枚使う。暫定的にだが一枚は「フロントバッファ」、二つ目は「バックバッファ」と呼ぶ。二枚の Surfaces に対して専用のシェーダを使ってカスタム描画を行う。

GPU シェーダは必要に応じて作成。PassThrough が基本だが、領域を指定して範囲を描画するなど用途に応じた単機能なカスタムシェーダを漸次作成する。

スクリプトのソースは GML のソースコードへ直接書いちゃう。今回は本格的なストーリーとか無いので、文字で説明する部分は少なめ。テキストも少ないし量が限られるのならば直接配列へ文字列代入するハードコードでもなんとかなるはず。

メッセージの表示

surfaces は暫定的に「フロントバッファ」と「バックバッファ」と呼ばれているが、二枚の surfaces は基本同時に描画される。一般的なダブルバッファ方式とは全く違うので、バッファに対する現在のこのネーミングはあまり芳しくない。

シェーダをフル活用する描画はパフォーマンス重視というよりも、シェーダに関する機能実装を実戦で試す目的がある。これまで多くのテストコードを書いてきたが、それらを活用する場を増やしたい。

仕様とか２

文字列は一行単位で surface へ描画される。

一番新しい行は画面の中央へ位置し、表示済みの古い行は色を変えて上へスクロールされる。これは既読行となる。

一定行数を表示したら適切なタイミングで表示している全ての行を消去する処理を二枚の surfaces に対して実行。ここまでを「１ページ」という単位とする。

ページが更新されたら、新しい行をまた画面中央へ表示、SurfacesA／B も初期値へ戻り、再度ページ終端へ到達したら新規ページの表示処理、この繰り返しとなる。

初期表示

複数行表示

メッセージの表示:初期位置

メッセージの表示:複数行表示

メッセージの表示例

次にキャラクターとセリフの表示処理へ取り掛かる。




次へ

前へ