8月ですね。

XopsAddonCreatorを触りましたが、次の難題にぶつかっています。
ブロックデータとポイントデータ、両者をいかに効率よく処理するか　です。


OpenXOPS（ゲーム）は、データを読みっぱなしで良いソリューションです。
あくまで両データはファイルから読み込んでいるだけで、読み込み後はゲーム
側で都合の良い独自のデータ構造で処理すれば問題ありません。
ところが、XopsAddonCreatorはエディタです。データを読みっぱなしで終わる
ことは殆どなく、データ自体を編集し 場合によっては元に戻す（Undo）機能
を提供する必要があるほか、ファイルとして書き戻す機能も必要になります。
この『読み込み⇒変更履歴管理しつつ編集⇒書き出し』という一連の処理が
エディタの肝であり、OpenXOPS以上に内部のデータ構造が重要になります。

モデリングソフトのようなひとつの形式（性質）のみに特化していれば　まだマシ
なのですが、厄介なことにXopsAddonCreatorはブロックデータとポイントデータ
という、性質が全く異なるデータを2つ同時に扱う必要があります。
※ブロックデータはモデリングデータに近く、ポイントデータはスクリプトデータ
　に近い。
ようは、『読み込み⇒変更履歴管理しつつ編集⇒書き出し』という処理パイプ
ラインが、同一ソフト内で二重に存在するわけです。

何も考えずに作れば、単純に同じ実装を2個開発して載せれば良いですし、
既に現行XopsAddonCreatorは、2重に実装されていると言っても過言でない
設計ですが、
単純に工数2倍で無駄な開発作業を生むうえ、バグを生みやすく、なんせ柔軟な
設計変更・改版もできません。
あくまで実装としては1つにして、両フォーマットに対応した柔軟な設計を取り
入れるのが理想であり最適解となります。

ですが、現状良い実装案が思いつきません。
C++のコンテナクラスを上手く使えないかと思っており、スタックやキューを
使えないかと企んでいますが、微妙に実装が合わず困っています。


6月の記事では、次期XopsAddonCreator開発における難所の一つに
「不具合のない安定したデータ編集機能の実現」
を挙げていましたが、本件前述の処理・実装がポイントになりそうです。
もう少し良い設計・実装を考えてみます。