読者です 読者をやめる 読者になる 読者になる

XC コア 1.0 に必要なもの

コア1.0 の新しい仕様案は一年前に出して、それなりにフィードバックがあった。国内の反応が1件だけだったのは心残りだったけど。でもその仕様だけでは足らない。

データモデルはいらない

XC でデータモデルを持とうかと思ったが、 XC コアの役割は人と人の作品を繋ぐことなのでこれは優先度は低い。しかも開発者にとって好みが分かれる箇所らしいので、やはり BASE 単位で持つのが理想だろう。ゲームエンジンでも、交換不可能な物理やAI、シーン管理をコアが搭載すると不評を買うケースが多い。たぶんそれと同じでしょう。

仮想サービス

XC の仕様で最重要かつエンバグ状態で放置しっぱなしなのがコレ。実質上、モジュール間通信を行う機能はこれで、レンダーシーケンスと合わせた二大機能なのは間違いない。もっとえぐいバインドを行ってもいいだろう。

問題はサービスから取り出すインスタンスの型をどうするかだが、これこそ配列相当の(独自の操作が追加できない)プリミティブな、構造体に近いモジュールものになりそう。

レンダーシーケンス

作品を組み合わせてレンダリングするという部分は 1.0 案で動いているが、 HTML にはヘッダ部があり、すべての描画で使用する CSS はそこで読むことが好ましい。本当に今更だが XC のマルチなレンダーターゲットによる描画処理は間違いで、マルチパスレンダリングのほうで考えた方がマッチしたかもしれない。まぁ同じ動きをさせればいいんで大きな問題じゃない。

テストレンダリング

フォーラムに書いたが、ビューに貼りつけられた情報から動かすプログラムを追加することが可能な工程が欲しい。ステンシルテストのようにダミーのレンダリングを一度打てばいい。

メインループがあり、ステートマシンのゲームPGと違い、Webの場合はプログラムを回してみないとどのビューが使われるか分からない。ビューが決まり次第、指定されたレンダーシステムでプラグインテストレンダリングを行うのがいいだろう。あるいはテンプレートが変更された時点でテストしておけばいいかも。

認証まわり

現在アクセスしている何者かを指す情報が XCube_Identity で、これはデータではない。MLでonoさんがパスワードと電子メールくらいメンバに入れては?と書かれているが、認証を Web サービスで受けた場合や OpenID で認証を通した場合は持つ情報がメールアドレスではなくなる。だから XCube_Identity には最低限の定義しかない。

ただ、これたまたま .Net でゲーム作ってるときに、そこから取ってきた仕組みなので、果たしてXCubeに適正かどうかがまだ分からない。早く時間を作ってXCDGJの議論を再開せんと……