進捗 メッセージシステム編 #03

 obake   character   progress 

Spine 用リソースを作成中

メッセージシステムは組み込み済み。ただしこのメッセージシステム自体がまだ試作品の延長みたいなもので、完成していない。

今後必要に応じて必要な機能を実装をしていく。

基本動作

メッセージシステムとしての基本動作は完成している。

  • キャラクター表示
  • キャラクターのセリフを表示
  • クリックを検出、次メッセージ表示

この辺りはデジタル紙芝居に必要な最低限の機能。

逆に現在できないのは

  • Spineで作られたスプライトのアニメーションを指定
  • Spineアニメーションの停止、操作など

Spine 系の操作がまだ未実装。Spine 用のリソースがまだ完成していないため、メッセージシステムの Spine 操作系も機能実装が停滞するという連鎖。

メッセージシステム・GMSスクリプトの構成

メッセージシステムは GMS スクリプトで機能実装されているが、中核となるユーザ定義関数は二つで、INIT_msgev と Draw_Selecter という関数の下にチャイルドスクリプトを複数持たせてある。

Scripts

チャイルドスクリプト

複雑な処理ではないので各チャイルドスクリプトもそれぞれ 100 行に満たない。小さな命令の集合体。

ユーザ定義関数は初期化/STEP/Draw 実行のタイミングで処理されるため、本来は INIT/STEP/DRAW というプレフィクスで大きく三つに分割されるのが望ましい。

試作品なので改良の余地ありだが、登録されるユーザ定義関数が少なくなるのならその方が他プロジェクトへ組み込む場合も楽かもしれない。

それでもやはり INIT が肥大化しているようなので、STEP で分割して親は三つにした方が良いだろう。

GMS 1.4 のテキスト処理

GMS 1.4 の文字列操作系関数はあまり充実していない。

もともとユニコード対応が遅れていた環境でもあり、GMS 1.4になってもまだ多くは ANSI レベルの機能に留まる。この辺りは将来的にもまだ期待できないだろう。

GMScript を python と比較するなんて野暮だけど、しかし筆者はたまに頭の中でゴッチャになるため、python にある関数が GMS 1.4 の標準関数に無いか探したりする。もちろんそんなもん無いわけだが。

一応以下が GMS 1.4 の文字列処理に関する機能一覧である。

GMS1.4の文字列操作用標準関数

ゲーム用とは云えかなり簡素というか質素。正規表現も使えないし制御文字には GMS 1.4 独自の方言を一部使っているため慣れが必要。制御文字関連はちょっとしんどい。

例えば CSV 形式のデータを配列に放り込みたいときなど、汎用でなければ、CSV を処理するスクリプトを書くのは比較的簡単。だが欲を言うと、その程度のものならば標準関数で対応して欲しかったりする( JSON には対応してるのにも関わらず )

しかし下手に標準関数化されてもブラックボックスだから、標準関数にバグがあると自分で直せないためアップデートのバグフィクスを待つ羽目になりかねない。それも困る。

キャラクター

スプライトを Spine で管理する必要は本来無いのだが、将来的に GMS 以外の統合開発環境で開発する場合に Spine 形式でやり取りできればキャラクターの移植が楽。そういう理由で Spine で差分を管理する方法を使っている。

キャラクターは顔と腕を消した以下の状態がデフォルト。

土台となる画像、顔・腕無し

ここに表情や腕の動きなどを足して、複数の表現ができるようにしていく。現在はまだ色も塗っていない線画の状態なので Spine へインポートできる状態ではない。もうしばらく線画の状態で差分を作りながら、差分が全体でどの程度の量になるかを先に把握しなければならない。

というわけで現在は普通の立ち絵を出力してシート化、それを見ながら別の差分を作ったりしている。

差分・イメージのシート化

実際の表情は以下のようになる。

腕と顔で差分を複数作る

肩が固定されている画像へ無理やり腕をくっつけるので差分の腕は描きにくいらしい。まぁ普通は腕が動けば肩も動くからな。




次へ

前へ