まとめ
メニューを開く-
数日前Popcapの人と呑んだらなんか昔僕がやってたのと同じような仕事をやっているらしい。カジュアルゲームには無縁の泥臭い技術とシステムかなと思っていたがやはり大所帯になると巨大なフレームワークを作ったりするみたいだ。 -
そのときに昔書いたReflectionの話をしたらこっちが引くぐらいすんげー食いついて来たので意外と今でも賞味期限切れじゃない話題なのかな、と思い始めた。
-
ゲーム開発でもC++なんかもうみんなそろそろ捨てるんじゃないの？そうでなくてもコンパイラといかにバトル(強敵と書いて「とも」と読む系の)するかみたいな話はいい加減もういいだろと思っていたが興味がある人が多いならMITライセンスで一から書いてみようかな。やり残した最適化もあるし。
-
と思いつつも自分でもコレいい加減話題にするの飽きてるんだよなぁどうしようかなぁ、と葛藤する。自分的には今から作って出しても高橋名人の冒険島４みたいな立ち位置になることが自明だろと思ってるし・・
-
あとHoard＋自前ページ管理で、マルチスレッド対応＆動的サイズ変更可能なヒープ＋ログベースのメモリデバッガというのも自分のプログラマとしての課題としては積み残しになっている。
-
コンパイラとバトルなんて何年やってないかなぁ。最適化で手間かけるぐらいならアルゴリズムとか設計で改善したほうが速いし安定するしなぁ……。 -
ヒープの話はシステム的にはEmery先生の論文マルパクなんで自分のだって言うつもり毛頭ないけどGPLは使いづらいからMITライセンスとかzlibライセンスとかで在野に存在するとみんな幸せになれるかな。
-
そういえばgccがllvmをサポートし始めたらしいが、llvmの使い方についても面白い話を聞いた。
-
C++の何が問題だって、クラスの依存関係や最適化の見地からいろんなものがヘッダに入る→コンパイル遅い→毎回全部ビルド完了状態にして全部リンクしないと動かない→リンク遅い（あるいはリンク時最適化遅い）→バイナリをリロードして実機をリスタートしないといけない→最初からテスト、という
-
実行機材がインオーダーCPUだったりタイムクリティカルなシステムだったりリモートデバッグが基本だったりするのが一般的なゲーム開発という分野には、成果としてのバイナリ自体のクオリティは兎も角運用面がすこぶる向いてない言語＝C++
-
そんなC++の運用面で特にイケテナイT&Eのサイクルの遅さを解消するべくC++→ビルド→llvmで止める→実機で実行→実行時にJITコンパイルしつつ実行→モジュール単位でリロードとかC++のくせに出来ちゃうんだぜ的なドリームプロジェクトがあるらしい
-
また、そこまで行くとC/C++を別の次元で使える。llvmになるなら呼出規約だけ別の言語と揃えられるようにコンパイラキーワードを追加したりすれば、C#で書いてもJavaScriptで書いてもいいってことになる。C#->C関数の実行のコストが実質C->Cの時と同じになるシステムを構
-
そして徐々に世界はJavaScriptで埋まっていく
-
なぜならCプログラマが受け入れてくれる文法の言語の中で圧倒的にプロダクティビティが高いから！キリッ
-
勿論、異なる言語の呼び出しの時にはManaged Objectをどう扱うかという重要な問題がある。別の言語のオブジェクトを別の言語で破壊したり生成したりということを禁止すれば、あとはアクセサの問題だけになるのでシンタックスシュガーでも付けてコンパイラがハンドリングすればよろしい問
-
Monoはこの辺面白くて、底辺のガベージコレクタがC実装なので全てのメモリはfree()に通ずる。だから低レベルな言語では全てのリソースはmalloc()して返せばよろしい。
-
結果としてMonoのネイティブコードプラグインはmallocしたメモリをそのまま返したりする。うわぁコレ大丈夫なのかなと言いつつ
-
CEDEC/IGDAなどで Squirrelや Luaの組込スクリプトを利用した動的な状態操作を覚えた私にとって、次にあったのは C++など native codeでの動的状態操作でした。Protocol Buffersとかyamlで保存・更新・回復。
-
あー、やっぱり拡散していくんだな・・・（遠い目）
-
Content from Twitter
コメント