ホーム > minahito

minahito

記事一覧 > minahitoの鯉日記

セイクリッド ファイア

今日はOSCのあと、スイスから来日したgigamasterさんとずっと飲んでたんですが、興味深い話があった。gigamasterさんたち(ヨーロピアンかスイスのフランス文化圏?)は passion のことを聖なる炎 secred fire と呼んでいる。この secred fire を失った人間は生きる屍 zombie になってしまう。 zombie となることは怖るべきことであり、 secred fire を再獲得しなければならない。

secred fire を失うのは大人だけでもない。両親に愛されなかった子供が zombie になる。セラピストが彼等が secred fire を取り戻せるようにサポートする。secred fire を再点灯するために secred fire が必要なら、もはや自力では難しい。誰かの助けが必要だ。

gigamaster はポルトガルで生まれ、一家はカーネーション革命の混乱の中でポルトガルを脱出。その後、giga さんはスイス西側フランス文化圏に移住した。giga さんがポルトガル語、フランス語と英語の3つの言語を使えるのはどうやらこういった事情があってのことらしい。

彼は元々プロのサッカー選手だった*1が、大怪我で選手生命を絶たれた。まだ若く希望と野望に燃えていた彼は、このアクシデントで心を砕かれ、 secred fire を失い、 zombie になったそうだ。しかし彼は secred fire を取り戻し、新しい目標に向けてそれを燃やし続けている。

覚えておこう。僕たちのパッションは、人を人たらしめる聖なる炎であり、それが消えれば生ける屍となる。情熱に逆らう決定は自傷行為であり、聖なる炎にションベンをかけるなんて二重の意味であり得ない。聖なる存在なのだから自分以上に尊く、そしてそれが自分を自分たらしめる。西洋的な表現だけどその通りじゃないか。わしゃー 100% agreement じゃけん。

*1:弟さんはまだ現役だそうだ

現状説明

http://cyberbloom.seesaa.net/article/142119459.html

リンク先の記事は肩叩きに追い詰められ自殺した従業員の悲劇について語られており、その他の従業員の状況を含めて何の救いもない。読むには覚悟が必要だが、「新興国を含めた〜」以降の文章は多くの人の賛同を得るのではないだろうか。そうこれこれ!まさにそういうこと!という感じで。

この文章で、今の自分たちの行動を文字どおり明文化できる人も多いと思う。僕も10年前に感じた未来への予感を、こういう言葉できっちり明文化できれば、両親と関係断絶するほどの大喧嘩にならずに済んだかもしれない。特に次の一文は多くの人にとって、今の自分を説明する総括になるんじゃないだろうか。

つまり現代の労働者は自分を事業主としてセルフ・プロデュースしながら、市場で競争し、常に生産力を高めていかなければならない。

これを年齢無制限&世界規模でやってるんだから凄い話だ。10年前の予感は、こういうことを日本規模でやるんだという予感に過ぎなかった。いま起こっているのは手を挙げれば誰でも参加できるオリンピックだ。

[#xoopscube]Webアプリケーションフレームワーク

フレームワークを採用すると、ある特定のジャンルに強くなる代わりに他のことに弱くなる。しかしジャンルごとにラージスケールのフレームワークを作るわけにはいかないので、その中でも共通モジュールとなるもの*1をコアとする。フレームワークはレイヤーで分離しなければいけない。と考えてました。

例えば、30フレーム未満のFPSと、60フレームの1on1対戦格闘では求められているロード時間、グラフィックやアニメーションの精度、コリジョンやAIが全然変わります。そんな中で共通に用意できる下位機能はおのずと限定され、モジュールの再利用を促すランタイムシステムが重要になってくる。それをうまく作ることでオールジャンルの下支え構造ができる。

……という話なんですけど、はたと気づいたんですが、Webアプリケーションってそれ自体がひとつのジャンルなんですね。だからみんなフレームワーク、フレームワークって言ってるんだ。こんだけフレームワークがあっても設計がほとんど同じだし、RubyがRailsだけで済んでる理由もそれか。

*1:例えばメモリアロケータや数学ライブラリ

[#xoopscube]オンラインミーティング

XCL 2.2 の残りの開発の進め方を確認するためにオンラインミーティングを開催します。たぶん Skype になります。

http://sourceforge.net/apps/phpbb/xoopscube/viewtopic.php?f=15&t=188

17日(日)にやります。

午前中がいいだろうと思ってます。

Skypeの接続限界までなら誰でも参加OKです。簡単な議事録も後で出します。

就職氷河期は大学生が増えただけ、就職者は微増?

昨日モーニングを買ったら、ドラゴン桜の外伝みたいなんが載っとった。漫画の話を鵜呑みにするのもなんじゃけど、ちょっとびっくらこいたんが、就職率の話。

新卒就職者の数は年々微増していて、絶対数は全然減ってないんじゃと。じゃあなんで就職率が下がるんかというと、大学生が増えたからなんだそうな。

日本は、時代に合わせて自営業者が激減して、サラリーマンになりたい人がものすごく増えとるんじゃと。で、みんな大学に行って会社員になるために就活するじゃろ*1。この分母が増える勢いが、分子である新卒入社枠の微増ぶんを完全に上回ってしまっているので、結果として就職率が物凄い勢いで下落してしもうたらしい。

なんであれ、多くの若者が職につけないのは事実。さりとて、景気に関わらず、この就職率を抜本的に改善できるほど企業側が新卒枠を広げるのは限界があるので、社会も学生も新しい道を探らなければいけない。というような話だった。詳しくは買って読んで!

自営業者が激減したのは企業に飲まれたからなんでは、という気もするけど、でもそう考えると少子化というのも自然な成り行きなんかなぁ。少子化すれば内需が減って先細り云々というけど、どっちにしろ外需開拓しかありあえない状況なんじゃけー、みんなが健全に生きていける程度の人口まである程度縮小して、それで熱く戦っていく社会っていうのもアリなような気もするけど。

まぁでもこれからの時代、国外も就職先だと思うので、分子も増えるんじゃないかという気もする。

追記:

やっぱそんな話があるんじゃ。

http://hakasenoikikata.com/posdoc_report05.html

ちなみに、学部生の就職率が下がってきているのは、就職先が減ったということよりも大学生の数が増えたことに原因があると指摘されているようです。

*1:個人的には、女性の社会進出もあると思う

[#xoopscube]ITの人らの凄いところ

ゲーム/アニメ業界の人間は、他社の凄いゲーム、アニメ、映画を観ると、自分も何か(そのパッションでダーッとなる何か)を作りたいと思う傾向があると思う。作ること自体が一種の娯楽だと考えとるフシがある。

ITの人ら(特にWeb!)と話すと、ほとんどの人が、凄いものがあるならそれを共有すればようて、手を動かすならもっと全然新しい何かを作り出さんと意味がないと考えとる人が多いと感じる。その精神性が常に革新を生み出しよる秘訣なんじゃないかと思いました。

まぁ、どっちにしろ、やろうやろうと言いよるだけで9割9分の人間が実際には何もせんという点だけは共通しとりますが。orz

XCを設計したとき、「ものを作ること自体がエンターテイメントなので、商用無償CMSが来てもXOOPSみたいなのは無くならないですよ」みたいな話をして鼻で軽く笑われたことがあった。

今はそれが凄く分かる。(-_-;;

XOOPSもIT系のものだから、僕は凄いミスマッチなことを言うとったわけ。

世に無償ゲームが溢れても同人ゲームを作る人はいなくならんけど、Googleが無償CMSを出したら同人CMSを作る人はおらんようになるかもしれん。

その代わり何か別のものを生み出すんだろう。

そういう気質はリスペクトして、盗まんにゃいけん。

シングルプレイヤーモードはマルチプレイヤーモードの特殊ケースである

 Game Engine Architecture の 1.6.14 Online Multiplayer/Networking の節に次のようなことが書かれています。

It is interesting to note that going the other way --- converting a multi-player game into a single-player mode --- is typical trival. In fact, many game engines treat single-player mode as a special case of a multiplyaer game, in which there happens to be only one.

 続きに Quake がそうだったでしょ、と書かれているのですが、そう言われてみればそうだった……

 言われるまで、あれはあの時期の洋モノエンジンのやり方であり、現代の(特にインハウスの)ゲームエンジンアーキテクチャにおいては別物という印象を持っていました。イカンイカン。

Game Engine Architecture

[ゲームエンジン][UDK]続・Unreal Development Kit

 アナウンスを意訳しましたが、日本語のドキュメントも出始めているようです。とりあえずどうぞ。

--------

 Epic Games 社は Unreal Development Kit (UDK) のローンチをアナウンスします。これは、受賞暦のあるツールセットへのコミュニティアクセスを提供する Unreal Engine 3 のフリーエディションです。3Dゲームエンジンテクノロジーに興味のあった方ならどなたでも --- ゲーム開発者、学生、ホビイスト、研究者、3Dビジュアライゼーションやシミュレーションのクリエイターそしてデジタル映画製作者 --- このソフトウェアリリースを利用することができます。 www.udk.com で UDK をダウンロードし、業界トップの Unreal Engine 3 ツールセットに取り組むことができます。また www.udk.com では、詳細な製品フィーチャー、テクニカルドキュメント、コマーシャルライセンス条件、サポートリソース等々を提供しています。

 ゲーム開発における空前の重大事件、UDKのリリースは世界一のビデオゲームディベロッパーとパブリッシャーによって使用されているものと同じワールドクラスのツールとテクノロジーへのフリーアクセスを提供します。 Unreal Engine 3 は絶えず発展するゲームエンジンであり、 UDK は( Unreal Engine を使用したゲームではまだ使われていない)ここ最近追加されたフィーチャーや技術的強化をすべて収録しています。さらに、 Epic Games では今後も UDK をアップグレードし、フリーでリリースを続ける予定です。

(中略)

UDKのベネフィットは以下のとおりです:

  • トップレベルの開発ツールの中でも完全な統合型スイートである Unreal Editor がコンテンツ開発を容易にします:
    • Unreal Content Browser - メタデータ・タギングシステムと協調するゲームアセットを閲覧、検索、整理できる革新的なツール
    • UnrealScript - オブジェクト指向のプログラミング言語。 Unreal Kismet は迅速なプロトタイピングを可能にするビジュアルスクリプティングシステムを提供します。
    • Unreal Matinee - インゲームシネマとゴージャスなカットシーンを構築するための映画監督レベルのコントロールを持った強力なツール
    • Unreal Cascade - 炎、フォグ、爆発などのビジュアルの作成を補助する先進的なパーティクルフィジックスと環境エディタ
    • NVIDIA PhysX - 強力なフィジックスシステム。キャラクターやオブジェクトフィジックスリグを作成するためのビジュアルモデリングツールである Unreal PhAT もついてます。
    • Unreal Lightmass - アーティストとデザイナーの負荷を最小限にとどめるグローバルイルミネーションシステム
    • AnimSet Viewer と AnimTree Editor - どんなマッスル/ボーンムーブメントであっても正確なコントロールをアニメーターに提供します
  • SpeedTree、Bink Video と FaceFX といったリーディングゲーム開発ミドルウェアの技術的インテグレーションによって開発にかかる時間を短縮できます
  • スタンドアロンアプリケーションのアウトプット: UDK で作られたゲームは完全にそれ自身で動きます。追加ソフトウェアは一切要求されません。これは誰でも UDK コンテンツを作成して、自由に配布できることを意味しています。

(後略)

--------

 省略した部分ですが

  • 従来、 Unreal Engine 3 への非営利アクセスはアンリアルトーナメント3とギアーズオブウォーのPC版に付属している Unreal Editor を使用した MOD 活動に限られていた。しかし、UDK ではスタンドアロンゲームを開発できる
  • アンリアルトーナメント3の MOD "The Ball" を UDK ベースのショーケースとしてダウンロード可能
  • 多くの教育機関で Unreal のテクノロジーが使用されている。 UDK もぜひ使って欲しい。
  • 200ページオーバーのドキュメントが udn.epicgames.com で参照可能
  • www.udk.com/forums にフォーラムを用意している
  • 有償頒布に使うなら www.udk.com でライセンス条件を確認のこと。インディペンデントディベロッパーや新興企業からまでガッツリとライセンス料をとるつもりはない。

 といったところです。

[ゲームエンジン]Unreal Development Kit と Unity 3D の件で思うこと

Unity 3D のフリー提供に続いて、非営利目的に限りではありますが Unreal Engine 3 のカスタム Unreal Development Kit のフリー提供が始まりました。欧米のゲームエンジン業界で、いま何が起きてるんでしょう。

かつての個人的な予測を書きますが、

今後、コンテンツやサービスはないけど技術力のある会社はミドルウェアに走るという傾向が、Web3Dの本格化でさらに加速するだろうと思っていました。そのラットレースがしばらく続いた状態から、耐え切れなくなったどこがミドルウェアの無償化を始めて、どんどんそうなる……みたいな展開かなと。

その読みは Unity 3D クラスのエンジンがいきなり無償化を始めたことで崩れ去ったんですが、いま思えば Torque が 100 ドルになったときにラットレースは既に始まっていたのかもしれません。

もちろん Unreal Development Kit の話は Maya でいうところの PLE にあたりますから、インディーズ向けエンジンの無償化とは別の話。ゲームデザイナー志望の学生さんたちが level-based ゲームデザイン*1で求められるスキルをひととおり身につけられるのは素晴らしいことだと思います。

そのまま日本スキップして欧米で就活しそうで怖いけど。

*1:さっそく使ってみた

[ゲームエンジン]Level-based

欧米では、(日本でいうところの)ステージありきのゲームデザインは Level-based って呼んでるらしいです。英語的にはそのまんまという気がしなくもないものの、皆が言い揃えているなら素晴らしい。いずれにせよ、日本人には便利な言葉です。

カタカナ的には、レベルベース、ステージベースでしょうか。プラットフォーマとも言うらしい。

ゲームエンジンとゲームエディタに対して、「これでパラッパラッパーみたいなのが作れるんですか」と言われたら、それは「レベルベースのゲームエディタでパラッパが作れるか」という表現で、課題に落とせばいいんですね。ああこれは便利だ。

[#xoopscube]OSC2009 Tokyo/Fall

東京は蒲田で開催されましたOSC2009 Tokyo/Fallに参加して来ました。Tom_G3Xさんの尽力でブースとセッションを行うことができましたが、次回からは東京組もコミットメントできればと思ってます。何度か書いてますが、1月あたりから仕事がだいぶ落ち着きますしね。

セッション

今回はネットワークインストーラがテーマだったんですが、僕がMacの故障でクライアントソフトを仕上げることができず、id:tohokuaikiさんのサーバーサイドのネットワークインストーラの紹介とデモがメインとなりました。しかし時間を考えるとこれでよかったような気がします。

感想としては、もうtohokuaikiさんの実装でいいんじゃないかと。(^_^)

クライアントサイドの実装は急がなくてもいいなと思いました。tohokuaiki版の実装があれば少なくともXCL2.2のパッケージ肥大化抑制の目処は立てられます。SSHのサーバーではSFTPを使うという話でしたが、コマンドライン実装がひとつあればいいかもしれない。

あとクライアントからサーバーサイドのネットワークインストーラを叩くという手もある、とのサジェスチョンもいただきました。

ブース

XOOPSでグループウェアパッケージを作ってるbluemoonさんのブースが隣だったんで色々話を聞きました。今度詳しく書きますが、新型BASEや新しいレンダーシーケンスで試行しようとしていることが、Drupalに近いらしい。

Drupalは大昔にちゃんと研究したつもりだったんですが、そのときは見かけなかった仕組みでした。

で、Drupalのブースも同じ部屋だったんで話を聞きに行こうと思っとったんですが、 id:LYE さんとのお昼御飯でガッツリ話し込んだらエネルギー使い果たしてしまって、聞きにいくパワーが残ってませんでした。(^_^;)

最後にDrupalブースの集合写真を撮って差し上げたので、次会ったときにきっと色々教えていただけるに違いない。

Drupalに限らず、他のブースはほとんど回れませんでした。ほんとに体力尽きてた……

飲み

そのあとohwadaさんの呼びかけで居酒屋に集まって一杯やりました。早い時間から飲み始めたんで、サクッと切り上げられてよかったです。

まとめ

今回は自分のぶんを仕上げることはできませんでしたが、今回を皮切りに「1イベントには1つの新しいテクノロジ(?)を持っていく」というポリシーをもって活動したいと思います。

仕事が落ち着くまであと二ヶ月です。

[日記]熱量の敗北

こないだNHKの番組で、膵臓癌の治療薬開発の話をやっとったんじゃけど……

なんでも日本の研究は補助金頼みで、その補助金も7000万くらいしかないらしい。対してアメリカは30〜40億の予算を確保し、治療薬開発で大きく世界をリードしとるそうな。

あーあ、また資金力の差か……と思ったら。

アメリカでは、膵臓癌で家族を亡くした遺族がネットワークを作り、癌の撲滅のために、自らも寄付し、そして各地のイベントで寄付を募り、自らロビイストとなってワシントンD.C. の有力議員に陳情を繰り返したんだと。

そんで寄付だけでもそれなり(数十億)を確保し、ロビー活動でも安定した国家予算を獲得した。

その膵臓癌ネットワークのNPOの人がインタビューに答えとって、

「研究開発者には開発を進めて欲しいのです。政治家への陳情は私達でもできます。彼らがワシントンD.C.に来て、そういったことに時間を割く必要はないのです」

と言うとった。

このストーリーはショックじゃった。これって、国家システムや資本力の差じゃないよね。人間の熱量の差なんよね。

実は日米のゲーム開発の差も、熱量の違いなんじゃないかと感じることが多くて……それなりにショックじゃった。

色々思うところもあったけん、この話を色んな人に話したんじゃけど、こういう考え方もあるって教えてもろうた。

  • NHKが真実を放映してない
  • アメリカのセレブが多数いて多額の寄付が可能だったことは世界の歪み
  • 膵臓癌ネットワークは医療貢献を隠れ蓑にした不当な組織に違いない

もはや目を背けるしか他に道がなかったら、使わせて頂きます。

Mutable なエンティティモデル(2)

可変実装を考える前に、不変実装を振り返ってみます。

XCLはcubsonというコードジェネレーターを使っています。元がmojaLEというmojavi2のX2適用サブセットのカスタム版ですので、若干古いのですが、プロパティの追加/削除程度の改変であれば、さすがに対応することができます。

モデル定義コードの変更

プログラムで使用しているモデルクラスが新しいプロパティを受け入れられるように、プロパティの定義を追加する必要があります。XoopsObject のシンプル版である XoopsSimpleObject のサブクラス実装がエンティティモデル毎に定義されていますので、そのダイナミックプロパティリストの初期化コードに、新しいプロパティ定義を追加します。

UIの変更

次に、必要があれば(たいてい必要ですが)、プロパティの入力を受け付けるためのUIを追加します。ほとんどの場合、テンプレートにHTMLコードを追加することになるでしょう。

グルーコードの追加

追加したUIアイテムと、モデルのプロパティを結びつけるグルーコードを追加する必要があります。cubsonスタイルではアクションフォームがこの役割を果たしており*1、アクションフォームにプロパティと検査を追加し、モデルの値を読み書きするメソッドにコードを追加します。

この箇所の汎用自動バインディングがあってもよかったのですが、ついに作られませんでした。世の流れを見るに、バインドは名前で縛り、UI入力検査もデータモデル検査にまとめてデータモデルのほうに書いてしまうというのが流行のようです。

アップグレード

cubsonスタイルの場合、というより、X2とXCL自体がデータソースの抽象化をモジュールに提供しないというポリシーのため、既存のデータソースにプロパティぶんの保存域を追加するコードはそれぞれのモジュールで書く必要があります。

*1:cubsonスタイルはUIにバインドされるのはアクションフォームという考え方です

[#xoopscube]Mutable なエンティティモデル(1)

cube.jpで、簡単にフィールドを追加可能なテーブルについて話題が挙がっています。

http://xoopscube.jp/forum/6582?comment_id=20210

最近では 2.2 の同梱モジュールである profile に同様の機能が実装されています。

モジュールをインストールしたユーザーがある程度フィールドを拡張できれば、モジュールを色々な用途に使うことができるでしょう。あくまで MODify 行為と割り切れば、振る舞い(機能)と、その振る舞いに強く結びついたフィールドの編集をロックすることで、大まかな問題をクリアにすることができます。

これまで何度か可変テーブルに関する議論がありました。こういった技術は各モジュールでそれぞれ実装するのではなく、ライブラリとして提供され、モジュールの開発者はそれを使うだけでよい、という形をとることが望ましいでしょう。

そのうえで、主要な検討項目として、まず以下の3つを挙げることができると思います。

  • 全モジュールを mutable なデータモデルで統一するのか、それとも選択式にするのか。
  • システムが提供するシステムAPIになるのか、システムパッケージが実装モジュールを提供するのか。
  • 1レコードのコンテナ形状でテーブルを作り、 alter table でフィールドを増やすのか。あるいは eZ publish のように、動的で仮想なテーブルのみを持つようにするのか。

最近、僕のほうでは、

  • mutable モデルはオプション。
  • システム(BASE)パッケージが実装モジュールを提供、あるいは標準提供なし。
  • どの実装で用いられるかはどのモジュールを使うかで決まる。

という形に持っていくのが良いのではないかと考え始めています。

まず、選択式にすることで、データモデルをテーブルの完全なバインダとして扱いたい開発者のポリシーを保障することができます。パフォーマンスを重視する開発者や、SQLを使って複雑な処理をRDBMSにリクエストできる開発者には重要なことだと思います。

次に、インターフェイスと実装を分けるのはモジュール設計として当然であると同時に、適用の広さと最適化のバランスをユーザーが選択することができます。想定しているのは、パフォーマンス面で有利な alter table を用いる方式が、レンタルサーバーによっては使用できないというケースです。

仮に「誰でも導入可能」という点を重視して、 eZ publish と同じ実装を採った場合、自由度と引き換えに、モデルをまったく変更しないユーザーにも遅い動作を強いることになります。しかし、パフォーマンスを重視して alter table の実装を採れば、一部のユーザーはカスタムフィールド的なフィーチャーを一切使用できなくなるでしょう。

実装部をモジュール化すれば、ユーザーが希望に応じた実装を選択して導入することができます。

それはつまり、このデータモデルを取り扱うAPIは公約数的なものになるということです。幸い?XCのデータモデルはデータソースをRDBMSに絞らない方向で設計される予定ですので、少なくともそことの齟齬はありません。

以上は、データソース特有の操作を隠蔽したライブラリ環境下で成立する話です。ある程度 mutable なモデル定義を用いたいが、ロジック中ではガンガン SQL を書きたいという開発者は、別途ライブラリを用意したり、自前で実装することができます。

ライブラリ化するといっても、あくまでアプリケーション用ライブラリであって、ハードウェアAPIではありませんので、用意しなければ直ちに開発者から選択肢が奪われる、というものではありません。これはXOOPSファミリの伝統的な選択と言えます。

最後に少し eZ publish のフォローをしますと、 eZ publish にはページ単位の強力なフルキャッシュ機能があり、 mutable モデルのデータはそこまで頻繁に更新されないという前提で作られています。フォーラムさえ非固定なテーブルで、テンプレートでトピックを表示する仕掛けはかなり面白いです。

[#xoopscube][OpenGL]WebGL

かなり普通に動くじゃないですか。

う、これで行列演算は GL 派が増えてしまうのか。(><)

http://journal.mycom.co.jp/news/2009/10/22/041/index.html

シーングラフのベタ移殖とかありそうじゃのー

XOOPS Cube プロジェクト的にもうまく使っていきたいですよね。専用クライアントを接続してでも3D使おうとしてきたんですから。

[Mac]もう修理に出すしかない

USB接続でもディスクを認識してくれませんでした。

もう修理に出すしかないな、と思っていたところに新型Mac発表です。

やっとハードウェアスレッド搭載コアのiMacが出ましたね。

と思ったら、27インチだったんですけど……置くとこありません。

しかしmac miniにも性能抜かれたのー

2年くらいしか経ってないはずなのに……

なんにせよ修理です。

保障かけてなかったことをマジで後悔。

なんぼするんかのー。

[Mac][日記]自宅Mac完全故障

OSC\(^o^)/

前に一度ディスク破損が起きてた自宅のiMacが完全に故障しました。最初は、ついに内蔵ディスクが昇天したか→外部ドライブからのブートに変更するか……程度に思っていたのですが、FireWireごと認識しやがりません。

f:id:minahito_carp:20091020093331j:image

なんかそのへん一帯のコントローラごとメゲたんじゃないかと思います。データは外部ドライブにTimeMachineで退避させているので、ブートボリュームさえ作れれば環境の復元はできますが、この状況では修理に出すしか……

と、ここまで書いて気づいたんですが、USBキーボードとマウスは認識できとったんで、ドライブをUSBで接続したら認識するかも?たぶん問題はデバイスコントローラじゃないと思いますけど……帰宅したら試してみます。

ただ、USBから起動ってできたかのぅ……

で、やばいのはとにかく OSC です。

OSCでネタする対象のソフトの開発環境がこのMac。

まぁソースコードは無事でしょう、間違いなく。

ただ、起動できんことには開発が続けられません。いま自宅にマシンはこれひとつしかないんです。

となると、同一ネタの別実装でid:tohokuaikiさんと1セッションを半々に分割するつもりだった僕らの計画は……

とりあえず今夜USB作戦に失敗したら、ガチで対策考えます。

[#xoopscube]関数コールバックかインターフェイスか

 xoopscube.jpでのonokazuさんのこの書き込みはかなり的確なところをついている。コンセプトとしてはその通りで、ただし、対して僕はコールバック設定リストではなく、インターフェイスないしは抽象クラスを使うかもしれない旨を書き込んでいる。

 話としてはそこに書いたとおり、インターフェイス実装はそのインターフェイスを提供するパッケージとズブズブの関係になってしまうことを意味しないという話だ。とはいえコールバックにすればその"見た目の関係"はもっとすっきりしたものになる。まして XC には仮想デリゲートが用意されている。

 にも関わらずインターフェイスクラスを作るかもしれないと書いたのはパフォーマンス上の理由によるものだ。とても面白い話なので、少し補足する。

 C言語やC#のように「関数アドレス」をハンドリングすることができる言語では、モジュール間の接点を関数コールバックで行うことで、依存性を大幅に下げることができる。一方、関数アドレスがハンドリングできないJavaなどではインターフェイスにレスポンスするコードを実装して、それをコールバック発信主に登録するという方法が多用される。Listenerクラスが代表格と言える。

関数ポインタ

 最近見かけた実例として、組込スクリプトエンジンのリモートデバッギングまわりの構成を挙げる。スクリプトエンジンのランタイムはターゲットマシンで動作し、PC上のリモートデバッガと接続して、互いにパケットを送り合っている。

  • VM モジュール
  • VM とリモートデバッガの間に流れる、メッセージコマンドと送受信データの仲介役を行う DebugSession モジュール(Debuggeeにちと近い)
  • ネット通信コードが記述されている NetClient モジュール

 この設計では、 VM は DebugSession を知らず、 DebugSession も NetClient を知らない。そもそも NetClient はスクリプトエンジンパッケージに含まれてもいなかった。

f:id:minahito_carp:20091017142219p:image

 これらのシステムはコールバックの接続で連携を行う。そのグルーコードはタイトルパッケージに含まれる AppScriptEngine の static メンバ関数に記述され、 init() で接続を行う形をとった。

 各モジュール間には依存性はないため、簡単に別物に取り替えることができる。「オーバーライドで拡張が容易」という表現ではなく「完全な別物と変更可能」になる。より高性能なリモートデバッガ資産があれば、それに対応した Debuggee を用意(移植)すればいいし、 NetClient はターゲットマシンのカーネルAPIベッタリのコードに差し替えることになるだろう。変更すべきはタイトルパッケージ所属のグルーコードだけだ。

 特に NetClient はスレッド動作することになるから、独立していることは有り難かった。この実例では、 DebugSession がメッセージをポーリングするコールバックと、送信したいメッセージを書き込むコールバックの2点があったので、 NetClient モジュールの同等のメンバ関数へ中継するグルーコードを記述した。

 外向けのロッキング(スレッドセーフ対応)も NetClient 内のわずか二箇所に留まっている。

 ローレベルの接続は、とてもC言語らしい書き方だが、C#でもデリゲートの用途としてお馴染みのやり方になっている。後述するが、もうひとつのやり方である「インターフェイス実装」は、単一継承しかできない言語ではステップがややこしくなることがある。C# などは単一継承ながらデリゲートが使用できるため、ケースバイケースでそれを使い分けることができるのが利点だ。

インターフェイス

 これもよく使われている方法で、Objective-Cのデリゲート(正確にはプロトコル)もこちらのタイプにあたる。インターフェイスを通じた通信は必ず同一のインスタンスに送信されるため、実装が非常に楽で、接続もインスタンスアドレスの引き渡し一発で済むというメリットがある。

 ただし、裏を返せば、関数ポインタやC#デリゲートのように接続の組み合わせが自由ではない。よって、インターフェイスに対し行われる通信を複数のモジュールで受け持つ構成を作る場合は若干手間がかかる。最低限として各モジュール間の独立性を保つにしても、ほぼアダプタークラスが必須になり、それを更にグルーコードから切り離そうとすると、2層3層の構造になってしまう点も若干面倒と言える。

 先のスクリプトエンジンの例を単純にインターフェイスを通じたコールバックに変更するならこのようになるだろう。

f:id:minahito_carp:20091017142532p:image

 ただし、これは C++ のケースで、 Java や C# では mix-in を使わない限り単一継承なので、もう1層間に入ることになる。

 といっても、基本的にはジャンプアドレスをどういう形で引くかの違いでしかない。関数ポインタを使って関数のアドレスを直接ハンドリングするのか、インスタンスを引き回す形でプログラムしておいて、関数アドレスの解決を vtable に委ねるかどうかの違いだ。基本的にはコードを書く側にとっては「表現方法の違い」の部類に入る。そういう意味では宗教戦争の誘因材かもしれない。*1

 先ほど書いたように、C#の場合はデリゲートとインターフェイスをケースバイケースで気軽に使い分けられるのから強力である。C++も同じだが、関数アドレスには型の問題が残りがちで、インターフェイス実装インスタンスの引き回しでは参照解除/メモリ解放タイミングがしばしばトラブルの要因となる。 Java や C# はリファレンスのメモリ管理があるからこのへんは気にしなくていい。

なぜインターフェイスを使うかもしれないのか

 XCにデリゲートを突っ込んだことからも分かるように、個人的にはローレベルのフィーチャーが好きだ。アダプターを挟まなくても各モジュールの独立性を保てる点からいっても、インターフェイス実装より、関数単位のハンドリングとコールバックのほうが、XCのコンセプトに向いている。*2

 しかし、パフォーマンスを考えると、PHPではインターフェイスなり抽象クラスなりを使わざるをえないのではないか。

 PHPではJava同様、関数がハンドリングできない。そこで文字列をパラメータにして、専用のコール関数を使ってコールバックを行う。文字列の時点では関数のシンボルは解決できていない。だから、関数のグローバルシンボルテーブル内を、文字列を使ってハッシュ検索して、都度シンボル解決してることになる。しかもその後関数オブジェクトを掴めるわけでもないので、コールのたびにこの負荷がかかる。

 一言で関数コールバックといっても、シンボル解決済みの素のアドレス情報をそのまま使って即ジャンプするC言語と、文字列からシンボルテーブルを都度検索するPHPでは、実行負荷は大きく違うものになる。そう、このエントリでは関数ポインタとインターフェイスを比較したが、関数ポインタなんてものはない。となると、判断は変わってくる。

 インターフェイスや抽象クラスにしておけば、それを実装したサブクラスのインスタンスのテーブルのメンバを検索すれば済むことになるから、ずっと軽いのではないか。

 コールバックの種類(機会)が増えれば増えるほど、パフォーマンス的にはインターフェイスのやり方のほうが有利になる。この負荷の違いが、種類×量に対してかかると考えると、どうせ同じことができるならインターフェイスのほうが良いのではないかと思えてしまう。それがインターフェイス実装スタイルを採用することになってしまうかもしれないと書いた理由だ。

 繰り返しになるが、アダプターを書くだけの話なので、これが独立性の高いプログラムモジュールを外部から突き壊す要因にはならない。

*1:見たことはないが

*2:この際 Object Oriented は忘れよう

[誰得]広島弁が抜けん謎

 ついにブログまで広島弁になってしもうたわけじゃけど、さすがに昨日の記事は読めませんって色んな人にメッセもろうた。すみません……

 はてなのキーワードのリンクも変なところに貼られるしねぇ。せにゃあいけん、せにゃあいけんとか書いとったら「あいけん」とかいうエロ漫画家のキーワードにリンク貼られてからに……わし "このエロ漫画家を含むブログ" として延々とヒストリに掲載されとるんよね。(><)

 でも頭じゃ広島弁で考えよーるけーねー。昔は、広島弁じゃとATOKがうまいこと変換せんけー、たいぎーけー普通に書きよったけど、最近なんか大体通るんよねぇ。ATOKも凄いけー。

 勿論、リアルでも広島弁抜けとりません。と言っても、わしの場合、ベースは石見弁じゃけん、石見弁と広島弁のハイブリッドなんじゃけどね。じゃけんどしたん!

 にしても、島根広島で9年9年あわせて18年のときを過ごした未成年時代を終え、ぼちぼち関東圏での生活が一番長うなってきようるんじゃけど、なんで広島弁が抜けんのんか。今日もアンチャーテッド2をみんなで会社でやりながら、

「いや、そこたわんですよ!」

「ここたう?ここジャンプしてたう?」

「うわ手すりめげた!」

 とひたすら、"たうたう"など連呼してました。まぁ"たう"と"たいぎー"は、ほんま抜けんらしけー、しゃあないけど。

 まぁ、なんといいますか、広島弁を隠す暇もないアンチャーテッド2の手に汗握る作り。本物です。

 そがなんじゃけー後輩と話すときはずっと敬語です。常語にしたら石見/広島弁になるけーね。さすがに東京の会社で広島弁で話するわけにはいかんけー。

 じゃけど、なんなんかねー。

 原因がよう分からんのじゃけど、学生時代にこれまた全く高知弁が抜けとらん奴とつるんでお互いの方言で喋りまくっとった挙げ句、関東出てきてから同期があんまおらんかったのが原因かもしれん。矯正のチャンスがなかった。

 アニメーターの頃は同期と普通に話しとった気もするけど。あんときゃ抜けとったかねぇ。

 でもだいぶ抜けてきょーると思うんじゃけどねぇ。

Scripts load multi-assets

 いま、ちょっとした実験コードを書きょーるんじゃけど……朝までに終わるんか分からん。眠い。

今回のネタは、ゲームプレイコードのオブジェクト……すなわちゲームオブジェクトが、

  • C/C++ で書かれたステートマシンで状態を渡り歩きながらロードと転送を処理していくんじゃのうて、
  • スクリプトのコルーチンで "式次第を消化するように" やれんかのーというもの。

 アピアランスとビヘイビアの両方に関わるゲームオブジェクトは、地勢、メッシュ、コリジョン、モーション、エフェクト、フィジックス等などの各専門モジュールのデータをハンドリングする。そのためにこれらの専門モジュールにアセットのロード(読み取りと構築)を依頼せんといけん。

そんだけじゃのうて、パラメータとかのゲームタイトル用の多種多様なデータを読み取って、データの生成やモジュールへの引き渡しを行わんにゃあいけん。

 それは開発当初では一種単品でも、終盤には複数種複数になり、それらのデータの連携動作などを大量に書かんといけんことになっとるかもしれん。いずれにせよ、「これをこう表現したい」「こうしたい」というゲームデザイナーの要求は開発の進行とともに変化する。

 思うに、少々下手な設計でも、アセットのロードが終わってしまえば、それらを繋ぎあわせたり、仕様通りに振る舞うようにすることは難しゅうない。データをハンドリングするメンバ変数を拡張して、アップデートプロセスにコードを書き足しゃあええ。

 面倒なんはロード行程じゃと思う。じゃけん、ゲームプレイコード側に複雑なロードを書かんでもええように、ゲームタイトル(あるいはエンジンシステム)の中央でコントロールされるアセットロードフレームワークが必要になるじゃろう。こうすると、色んなゲームオブジェクトが、アセットロードフレームワークに依存性を持つことになる。けど、ゲームオブジェクトが、各専門的モジュールと直接喋る必要はのうなる。

 そのロードフレームワークが、

  • 複雑で多岐にわたるアセットのロードを確実に遂行する
  • ロード中に、あるいはロード後に判明した追加リクエストを受け入れる
  • あらゆるモジュールで管理されるキャッシュを検索する
  • サードパーティライブラリによって極端に違うロード行程を隠蔽する
  • すべてのアセットがロードを終えれば通知する
  • あるいは、VRAM等に転送が可能になったデータの単位から、(依頼主がそれを求めるなら)依頼主に通知を行う。*1

 などの能力を持てば、専門モジュールとのネゴシエーションはロードフレームワークが持ち、そのフレームワークにクエリを投げて、すべてが終わるまで待つ、という部分をゲームプレーコードの初期化行程に書きゃあええ。

 これをすべて C/C++ で実装した場合、必要なアセットのロードクエリはバイトデータとして表現されると思う。拡張が必要になれば、コントローラに新たな処理を追加して、クエリのフォーマットに新しい制御コードを追加することになるじゃろう。

そういった拡張は頻繁に発生する。加えて、ひとつのアセットをロードしたことで、そのロードしたアセットの中に含まれているパラメータから別のアセットをロードせんにゃあいけんようになることもある。たとえばメッシュデータにベイクされた情報から必要な別資産をロードする場合などは、汎用であるアセットロードフレームワークには判定できん。一度その専門モジュールにメッシュデータを送りつけることで、初めて追加クエリが判明する。

 こういった拡張は、モジュールの担当者とゲームデザイナーの間で必要に応じてスピーディに行われていくし、実験の結果、断念されることも結構あるけー、とにかく変化に強くなきゃあいけん。

 また、必要なアセットはデータに書き込まれてるだけじゃのうて、カスタムコードから要求される場合もあるじゃろう。たとえば、ある種のゲームオブジェクトはコリジョンデータを使う予定がなかったが、ある非常に特別な役割を担うオブジェクトを表現するためのサブクラスが、その仕様の実現上、特別にコリジョンデータを必要としたとする。

 その1例のために、全データ構造に手を入れるかどうか。

 そういう考え方もあると思うが、カスタムサブクラスから、彼のみが知るアセットの追加ロードをリクエストできて、それをそのアセットの特別なメンバ変数にぶらさげることができれば「一品モノ」を作るフットワークは軽くなる。

 データからロードの計画を立てるということは、計画外のものが出たときに、データの作りから拡張しなければならないということ。ユニークな「一品モノ」が増えれば、 C/C++ に特例のアセットロードというグルーコードが増えてしまう。

長々とわりいの

 やっと話は冒頭へ。そこで、アセットロードフレームワークのコントローラをスクリプトで記述し、必要があればリクエストの依頼主が制御スクリプトを送り込むことができるメカニクスをちょっと思いついたんよ。単純にリクエストをかける場合は、スクリプトで制御されている部分は依頼主からは隠蔽されとるけー、その制御がスクリプトドリブンであることを意識する必要はないじゃろ。で、そのスクリプトの品質を管理できれば、データにロード計画のヒントとなる制御コードをどんどん拡張していくより、シンプルな構造だと思う。グルーコードはスクリプトコードにしとけ、という。

 もう一点、スクリプトがロードの処理に向いているのではないかと考えたんは、上のような状態におけるロードの処理はパイプライン処理であり、ステートと相性がよくないと思ったけーなんよ。たとえば、絵を描くときに、まずパースをとり、アタリをとって下書きを作り、清書して色を塗るように、ロードは順番と終わりのあるパイプライン処理じゃけー。

 決められた種類の決められた量の指定データを順序ロードする。それには追加や順番も存在するが、基本的にはスタートから始まり、有限のループを経て、処理の終了にいきつく。式次第を順序よく消化していく要領で、バックステップするこたぁない。じゃけん、コルーチンとぶち相性ええし、コルーチンは非同期ロード待ちの一手段であるポーリングを簡単に実現することができる。

 超汎用的なフレームワークはデータドリブンでも作ることができるけど、各モジュールと "喋る" 部分をスクリプトエンジンとの会話部分に限定すれば、通信部分は限定的でシンプルになると思うたんよ。それに汎用スクリプトなら、データドリブンなロードも、カスタムロードも両方可能になると思うた。

 しかし正直 "思いつき" でもあるので、実験している次第。でも、スクリプトにデータ流し込みの役割をやらせるという話は、数年前からあったと思う。

*1:このあたりをスクリプトならむちゃくちゃ柔軟に書ける

To Top