ゴミ箱.net

汚物は消毒

ゲーム製作日記2 言語の選定

さてゲームを作るにしても、何の言語を使おうか。

今回言語の選択にあたって重視したのが、マイクロスレッドを記述する仕組みの有無。
フレームごとに刻々と状況が変化するゲームだと、フレームごとに少しずつ処理を呼び出さなければいけない。キャラクター1体動かすにしても、フレームが変わるごとに「キャラクターの座標を変更して画面に描画する処理」を毎回呼び出すことになる。
その性質上、その処理を普通の関数みたいに連続した形で書くことはできない。それをやろうと思うと、関数の中に処理を中断したり中断を再開したりするポイントを設けないといけなくなる。マルチスレッドだとできなくはないが、スレッド切り替えはコストが高いのでキャラクターの数が増えていったら処理しきれなくなるだろう。
こういう場面でマイクロスレッドを使うことで、フレーム単位でぶつ切りになる処理を普通の関数のように書くことができるようになり、開発の付加がかなり変わってくると予想される。

マイクロスレッドを言語レベルでサポートしている言語はいくつかあるが、どういうわけかことごとくインタプリタ系の言語だったりする。RubyとかLuaとか。でもインタプリタってなんか遅そうだったり、実行するマシンに実行環境が必要だったり、型制約が緩すぎてバグのすくつになりそうだったりで嫌だ。
その中で、おそらく唯一のコンパイラ系言語がC#。仮想マシンとはいえきちんと機械語にコンパイルされるし、.NET FrameworkだったらWindowsに標準搭載されてるだろうし。それに何より自分がC#に慣れている。
というわけで、言語としてC#を使うことにした。

C#でマイクロスレッドを実現するには、yield returnというものを使ってイテレータ(Enumerator)を作る。
これによって、あたかもメソッドの実行を中断したり、中断したメソッドを再開したりしているかのような感覚で処理を記述することが出来るようになる。
イテレータを次の要素に進めるとメソッドが実行されるが、その処理はyield returnのところで中断される。もう一度イテレータを次の要素に進めると、中断したところからメソッドが再開されてその次のyield returnまで実行される。

内部的にはメソッドがyield returnのところでぶつ切りにされ、隠された状態変数によってぶつ切りになった処理のどれを実行するか分岐するようなコードに変換されるらしい。M$はこれを実現するためだけにコンパイラにかなり手を加えたとか。詳細はC# in Depth: Iterator block implementation detailsを見れば分かる。
この仕組みだとスレッドのようにコンテキストの切り替えを伴わないのが明らかなので、使う側としては気が楽だ。

言語を決めたら次はライブラリだな。
スポンサーサイト

PageTop

コメント


管理者にだけ表示を許可する