Beta.06A 更新履歴｜仕様変更など 1

Beta.05C rev.5 からの続き。

バグ修正履歴

Beta 版としては 06 が最後。Beta 06 の機能で、正式版を C++20 で作成することを決定。

06A 以降のベータ版は開発を全部キャンセル。06A はプレビュー版として公開しますが、体験版なので一定期間公開後に削除されます。

Beta 06F ( Final ) はベータとして最後の正式公開版で、細かいリビジョンは今後ある程度更新される予定ですが新機能追加は無く、機能的な安定性を重視した一般公開版です。

Beta 06F は 2023 年 05 月 01 日に公開された Beta.05C rev.4 までに実装された機能を基に作られています。

新機能実装履歴

06A について

Beta.05C rev.5 はキャンセル、MoveToward という新しい Motion 定義が実装予定だったが仕様がまだ複雑で、もう少し設計をしっかり練る必要があった。

先行して +A-Motions に Swap A to B という指定オブジェクトインスタンスの位置を入れ替える機能が 05C rev.5 に実装されている。これはインスタンスの数が 1 on 1 の場合に機能するため仕様が単純で作りやすいからだ。

これ以降バージョンを 05C から 06A へ改める。比較的大きな機能追加があるためバージョンをアップ。

以前から階層データ構造をファイル保存する手段が欲しかったのだが、最終的にデータベースではなく JSON 形式に対応することに決定。ファイル読み込みと書き込みに対応すればセーブデータの実装とデータロードまでをカバーできる。セーブデータはバイナリ形式( BSON か MessagePack )でも保存できるようにしたい。

JSON object という拡張が Clickteam メンバーである LB によってすでに作られているが、LB は 2014 年当時まだ Clickteam の公式メンバーではなく、この Extension は Third Party 製の拡張機能として公開された。String を JSON に変換したりファイルから読み込むことができるのだが書き込みに対応していないのと、何故か現在この拡張機能は Clickteam の Extension Manager からインストができない。Github からバイナリをダウンロードして手動インストールはできる。

Clickteam 公式フォーラムでは JSON++ Object という拡張機能も開発が進行中。基本的にこの拡張機能の作者と同意見なのだが、JSON Object は全面的に刷新する必要がある。ただし prester.org としては Windows 開発だけに絞っているため HTML5 とか Android や iPhone などエクスポート対応することは考えてない。現在 ASTER Beta 05C に実装されている align 機能をそのままデータ構造として保存したいのと、なるべく入力パラメータを少なくしてループ処理の多くを拡張側で行い自動化することが目的で、JSON++ Object とは機能的に競合しない。汎用ではなく特定用途に特化して、その分操作が簡単なデータ保存と再生機能を目指している。

Pisition Array Object

ASTER の Align や Motion Control も Regex の副産物だが、似たような機能は Position Array Object というものが Clickteam のアセットストアにあるのを発見。ログインが面倒で試してないが動画で動作を見る限りたぶん似たような感じ。こちらは Android に対応もしてるようだ。メニューを見る限り ASTER の Motion control と概念が本当よく似てる。

JSON

C++側からJSONデータの読み取りと階層データから指定したキー名でデータを取り出すなど、基本操作は現在でも可能になっている。問題はCF25側でどうやってデータの受け渡しをするか。

配列を配列として渡すことができないためパフォーマンス面では最初から不利なのだがそこは納得した上で、階層構造から指定したデータを取り出すための効率的な手法が思いつかない。そのため現時点での問題点をメモとしてここに文章化して残しているのだが、どう解決するべきか。

CF25は元来セーブデータとしてINIなどを利用し、INIは階層構造を扱わないのでキー名とデータは常に一対一の関係にある。JSONデータ構造はC++だと構造体（Struct）に近く、構造体から指定されたキーからデータを取り出す場合にはドット記法を用いている。だからCF25でもドット記法を使ったパラメータの受け渡しが出来ないかと考えていたのだが、汎用性という名の非常に厄介な「制約」をある程度無視しなければ実現はできないかもしれない。

ドット記法を考えてみる

「TEST」という構造体（オブジェクト＝プロパティの集合）に格納された「SCREENPOS」というキーに「100」というデータが入っている場合、ドット記法だと「TEST.SCREENPOS」という記述で「100」というデータ（値）が返ってくるようにする。これは可能。

しかし標準のJSON仕様だとキー名にドットを使ってはいけないという規則は無いため、キー名にドットを利用された場合、ドット記法だとパラメータを解析する段で少しややこしいことになる。

「TEST」という構造体に格納された「SCREEN.POS」というキーに「100」というデータが入っている場合、「TEST.SCREEN.POS」となってしまう。つまりドット記法使いたいから命名規則に「ドットの利用禁止」というハウスルールが必要。このローカルルールが致命的クソ仕様になる可能性はたぶん無いが、JSONの仕様とは一致しないから混乱を生む可能性はある。

「ドット記法を使いたいからキー名にドットを使うんじゃねーよ」は許されざる我儘なのか、否か。あるいは別の解決方法について。

ドット記法以外

JSONの階層構造データは仕様上非常に深い階層でも許容している。実用性はともかく。

INIはそういう点ですごく楽だ。階層化できない代わりにキー名とデータが必ず一致するので呼び出しも書き込み指定も記述は簡潔になる。

でもJSONのメリットはやはり階層構造にあるので、それをなるべく簡潔に記述したい欲求。

「(TEST)(SCREEN.POS)」みたいに丸括弧で名前を囲む方法とか、でもこれだと名前に丸括弧が利用できなくなるし、記述が面倒くさい。

ブラケット記法

「TEST」というオブジェクト、「TEST[SCREEN.POS]」、これはまぁ…許容できる。ただこれもキー名に[]を利用された場合を想定した解析処理が必要になることに代わりない。ブラケット記法とドット記法を比べるとドット記法のほうが簡潔にはなるし、両方に対応する義務は無い。

JavaScriptではオブジェクトのプロパティへのアクセスにブラケット記法を使うことも出来ますってことで参考にしてみたけど、ブラケット記法を利用した場合、一部命名規則を暗黙的変換によってブラケット記法では利用可能にしてたりする。

参考：ハイフンを含む識別子も利用できる（ブラケット記法）

ブラケット記法とドット記法を使い分けることでプロパティの名前にドットが含まれる場合はブラケット記法を使ってもらい、［］が含まれる場合はドット記法をとか？どちらにしても名前を検索する事前に文法解析が必要になる。

やっぱりJavaScriptの変数宣言の際に適用される「変数名に使える名前のルール」を借用するか、そこまで厳密で無くていいからとにかくJSONデータ側で予め「プロパティ名にドットを利用しないでください」と呼びかけるか。ドット記法使えるメリットやその方が作るの楽だしという理由に加え処理も速くバグも出にくい。やっぱり命名規則にハウスルール適用が現実的か。

JSON Pointer (RFC 6901)

JSON Document の値にアクセスするための記述方法が RFC 6901 で定義されていた。

階層構造を表現する記法としてはドット記法とほぼ変わらないが suffix であり、RFC 6901 では prefix として「/」 (%x2F) 利用が定義されている。

具体的には

/
/json
/json/aster
/json/aster/key

こんな感じの記述になる。prefix なので root でも文字列先頭に必ず「/」を付ける。ファイルパスと同じ仕様だがドライブ指定が無いみたいなもん。

でも結局、構文や記法が定まっていても文字列解析は自前でやるんだよね？と思っていたのだが、C++ nlohmann/json はすでに JSON Pointer をサポートしていた。これで深い階層のデータでも一発で取り出せるってわけさ。これは便利。

とりあえず JSON をパースして Dump 出力、JSON Pointer を使って深い階層から値取得し CF25 で受け取り表示、ここまではできるようになった。セキュリティ的な処理を一切やってないが。

2023 年 6 月までの作業で JSON 用のクラスは予め作ってテストもしてあったらしく、後はクラスにメンバ関数を追加していけばそれなりに機能する状態だったようだ。

来年2月頃に新バージョン出せそう？

手応えとしてはいけそう。セキュリティゆるゆるなままだろうけれど、基本的操作の機能実装は一ヶ月あればそれなりに成果を出せる。

１月３１日、06a rev.1 公開予定

動作テストが順調。

現在 JSON for Modern C++ の API Documentation を読んでいるが、ライブラリとしての実用性や汎用性がすごい。ただし処理速度という点ではかなり遅い部類になる。Modern C++ では文字列が機能強化されている、がその分処理速度ではデメリットも多く書き方次第ではスクリプト言語より遅くなる致命傷を負う場合がある。仕様をしっかり理解して書かないと。配列へのアクセスは JSON Pointer を使うのだけど、連想配列なので元々遅い。多次元配列も対応可能だがそこから処理速度を求める場合は、別の対応が必要になると思う。

F3 Blog

久しぶりに Clickteam フォーラムを見に行ったらサイトリニューアルされたばかりだった。

一部使いやすくなったがまだ構築中の部分があり、仕様の変更もあった様子。フォーラム記事を読むためにログイン必須。過去記事のリンクは生きてるけどログインを促される、パスワードを覚えてない、パスワードを探そう！という非効率コンビネーション。

F3 ブログが一時的に見れなくなっているようだが、関連スレッドでたまたま Yves の生存を確認。F3 については現在も作っていますと。進捗についてはやはり言及されなかったのですが、今回に限っては公式スタッフである Danny が現在作業中の内容について「フレームワークの構築」に全力を注いでいると発言しています。

個人的には拡張機能の開発でまだまだ戦えるため CF25 現役ですが、あるいは小規模な開発なら確かに他に無いくらい簡単な開発ソフトなのです（ビルドの速さが特にお気に入り）。F3 に関しては出来れば拡張機能開発のため今から API ドキュメントをしっかり用意して欲しい。これくらいでしょうか、今ある要望としては。やっぱり普及するライブラリなり開発ソフトウェアはドキュメントがしっかりしてます。

Targeted Array

配列からデータ受け渡しは Clickteam 製品の鬼門みたいなもの。Clickteam の Fastloop が致命的に遅いためこれが最初のボトルネックになる。次に配列へのアクセスや検索自体が重いのですが、今回は主に連想配列なので更に遅い。データベースといっても中身巨大なものは到底無理で、あくまでも CF25 の制限のなか使える範囲で便利化するための拡張機能を目指し開発します。

「fastloop」をなるべく使わないでループを回すにはエクステンション内部で処理を増やすしかないのですが、他オブジェクトとの連携には基本的に「fastloop」使用も止む無し。現在はこの「fastloop」を使ったデータ受け渡しを少しでも簡単にするため「Targeted Array」という機能を作って試してみました。

Targeted Array とは

指定配列へのアクセスをエクステに記憶させ、エクスプレッションからは配列インデックスを送信するだけでデータ取得が可能になるという機能。LB が作った元祖 JSON Object には Bookmark という概念で実装されていますが、これが現代では JSON Pointer に相当します。

繰り返し処理がある場合、何度も JSON Pointer を送信するのは無駄なのでアクセスポイントを一度記録させ、次からはそこ起点に別階層データへアクセスするための足場とするのです。データ送信や文字列処理をなるべく少なくする工夫ですが、一括処理する場合以外だと少し手順が面倒。

LB 版 JSON Object は、常に階層データの位置を Bookmark として記録し作業用足場を作ってから次にデータアクセスという手順を取ります。

ASTER に実装中の JSON 機能は、ループ処理が必要な場面でデータアクセスにブーストを効かせるため JSON Pointer でアクセスポイントを記録しますが、通常はどこからでもどんなに深い階層でも一発でデータにアクセスできます。つまり階層データにおける現在位置を意識するほぼ必要は無く、ループ処理する際にだけアクセスポイントを作って高速化するという使い方です。このアクセスポイントの一つが配列用だと「JSON Pointer :: Targeted Array」です。名前はまだ仮なので変わる可能性があります。

ゆるいデータ型チェック

LB 版 JSON Object は型チェックも厳密です。

ASTER の JSON 機能はループ処理中には暗黙的変換処理をする場合もあり、型チェックは緩めに作ってます。型チェックを厳密に行う場合は専用命令を使うことで厳密化できます。

データダンプ機能

LB 版には無い機能としてデータダンプが取れるようになっています。これは型のチェックも兼ねているのですが、JSON オブジェクトが格納しているデータを抜き出して一覧出力したい場合など、入力されたデータをファイル保存する前にアプリ側でリアルタイムに可視化できる仕組みが欲しかった。現在は主にデバッグ用途ですが、データダンプを REGEX で処理し、もう一度 JSON データとしてメモリにリロードすることなども想定しています。

現時点までの対応機能として

以下 JSON テンプレートをインポートすれば、対象アクティブオブジェクトのインスタンスに対する設定をテキストエディタから個別に指定できるようになります。

{
"ByN_JST_01":
{
"$meta_description": "ID, X,Y, AnimationSequence, AnimDirection, AnimFrame, AnimStop, AnimSpeed, SetLayer.",
"id": 16001,
"window_title": "TEST ☻",
"setup":
[
[null, -1, 200, 0, 0, 3, true, 5 ],
[17, null, 400, 1, 8, 0, true, 5 ],
[99, 700, null, 1, 0, 2, true, 5 ]
]
}
}

従来だとフレームエディタとイベントエディタからの操作でしか出来なかったことが CF25 起動も不要なまま設定ファイルを書き換えるだけで設定可能になります。

現時点でできることは元々 ASTER Beta 06A が対応している各種機能、それはインスタンスの初期配置や変数代入、そしてこれまで指定できなかった Z Order や 指定レイヤーへの移動、アニメーション方向やシーケンス変更も可能になります。

実際作りながら思ったこととして、各インスタンへ個別の値を送信するときに利用される「アクションループ」、あれ初心者には分かりにくいよねってこと。

各インスタンスに値を確実に設定できるという点で、テキストエディタ使った作業の方が便利に感じることもあります。

機能追加は順調進行

今週は Expression へ機能追加が多かった。JSON テンプレートは先週までに機能が把握できたので、次はメモリにロードされたデータから実際にデータを取得する機能の追加に集中している。

動作サンプルがすでに必要最低限は揃った。実際に作りながら必要な機能を追加している段階なので、進歩が著しい。できることがどんどん増えている。

JSON Templates と Targeted Structured はかなり使える機能だと思う。問題は作者の考えている機能概念をうまく説明できているか、あるいはできるのかどうか。動作サンプルはまだまだよく練る必要あるかもしれない。

Beta 06A Preview

拡張として結構大きな機能を持つようになってきたため、ソースコードを大幅に書き換える必要性に直面。ベータ版を卒業したいのでここまでに実装された機能を基に、全く新しいエクステンションとして作り直す決定をした。

この開発のきっかけは正規表現を使いたいからという理由で、自分自身の製作上必要な機能として文字列処理だけを行うエクステンションとして最初に設計されていました。

オブジェクトコントロールを後付けした時点から方向性が変わってきたのですが、JSON 機能に対応しながらやっぱり後付けでベータに今後機能を追加する不都合に耐えられなくなってきたのです。

06A はプレビュー版として公開しますが、体験版なので一定期間公開後に削除されます。

安定版として Beta 06F を公開し、これは 2023 年 05 月 01 日に公開された Beta.05C rev.4 までに実装された機能を基に作られています。
05C はある程度完成度を持っていて、自分用として実際に利用しているバージョンなので安定化版が必要でした。06F は今後メンテナンスが継続されるので不具合報告などにも対応できます。