ゴミ箱.net

汚物は消毒

POIでシートの並べ替え→削除をすると内部データが壊れる件

JavaでExcelのデータを触れる便利なライブラリApache POI。色々なところで使われていてかなりメジャーなライブラリのはず。

そのPOIのけっこうきついバグを、ついこの間見つけてしまったようだ…

続きを読む

スポンサーサイト

PageTop

ゲーム製作日記4 衝突判定

道具立ても揃ったことだし、そろそろ実装に入るとするか。
はじめにゲーム作りの基礎ともいえる衝突判定の実装をすることにする。

ゲームが実世界の挙動をそれなりに再現してくれるのは大部分が衝突判定のおかげといっても過言ではない。
地面とプレイヤーキャラが衝突するから、プレイヤーは地面や足場をすり抜けずに立っていられたり、壁をすり抜けるなどの非現実的な挙動をしなくてすんだりする。
格闘ゲームで敵を攻撃したり敵から攻撃を食らったりするのも、自分がダメージを食らう領域と相手が攻撃を仕掛ける領域が衝突するからである。
さらには3次元空間で物体が物に隠れて見えなくなるのも、視線と物体の衝突を判定できてこそだ。

今回は昔ながらの2次元グラフィックスを使うので、2次元空間での領域どうしの衝突判定を考えよう。

続きを読む

PageTop

ゲーム製作日記3 ライブラリの選定

1からゲームを作るとなると、いろいろと面倒が多い。
たとえば画像、音楽、オブジェクトの管理といったことを全部こなさなければならない。
さすがにそれはしんどいので、一部の処理は既存のライブラリを使って楽をすることにする。

○○ツクールみたいな大掛かりなフレームワークは使わない。使えばとても楽なんだろうが、今回は汎用的なゲーム製作のノウハウを身に着ける・ゲームに最適なプログラムの論理構造を研究するという目的もあるので、基本は自力で作成することにする。

今回はとりあえずDXライブラリを使う。
比較的低レベルなインターフェースであり、またあまり面白みのないわりに作るのが面倒な画像や音声の処理がひととおり揃っていて大変都合がいい。しかもC#でも使えるし。
そして、低レベルの処理はDXライブラリに任せ、オブジェクト管理や入力処理といった高レベルな処理を自作することにする。
DXライブラリはどう見てもゲーム作成用に最適化されたライブラリであるが、その提供する機能は画像処理、音声処理といった基本的なものばかりである。それだけゲームの構造というのは一般化しにくいということなのかもしれない。

ここでひとつ問題になるのが、DXライブラリにべったりな処理を書いてしまったら再利用性がぐんと減ってしまうのではないか?ということ。将来的にもっといいライブラリに乗り換えてもある程度コードを使い回せるようにしたい。
そのために、プログラムを特定のライブラリに依存しない部分と、DXライブラリに依存する部分に分けて、できるだけ前者の中で処理を作りこむようにする。
たとえば当たり判定の処理などはただの数値演算なのでライブラリ非依存の部分に落としこめるだろう。しかし、画像の表示はもろにライブラリ依存になってしまう。その場合、画像を表すクラスとしてライブラリに非依存な抽象クラス(またはインターフェース)を作り、それを継承してDXライブラリ依存の処理を作りこんだ具象クラスを作るようにすればいいだろう。

PageTop

ゲーム製作日記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