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

メッセージシステムを改修中

Tweet

大規模な改修。前回作ったメッセージシステムをある程度流用しているが手間はかかる。

作業要領は得ているも仕様とかをメモっていくの面倒くさい。

CF25 用の自作エクステンションをデバッグするついでに CF25 でメッセージ表示用タグをアトリビュート付きでクリップボードへ転送するツールを作っておいた。可能な限り楽をするためスクリプトやツールを駆使する。

スクリプトの書式と仕様

メッセージの表示はメッセージボックスをオブジェクトとして作成しメッセージボックスとして描かれた範囲内に文字列が描画される。

メッセージの指定は一行で簡潔に書く方法と、複数行を利用した方法二種類が定義されている。

一行で書く場合、メッセージに含める改行は GML の仕様に沿って改行位置へ「#」を挿入すること。これは \r\nに相当。

二行以上に及んでメッセージを作成する場合はテキストエディタの改行を利用できる。/t（ タブスペース ） など不可視文字は自動的に除外される。ホワイトスペースは除去されない。

HTML タグに似せた書式でメッセージ本文を閉じ、タグ内にアトリビュートを書くことができる。

<Message.New xs=-0.2; ys=0.5; xpos=-0.2; ypos=0.5; mspd=+.10; ID="title@00"; font="font0"; fukidashi="FALSE"; color="default"; >

アトリビュートのデリミタは; （ ホワイトスペースを含めた二文字 ） 、メッセージ本文はタグで囲まれる。

先に数値データが挿入され文字列データは“で囲まれる。順番は絶対なので先に数値を置く。文字列を先に置くとパースエラー。

アトリビュートの文字列はパースされると全て小文字になる。

id=“TEST”; がパースされるとtestと出力される。

アトリビュートに大文字利用を禁止していないのはスクリプトソースを作る際に可読性が良くなるため。

しかし文字列は評価時に大文字／小文字を区別するのでどちらかに統一しないと記述ミスの元となるから、CSV へパース時点では小文字に統一される。

おかしい GML の文字列処理

GML の文字列操作系関数の仕様がおかしいため時間を無駄に潰す。

string_delete関数で指定した文字列を削除する際、行末に付いている改行コードを取り除くためになぜか二つ分の文字を削除指定しないと改行コードが削れない。

a = string_delete(a, c, 2);

1.4.9999 以前の古いバージョンにもバグがあったけど、最終バージョンでも改行コードの扱いがやっぱりおかしい。

string_posで検索しても行末にある改行を判定してくれないし、こういう変なバグみたいなのは互換性維持の点でも危険なのでそれぞれビルドして点検・検証しないとまずい。

Windows PC と Android のビルドはそれぞれコード互換性が高いためあまり問題を起こすことはないが、HTML5 は試してみたら動作がおかしいとかよくある。ちなみに今回はテストしたらそれぞれのビルドで動作は共通していたので実行環境に応じて処理を変える必要はなかった。

なぜ行末の改行を取り除くときだけ二文字指定しないと消えないのか、一抹の不安を抱えながらとりあえず次の実装を急ぐ。

実装完了部分

• メッセージウィンドウの作成／更新

• 背景の表示／消去

• ユーザー操作待ち命令

上記はそれぞれ基本機能を実装完了。

メッセージウィンドウの作成と表示機能は前回実装よりもパワーアップ、三つ以上のメッセージでも同時に表示したり消したりできる。エフェクトの指定でシェーダを選択可能になった。

別々の背景を二つ同時に指定して表示することが可能で、やはりエフェクトとしてシェーダが選択ができる。

あとはキャラクターに関する実装が完成すれば、メッセージシステムも八割完成。

動作テスト

実装がある程度終わったので動作テスト中。やはり経験が活きてくるため前回よりも作業が速いし動作もしっかりしてる。

機能実装にテストが追いついていなかったため、一旦開発を中断して動作テストに専念。思っていた以上に作業が進んでおり機能も豊富で、その分動作テストが時間かかっている。CF25 で作ったメッセージシステム用の補助ツールも活躍中だが Public 1.0.0 版は実際に使いはじめるとバグがあったのでそれらを直しながらツールの動作テストも兼ねている。だから余計に動作テストの完了が遅い。ツールも rev 1.0.2 までバージョンは上がり機能も増えた。

CSV にパースする Python Script の方は一日で書いた糞コードの割に動作が安定してしまったので、とりま使ってるが全然問題無い。問題無いが糞コードなので読み難いし残念ながらもう書いたコード自体を忘れかかっている。先週は途中 C++ の作業も入ったので頭の中が色々な言語仕様で乱れてしまって余計に悪い。

Python であれ GML であれきちんと仕様についてのまとめを作業後すぐ書いたことについては、大変良かった。

あれが無ければ細かい仕様は全部忘れてた。GArR のソースコードは三年前だから忘れても仕方ないが、書いたばっかりの Python コードは書いて即忘れたのでは作業効率が著しく悪い。

動作テスト後、内部バージョンのアップ

大幅な機能向上を果たしたので 0072 はすっ飛ばして 0074 まで内部バージョンを上げる予定。次回は 0075 への昇格を目指す。