頭の体操

アイドレスの大元はプリミティブな仕様の裏で物凄く面倒なことをしているようだ。MVCのうち、Mだけが突出している正直表がRoRである必要性を感じないが(1セッションのコストを考えると特に)バックエンドや管理画面等で便利なことも多いのだろう。

とにかく、この過去との互換性を背負った複雑な書式にあいまいな記載のデータをつっこんで、きちんとした結果を出す、そのプロセスの複雑さは想像することすらできない。パーザの仕様を見てみたい。

その一方で不思議なのが、何故書式がｉ言語ではないのか。同言語がゲームを記述する言語であり、ゲーム規則を規定する言語ならば、何故その言語ではないのか。初期に基礎となる規定を精査したけれど、それ意外の部分でも言語として成立しない理由があるように見える。

プログラムの組める人間からの視点だと「公式データが書式違反ばかりだった」につきる。イレギュラーをお手本にして厳密な規定はできない。また編集支援の無い記号山盛りの言語は辛い、ということ。リファレンスパーザが初期にあれば良かったのだろうが、公式データが入らないのにねえ…。

後から色々成立した時には、独自の書式があり、それにあわせるのがプレイヤーも楽だというデ・ファクトの強みが発揮されている。結果、規定を定義するのではなく、データを定義する言語にダウングレードしているように見える。特殊行動はデータ持ちなのである意味ドミニオン的なデザイン。

もっとも、データの大規模修正や一斉転換(今回の大元もその一つ)が行われることはあるので、将来的にはコストが見合えば一つの言語に集結し、メタ規定でメタメタ規定で作り、ユーザがそれにメタメタメタ規定で答えるといった風になるのかもしれない。十分なIT支援が前提だけど。

その上で、今回の大元、私ならこうするというデザイン。現状のプレイヤーから導かれた解であるし、基本的なVCはこのままとする。

まず、内部的にｉ言語で冗長表現の無い厳密解ができているとして、入力をパースして、中間言語のｉ言語に変換する。そして、バイナリ表現に変換した上でオブジェクトごとにハッシュでidをふり、データベース(SQLでもNoSQLでも)に保存する。ここでKEY-VALUEにしておけば、後でmemcachedにでも何にでも乗せやすい。

中間言語に変換するのはフロントエンドを適時交換できるようにするためである。対外的に利用できるｉ言語を内部インタフェースとしておけば、人間ご利用であろうがAPI経由の利用であろうが対応のための変更は少なくすむ。

データを保存するのはキャッシュとして再利用するためである。利用形態からも、突発的に出るデータは少なく同じデータの試行錯誤が多いと想定でき、データの局所性が十分に期待できる。

組み合わせについては、まあ頑張る。流石に深く見ていないのでここに関しては断言できない。おそらくは言語におけるevalにようにややこしく、山のような特殊処理が入るのだろう。

出力についてはｉ言語で出す。その上で、APIなりウェブなりテキストなりに変換する。

…やっぱり肝心要の部分がややこしすぎる。本当によく大元ではまとめたものだ。そして普通に開発すると、まず顧客からの要求仕様が足りなくて、ほぼ確実に設計者以降が泣く。

関連記事:

• 最近のゲームAI
• Ruby Gems の罠
• GDB7.0でトレース逆流