ゴミ箱.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

ゲーム製作日記1 くっ...鎮まれ...俺のゲーム製作熱...

ゲーム製作というのはプログラミングの中でも最高峰に難しいものだと思っている。
というのは、いったん起動したら順番に処理をすればいいバッチ処理や、基本的にイベントを待ち受けて処理をすれば済むGUIアプリとは違い、リアルタイム制御やら並列処理やらが絡んでくるから。
しかもいろいろな種類のイベントが発生するので定型処理が作りにくい。
画像処理や音声処理といった要素技術は別にしても、プログラム構造自体がかなりややこしいのだ。ゲームプログラムをきれいに作ることができれば開発者として上位1パーセントには入れるだろうな。

開発者としての集大成として、いずれきちんとゲームを1本作りたいという気持ちはあるんだ。
以前にそれっぽいものを作ってみたりしたことはあるが、なんか中途半端な仕上がりになってしまった。
その後も作りかけては放置したりでご無沙汰。だって面倒だもん。

しかし…最近某スレ何やらローグライクを作ってる人を見かけて、ゲーム作りたい病が再発してしまった。
昔よりはプログラミングの知識が増えたし、今はいろいろと手抜き便利なライブラリもそろっている。なので、昔作ったやつよりはよいものが出来るだろう。そう思いたいところだ。

PageTop