今月の"今なにやってんの"

nmosh teslawire

こういうコーナーを書けるくらい目的を認識してやらないとなかなか最終製品に辿り付かないので。。このフォーマットだと最初の段落は常に同じことを書くことになりそうだけどその辺は追々考える。
本業との兼ね合いも有り、週締めだと短かすぎる、年締めだともちろん長すぎるので月締めくらいを狙って。定期的に締めを入れないのが悪習と感じているので。

nmosh / yuni

nmoshはR6RS/R7RS Schemeインタプリタ。常識的な速度で動作するのと、それなりに使いやすいフロントエンド(マクロの展開トレース等が出る)やアプリケーション組込みサポート(Win32上のnmoshのみ)がウリ。
yuniはR6RS/R7RS Scheme用の移植性ライブラリ。Racket / Gauche / Chibi-Scheme / nmoshで同じアプリケーションを実行できるように共通のライブラリ基盤を実装しようというもの。yuniはまだ開発の初期段階で、使えるものは何一つ無い状況。Snow2のような他のSchemeライブラリプロジェクトと異なり、yuniの開発は基本的にFFIと既存のC APIのバインディングを作成することと、通信プロトコルのパケットを生成することにフォーカスしている。
今月はyuniのCスタブジェネレータの作成を行っている。CスタブジェネレータはS式で表現したC言語API仕様(stubIR)から、FFIスタブのためのCソースコードを生成するもの。ビックリするくらい退屈な作業で、日記にも書くことが無い。これを作ることによって、一度stubIRさえ書けば、そのCライブラリは上記のScheme処理系それぞれで同じように使えることになるという寸法。
Cスタブジェネレータができたら、テストケース( http://d.hatena.ne.jp/mjt/20150108/p1 )を各種処理系でFFIしていく。ここは多分面白いので今から楽しみ。GaucheとChibi-Schemeはまず拡張(extension)を用意しないといけないので、その辺の流儀を調べるのも必要。Racketとnmoshは動的FFIがあるので、それを使えばCコードを書く必要は無い。
ちなみに、各種処理系のライブラリ流儀は調べるのが面倒だったのでyuni側で"R6RS-light"仕様を策定し、yuni側でライブラリアダプタを用意している。"R6RS-light"とは、要するにR6RSのライブラリ構文だけ借りてきたもの。例えば、Racketでは#!r6rsのようなプレフィクスが無いとライブラリをR6RSライブラリとして認識してくれないが、その辺をyuniが面倒を見るようにしている。
nmoshにおける基盤ライブラリのマルチ処理系戦略はかなり特殊な試みではあるけれど、これは将来PythonとかLuaとかRubyのような別の動的言語ベースの上でも同じアプローチを適用できることを期待している。現状のstubIRはS式だが、これをJSONとかXMLのような形式に落すことでローレベルなSWIGを実現することができればそれなりに需要有る気がしている。
常識的な処理系では、そもそもスレッド生成のようなOSインターフェースは処理系の移植層に組込まれているので、yuniのようなC APIブリッジは必要無い。このため、処理系間で共有できるタイプのFFIシステムはSWIGのような高レベルなものや、COM automationやgobject introspection等一般APIをサポートしないものが多い。yuniはその隙間を狙っている:

  • pthreadとかsystem callのようなOSインターフェースもFFIできること
  • 処理系の負担が少いこと。生成したスタブは他の処理系でも同じように使用できる。
  • 静的リンク等、処理系のサポートを広げるために多様なリンク戦略をサポートすること。

... これを書いてて、面白い部分を可能な限り先に回した方が良さそうなことに気付いた。というわけで、生成される予定のstubを手書きしてからFFIブリッジの制作を始めることにした。

teslawire

  • (まだWebサイトは無い)

teslawireは、アクションRPG。男の子と女の子が宝捜しをするオーソドックスなシナリオとロックオンシューティングの融合。ちょっと別件で予算の都合が付かなくなってしまった(要するにAutodesk税の負担が厳しい)ので、企画や規模を取捨選択しているところ。売り物のゲームではなく、基本的には各種プラットフォームの開発環境のリサーチと、将来作るゲームのtestbedとして。
何分、シナリオが有るゲームを自分で企画するのは超久々なので全然勝手が判らない。まぁ趣味プロジェクトくらい適当でも良いじゃないか説も有るけど、会社の方では結構残酷物語したので芯の通った企画をする訓練は普段からやるべきだろう。と。。
"teslawire"は電線を意味する造語で、日本語の"伝染"と掛けて、遠隔地への伝達とか県境国境を越えた関わり、接続を意味している。(これはyuniとコンセプトを共有している - 異るカルチャのmixを軸としたプロジェクトとなっている)
今月と来月は企画書の準備。ゲームとしての基本フォーマット( http://d.hatena.ne.jp/mjt/20141229/p1 )を一旦決めたので、これを組み合わせて何が表現できるのかを考える。
一般に、企画書に書く事はそんなに多くない。

  1. プラットフォーム / ジャンル
    1. Lead: Web(Firefox WGL), 移植: Nintendo3DS(Smile Basic 3), 移植: Windows(GLES3 using ANGLE), 移植: BD-J (Profile5)
    2. ジャンル: アドベンチャー、アクション
  2. ユーザへのアピール
    1. 物語指向の技術萌えゲーム。ポリゴンとスプライトの2通りで楽しめる"新しい絵本"。
    2. 見慣れたハードウェアで展開される見慣れないビジュアルによる意外性。
    3. 簡単操作とBGM同期演出で爽快なプレイ感覚。物語だけ楽しみたい方向けのtravelling(ダメージなし)難易度。
  3. ゲーム概要
    1. 舞台
      1. まほうつかいの家 : 子ども達の拠点となる場所。いわゆる無国籍な、いわゆるRPGなイメージ。基本的にはアクションステージでない。
      2. 春〜冬の記憶 : 各アクションステージ。四季モチーフ。秋→冬→春→夏。
    2. キャラクタ
      1. (略)
    3. ゲームの流れ
      1. 各アクションステージは以下の3パートを混成
        1. 探索パート : フリースクロールの3Dパート。移動、斬撃、ロックオンによる射撃。落ちても飛べるのでプラットフォーミングは控え目。
        2. スクロール面 : 強制スクロールのシューティングパート。会話デモ等。
        3. ボス面 : 巨大ギミックの登場。操作は探索パート同様。
      2. アクション
        1. ロックオン : キャラクタの向いている方向の敵キャラクタは自動的にロックオンされる。カーソルは出るが目安。最大8体。
        2. ダブルロックオン : 斬撃のヒットする範囲に敵キャラクタを入れるとダブルロックオンされる。ダブルロックオンは1体のみ。カーソル形状はダッシュ方向を示す。
        3. ダッシュ : ロックオンしたキャラクタの方向にダッシュする。ダッシュ中は無敵。
        4. バックダッシュ : 逃げる方向に方向キーを入れながらダッシュすると、逆方向にダッシュする。こちらも無敵。
        5. 斬撃 : 剣を使用した斬撃。周囲のキャラクタにもヒットする。
        6. ショット : ホーミングショット。斬撃との打ち分けは自動。ロックオンしたキャラクタにダメージを与える。

10ページそこそこといったところか。。これにシナリオの概要と絵とかを用意してパワーポイントにする。ここまででQ1。Q2でベンチマークを計画し、各プラットフォーム上で本当に実現できるのかを検証する or Windows上でプリプロ。
teslawireの作業で一番ボリュームが有るのはオーサリング環境の制作とメンテナンス。ポリゴンで作ったステージをスプライトベースに打ち直す方法論を考えないといけない。当然ステージのプランニング段階でそれを織り込む必要も有るが、演出ノウハウが無いので難航が予想される。

nmosh Retrocomputing edition

上述の"別件"。nmosh REは、8bit / 16bitアートのためのコンパクトな処理系を目指すもので、SchemeではなくC関数またはBIOSコールをサポートした単純なbytecodeマシンをnmoshの動作するホストから透過的に制御するもの。
いわゆるレトロPCやゲームコンソール、産業機器のプログラミング請け負いを結構やってきたけれど、そのノウハウ(デバッグとかビルドとか)をもうちょっと一般的に使えるパッケージとして提供すれば需要有るのではないか。と。計画等はまだまだ未定。8bitにいきなり取り組むのは難しそうなので、最初はWin16とかMacOS Classic、ITRON等を攻めていくことを考えている。実機の入手とかROMの調達等に結構コスト掛かる。
Ancient SDKシリーズが唐突に始まったのはこのため( http://d.hatena.ne.jp/mjt/searchdiary?word=*[Ancient%20SDK] )。
今月というか暫くは具体的作業は無し。リサーチ段階。