本日は敬老の日でお休みです。

salで階層化格子を使った当たり判定を書きました。

でも肝心の物体管理部分がなかなか書けません。多態性を表現する機能が無いのが痛すぎます。salでこのような継承関係を表現するにはどうしたら良いのでしょうか。

• 種類ごとに別々に管理する
• すべての種類を内包できるルーズな構造を用意する

その方面には詳しくないんですが、O/Rマッピングとかではどうしてるんでしたっけ？

種類ごとに別々に管理するのは、将来的に何が増えるか分からない状況では抵抗があります。種類ごとに同じような管理コード(特に未使用IDの管理)を量産するのは苦痛です。templateや、そうでなくても動的に色々やる機構があればうまくまとめられるかもしれませんが、salには当然そんなものはありませんし。

次善の策はある程度余裕を持たせたルーズな構造で継承ツリー全体をカバーしてしまうことでしょうか。ただ、言語仕様上種類によって変数名を変えるようなことは出来ないので、かなり嫌なことになりそうです。lparam, wparamみたいな。ただ、メソッド呼び出し前に別の一時変数へデータをコピーし、呼び出し後に元へ反映させるような仕組みを入れれば多少書きやすくなるかもしれません。オーバーヘッドは伴いますが。

一番良いのは、もっとちゃんとしたプログラミング用の言語を作る、ということなのですが……。

三村智保九段対山田規三生九段は三村九段の一目半勝ち。13時前にいきなり手順のみになったので何事かと思った。しかし、あんなところからセキとか言われても全然わかんない。もう何がなにやら。恐ろしい対局だった。

夕食は黒豚島津ですき焼き。うめー。

関係ないけど、行き帰りの電車の中で、ようやくもっとひと目の詰碁を読了。

どこから作ればいいんだろう？　今回は一般の人たち向けではなく、開発者に向けてのお話と言うことで、内容をブログに書いたりしないようにとのこと。

20年前のゲーム作りと近頃のカジュアルゲーム作り。昔はアイデア一発の奇抜なゲームを作っていた。DSで定番ゲーム集を依頼され、5～95歳、誰でも楽しめるゲームを作ることに。ルビを振る。小さい文字が読めない人。俺のばあちゃんはプレイできない。名前入力が出来ない。「決定」の意味が分からない。ペンでなく指で押せるように。設定項目がたくさんありすぎてゲーム画面にたどり着けない。色盲。全てタッチパネルで。STARTボタンでポーズ。六カ国語対応。欧米は子供っぽい色遣いが嫌。通信対戦に関わる様々な問題。奇抜さよりも安心感と使いやすさ。遊べない人を減らす工夫。

AI分野(2)ゲームとAI。コンピュータが将棋を指すしくみ。ボナンザの開発者の話。ミニマックス、支配戦略、ナッシュ均衡、パレート最適、他。本業の研究で頭がいっぱいのところ来ていただいたようです。

プロシージャル技術の動向。フラクタル、L-System、雲の生成、植物の生成、山の生成、都市の生成、等々。最近は自然物の生成は下火で、人工物の生成の方が。

FLASHを使ってゲームUIを構築する。NINJA BLADEというソフトのUI(ライフゲージなどのHUDや各種メニュー画面)をScaleform GFxというSWFファイルを再生してくれるミドルウェアで作っているという体験談。これまでのアーティストが素材を作って、プログラマーが組み込んで、実機で確認して、アーティストが修正して……という繰り返しを、FLASHで作成、PC上のプレイヤーで確認、調整、実機へ組み込みという流れにできたという話。

以下、個人的なメモ。

ゲームというビジネス、ビジネスというゲーム。カプコンの開発統括の人の話。リスクを回避してくれ(続編を8割、後はやりたければ新作を1～2割やってもいい)と言う経営者に「はい、おっしゃるとおりです」などと言いながら、実際には逆にしたんだとか。ビジネスとゲーム(クリエイティビティ)は矛盾する部分があるが、突き詰めていって両立できれば売れるという話。一番悪いところは、経営者は偉そう、クリエイターは甘えてる。相互理解が必要だという話。経営者の気持ちを理解するために、株価を見るようにしたとかなんとか。クリエイターはクリエイティブではない事にも興味を持とうとか。経営から逃げるのではなく、どんな形であれ関わっていくこと。世界市場で勝つためにもっと攻めるべきだとか。http://plusd.itmedia.co.jp/games/articles/0809/10/news088.html

物理エンジンの作り方。剛体の物理シミュレーションについて。拘束なしの場合、拘束ありの場合、安定化/高速化の技法について。拘束なしについては並進運動、回転運動の二つについて計算方法を紹介。拘束ありについては解析法で拘束力を求め、後は拘束がないものと同等に処理する。拘束力は投影型Gauss-Seidel法でLCPとして解く。後は剛体が積み重なったときなどにピョコピョコ動かないよう、安定させるための工夫をいくつか。

モデル検証入門～ツールに振る舞いを検査させる～。機械的にソフトウェアの状態を網羅的に検証するような手法がありますよーという話。

ネットワークゲーム研究の理論と実際。主にMMORPG等の不特定多数間の通信を伴うゲームのネットワークについて。バーチャルリアリティを端に研究が始まった。QoSの失敗。国内、海外の具体的な遅延時間について。ネットワークトポロジ、ピュアなP2P、サーバ集中、マルチキャスト、エンドホストP2P。SCAMPIで行った仮想空間内の距離に応じてネットワークトポロジーを調整する試みについて。Skype4Games。ネットワーク負荷の分析。ユーザーの行動の分析。

衝突判定法をソート・検索アルゴリズムの観点から眺める。BroadフェーズとNearフェーズ。O記法の説明。代表的なソートアルゴリズムの概略。代表的な衝突判定アルゴリズムの概略。ソートアルゴリズムと衝突判定アルゴリズムの類似性。既知の情報をうまく利用することで、n^2のオーダーからn log n、さらにその下へ。Nearフェーズでは物理エンジンで必要となる衝突面の形状、面積を求めることについて少し。

以下、個人的なメモ。

CEDECの10年、これからの10年。CEDECのあゆみ。東京ゲームショー併催の技術戦略説明会が始まり。類似のイベントの紹介(GDC、SIGGRAPH)。最近の動向。世界のゲームコンテンツ市場3兆8千億円。高性能機の普及について、欧米と日本との間で格差。ノウハウの差が心配。今後。各種多様化への対応(プラットフォーム、プレイヤー層、地域)。研究から応用への期間短縮。基礎研究の動向、応用との親和性について。技術の方向性を示す。技術開発情報の発信・交流の場。こんな事ができる、こんな技術がある、というシーズ。こんなものが求められている、こんなものが受けそうというニーズ。両面の情報をゲーム開発者へ提供していく。http://www.excite.co.jp/News/it/20080909/Itmedia_games_20080909051.html

レンダリスト養成講座2.0。環境マップからのソフトシャドウ生成。レンズのぼけを再現。http://www.4gamer.net/games/032/G003263/20080909051/

Squirrelを使ったゲーム開発。スクワール。リス。C/C++言語に近い動的言語。SqPlusというライブラリを使ったC++ - Squirrel間のやりとり。小さな王様と約束の国 ファイナルファンタジー・クリスタルクロニクルでの導入事例。6000行くらいだし、何かあっても自分たちでなんとか出来そうと思った。ワークフロー。プログラマーがC++で必要な機能を実装してSquirrel上から呼び出せるように関数を公開。イベントを作る人はその関数を使ってSquirrelを記述。アドホックな仕様の変更が比較的簡単にできた(敵のパラメータ項目を増やすとか)。プランナーはExcel等で数値データを作って、それをSquirrel上の表記へ変換。ランタイムで発生するエラーに対処するのが大変。ちょっとしたタイプミスや、別な仕事に気をとられて書きかけでアップしてしまうミスもあったらしい。型情報等、ソースを少し見ただけでは分からないものはコメントで補わないと訳が分からなくなる。スレッドが使えるので、裏で戦闘の計算を走らせたりとか。細かいヒープ割り当てが50000個発生して大変だったとか。そのときの対処とか。

ゲーム開発のためのプロシージャル技術の応用。自動生成。プロシージャル技術は大規模化して硬直しそうなゲームに再び命を吹き込むものなのだとかなんとか。SporeとかFar Cry 2とか。グラフィックス、アニメーション、サウンド、AI、レベルデータ等への適用。ユーザーが出来る行動を拡張。

プロシージャルグラフィックス理論と実践。眠かったのでよく覚えていない……ことにしておこう。http://www.watch.impress.co.jp/game/docs/20080909/imagire.htm

cpセーブ方式の欠点は文脈情報の収集処理が頻発してしまう点だ。この欠点を補うため、保存時点収集方式を導入したのだが、こちらの欠点は完全な実装が困難なのと、情報量が多くなりがちなことだ。結局、切り替えて使うことになる。

あー、もう、自動保存むかつくなぁ～。でも無いと突然落ちたときに怖いしなぁ。

いつも行くセブンイレブンで、飲み物やサンドイッチとかをレジへ持って行ったわけですよ。で、鞄を開けるとそこにあるはずの財布が無いわけですよ。もうね、どうしようかと。