ゲームプログラミング

HEXのマインスイーパを作ってみた

凪瀬 — Wed, 11 Jun 2008 09:22:00 GMT

ふと触発されてマインスイーパっぽいものを作ってみた(スター●ーカーとも言う)。後悔はしていない。

JavaWebStartでの起動はこちらから(約1.7MByte)。

ご褒美グラフィックはりょーいちさんとこからシュウたんの画像を借りてきました。事後報告でごめんなさい。

HEXなリバーシを作ったよ

凪瀬 — Sun, 25 May 2008 02:34:00 GMT

リバーシゲームＡＩ続報でネタに上がっていたHEX(ヘックス。六角形による盤面のこと)でのリバーシ。

ちょうど手元に自作のHEX用フレームワークがあったので、リバーシを乗せてみました。 AIは一番多く取れるところに置くだけのお馬鹿さんです。

JavaWebStartでのデモはこちら。

タスクシステムにコルーチンを組み込むには

凪瀬 — Wed, 12 Mar 2008 23:31:00 GMT

型を継承する以上はis-aであるべきではコルーチンを使おうが何だろうが、java.lang.Iterable(C#ならSystem.Collections.Generic.IEnumerator)であるからにはその型としての機能性を全うすべきだと主張しました。

では、本題のタスクシステムでコルーチンを扱うケースでどのように設計するべきかを考えてみましょう。

そもそもタスクシステムって？

ゲームにオブジェクト指向の考えを部分的に取り入れたのがタスクシステムと言えるでしょう。タスクシステムでやっていることは、

キャラクタを表現する構造体を作る
その構造体には関数ポインタによって挙動の違いを表現できる機能性を持たせる
構造体は双方向リストなどの構造で複数のデータを管理できるようにする

といったところです。これは、非オブジェクト指向であるC言語では「システム」と称するだけのものかもしれませんが、 JavaやC#といったオブジェクト指向を前提としたモダンな言語ではごく日常的な表現にすぎません。

キャラクタを表現するのは抽象クラスかinterfaceを用います。
関数ポインタによる挙動の違いは、抽象クラスもしくはinterfaceの実装クラスのポリモフィズムによって行うことができますから、わざわざ関数ポインタなどを用いる必要はありません。
双方向リストにするためにクラスに前後へのポインタを持たせることもできますが、現在のプログラミング言語であれば外部のコレクションAPIを用いる方が自然でしょう。

このように、C言語で作られるタスクシステムがオブジェクト指向言語と極めて相性が良いのは、タスクシステム自体がオブジェクト指向の考え方を取り入れたシステムだからに他なりません。

C#で大雑把なイメージを表現すると、

// ゲーム中のキャラクタを表現するインターフェース interface GameCharacter { // 1フレーム分の処理を行う public GameCharacterStatus update(); // キャラクタの描画 public void draw(); } class TaskSystem { private List<GameCharacter> list; public void GameMainLoop() { while (true) { foreach(GameCharacter gchar in list) { GameCharacterStatus status = gchar.update; // ... // キャラクタのステータスによって削除などを行う // 描画処理 gchar.draw(); } } } }

この例では、敵が倒されて除去されるような部分はタスクシステム側の責務としています。そのため、キャラクタが返すステータスを見て、倒されたなどの状態をみてタスクシステムのListから除去するように実装する必要があります。

キャラクタの制御にコルーチンを用いたい場合は？

このサンプルでは、1フレームの処理を行うためにupdate()というメソッドを用いました。この内部がどのような実装になっていようともタスクシステム側は関知しません。ただ、1フレーム分の処理さえしてくれればいいのです。ここがオブジェクト指向的な抽象ですね。

C#のコルーチンはIEnumeratorで表現されます。「繰り返し値を返すもの」として扱われるわけですね。状態を表すオブジェクト(ここではGameCharacterStatus)を返すコルーチンを用意した場合、

class HogeCharacter : GameCharacter { // コルーチンを保持するメンバ private IEnumerator<GameCharacterStatus> coroutine; public HogeCharacter() { // コルーチンの初期化 this.coroutine = this.getCoroutine(); } // 1フレームを処理して状態を返す public override GameCharacterStatus update() { this.coroutine.MoveNext(); return this.coroutine.Current; } // コルーチンの実装 private IEnumerator<GameCharacterStatus> getCoroutine() { GameCharacterStatus status = new GameCharacterStatus(); // ... yield return sutatus; // ... yield return sutatus; // ... } }

といった感じになると思います。このように、コルーチンの実体と外界との接点をyield returnの値のみにすることでスパゲッティコード化することを防いでいるわけです。

こういった工夫は小さい規模のプログラムではメリットを感じにくいところですが、大規模化するほど効果を発揮します。

状態を表すオブジェクトなんて作ってられないというのであれば

もし、こうしたように状態を表すオブジェクトを返すという作りにしにくい場合はどうでしょうか？
状態を表すクラスを宣言するよりも複数の値を返したい場合など、メンバ関数を用いてやり取りする方が楽な場合もあります。私は二つの値を返したければ、それを保持するクラスを作ることを厭わない人間ですが、いろいろな人のソースを見ていると、クラスや構造体をわざわざ宣言するということがためらわれるという意見も多いようです。

C#ではジェネリクス型パラメータとしてVoidを設定することはできないようなので値を返さないIEnumeratorにする場合はダミーの値を返すようにする必要がありますね。
こういったケースでは C#のyieldに対する誤解と私の見解で主張されているように「コルーチンとしてのyieldは無意味な値を返すべき」というのは当たっていると思います。
ただし、それはC#のジェネリクス型がVoidを表現できないことからくる実装上の工夫という泥臭い理由によることも忘れてはなりません。

ともあれ、そのような場合はメンバ変数などを用いて状態をやりとりすることになると思いますが、そのような実装の話は、あくまでGameCharacterというインターフェースの実装の中に隠蔽される事項です。これはオブジェクト指向で言われるカプセル化の概念ですね。

class PiyoCharacter : GameCharacter { // コルーチンを保持するメンバ private IEnumerator<GameCharacterStatus> coroutine; public PiyoCharacter() { // コルーチンの初期化 this.coroutine = this.getCoroutine(); } // 1フレームを処理して状態を返す public override GameCharacterStatus update() { this.coroutine.MoveNext(); // メンバ変数を通してstatusオブジェクトを構築する GameCharacterStatus status = new GameCharacterStatus(); // ... return staus; } // コルーチンの実装 private IEnumerator<int> getCoroutine() { // ... yield return 0; // ... yield return 0; // ... } }

このような場合、PiyoCharacterクラス内部とコルーチン部分とではメンバ変数によるデータのやり取りが行われます。カプセル化という観点ではあまり望ましくない状態ですが、このPiyoCharacterクラスの内部だけの話として隠蔽してしまうことでスパゲッティコード化することを防いでいます。

いずれにせよ、外側(ここではTaskSystemクラス)から見た場合は、 GameCharacterインターフェースに対するポリモフィズムであり、内部の諸事情は一切考慮する必要がありません。

この考慮する必要がないという部分がオブジェクト指向で言われる隠蔽であり、また再利用を高めるための抽象化でもあるのです。

ゲームのバグにみるアルゴリズム - バッファオーバーフロー

凪瀬 — Tue, 09 Oct 2007 20:28:00 GMT

Programming SHOT BARへようこそ。
ゲームのバグシリーズはひそかな人気シリーズです。ぼちぼち検索エンジンから飛んでくる方がいらっしゃいますね。今回はダンジョンズ＆ドラゴンズシャドーオーバー・ザ・ミスタラ(1996年カプコン。略称で以下D&D2)です。

ジャーレッドのアイテム増殖バグ

このD&D2ではゲーム開始してしばらく進むとプレイヤーの名前を入力する画面があります。名前入力は最大6文字で、入力した名前によってA～Jの10タイプに振り分けられ、ステータスや初期装備アイテムが変化するというシステムになっています。プレイヤーの選択したキャラクタの職業別にデフォルトの名前があるのですが、 2プレイヤー側の戦士の「ジャーレッド」という名前のみ6文字のデフォルト名となっており、この名前を使った際にはバッファオーバーフローが発生します。

つまり、文字入力の際に6文字目だったらカーソル位置を変更しないことで、 7文字目以降の入力が行われないように制約しているのですが、デフォルトネームを選択した場合に漏れがあり、「ジャーレッド」を選択した時点で「決定」せずに続けて入力するとカーソル位置が7文字目に移動してしまい、名前のメモリの後ろの部分にデータ入力することが出来てしまうのです。

このバグにより、所有アイテムや装備品などのステータスを自由にいじることが出来ます。といっても、メモリに直接値を書き込むのですから、メモリ構造が把握できていないと思ったように装備品やアイテムを変更することは出来ませんが…。

なお、不用意にメモリを書き換えるとゲームがフリーズしてしまいます。ゲームバランスを激しく損ないますし、迷惑ですからお店では試さないでくださいね。

ゲームのバグにみるアルゴリズム - GameOver

凪瀬 — Wed, 12 Sep 2007 20:51:00 GMT

何を見てもアルゴリズムを考えてしまうのがプログラマの職業病第二段。
前回はナイトレイドという、非常にマイナーな作品だったのですが、今回はメジャーなタイトルを取り上げてみたいと思います。

バトルガレッガの臨死

メジャーといいつつも世間的には非常にマイナーで申し訳ありません。
90年代後半の弾幕シューティングの幕開けは怒首領蜂(どどんぱち 1997年 cave)とされることが多いですが、 BATTLE GAREGGA(バトルガレッガ 1996年 RAIZING)の2面ボスを見てcaveの開発者が「そこまでやってもいいんだ」と弾幕をコンセプトにした怒首領蜂を作ったという逸話があり、このバトルガレッガを弾幕シューティングの始祖とする意見も多いです。

シューティングゲームのスコアラー(スコアアタックをする人々)界隈では非常に有名なこのゲーム、いくつかバグがあるのですが、初めてみたときに何が起こったのか理解できないのが「臨死」と呼ばれる現象でしょう。

本当は実物を見てもらいたいところなのですが、YouTubeで手ごろな動画が見つかりませんでした…。
現象としては残機のない状態で、ミスをしながら1UPするとGameOver時にばらまくアイテムをばら撒いて死んだはずなのに何事もなかったようにプレイ続行できる、という現象です。

バトルガレッガというゲームでは100万点ごとに1UPする上、スコアを稼ぐのにボムを大量に使用するので、ゲームオーバー時に出るボムアイテムを回収しながらGameOverにならずにプレイ続行できるこの現象は、スコアアタックでは非常に有利なのです。私も当時はこの「臨死」の練習をしたものです。

その原理

前提条件が幾つかあります。

パワーアップなどがアイテム制で、ミスした際にはパワーアップアイテムなどをばら撒くタイプのゲームであること。
ミスした際にその場で復活するタイプのゲームであること(グラディウスシリーズのような戻るタイプでは不可能)
ミス中に1UPすることが可能であること

最後の１機をミスをした瞬間にGameOverと表示させるのであれば面倒はないのですが、ミスをした後にアイテムがばら撒かれ、自機が爆煙を上げて落ちるといった演出がされます。
そのため、ミス時のアイテムの種類の判定はミスの瞬間に行い(GameOver時には多くのアイテムをばら撒く)、 GameOver判定は次の自機が登場するタイミングで行うというアルゴリズムが用いられます。

そのため、アイテム判定時にはGameOverと判断され、コンティニュー用に多くのアイテムをばら撒き、 GameOverが確定するまでの間に1UPすることでGameOverとならずに復活することができるのです。

開発もとのRAIZINGのアームドポリスバトライダー(1998年)では1UPをアイテム方式にしてこの「臨死」が行えないようにしています。臨死を行えるゲームはそれなりに多くあるようですが、あまりにシビアであったり、また、臨死をするメリットがないので単なる大道芸となったりといった具合です。

ゲームのようなリアルタイム性の強いプログラムでは、この現象のように思わぬタイミングで処理が発生すると奇異な現象が起こることがあります。プログラムする際にはこういった「間」にも注意を払いましょう。

ゲームのバグにみるアルゴリズム - 衝突判定

凪瀬 — Sun, 05 Aug 2007 18:28:00 GMT

何を見てもアルゴリズムを考えてしまうのがプログラマの職業病といったところです。
私は結構ゲーム好きなんですが、ついついアルゴリズムを考えてしまうんですね。バグを発見したときなどは楽しくてたまりません。そのほつれからプログラムのコードが透けて見えるのです。

本日のターゲットは2001年、匠から発売されたアーケードゲーム「ナイトレイド」です。ジャンルはシューティングなのですが、変なシステムを採用した、あまり見栄えのしないゲームでした。このゲーム、非常にマイナーです。多分、名前を聞いて分かる人の方が少数派ですね。ちなみにプレイステーションに移植されています。
アーケード版公式ページ
 PS版公式ページ

このゲームには非常に致命的なバグがあり一部界隈では有名です。
自機を画面左上に移動させると敵が弾を撃たなくなるのです！
なぜこんなことが起こるのでしょうか？

矩形の衝突判定

ところで矩形(ようするに四角形のこと。プログラム用語。「くけい」と読む)同士の衝突判定はどうやるか分かりますか？

図のようにA,Bふたつの矩形があるとします。 Aの左上角の座標から見て右下にBの右下角があり(図の黒矢印)、 Aの右下角の座標から見て左上にBの左上角がある(図の赤矢印)場合にふたつの矩形は重なっているのです。


// 矩形Aの座標

// (ax1, ay1)───────────┐

//      └───────────(ax2, ay2)

// 矩形Bの座標

// (bx1, by1)───────────┐

//      └───────────(bx2, by2)

if (((ax1 < bx2) && (ay1 < by2))

    && ((ax2 > bx1) && (ay2 > by1))){

  // 衝突！

}

シューティングゲームでは敵に近くから弾を撃たれて即死しないように配慮して、敵が自機に近い場合は弾を撃たないようにしているものがあります(ゲーマー用語で弾封じといいます)。

このナイトレイドでは自機と敵が重なってもミスとはならない仕様なのですが、重なった状態から弾を撃たれると理不尽だろうという配慮でしょうか、この弾封じの判定が実装されているわけです。

そして、あろうことか、弾封じのための矩形の衝突判定で条件式の"<"と">"を間違えるというコーディングミスをしてしまったのです！


// 矩形Aの座標

// (ax1, ay1)───────────┐

//      └───────────(ax2, ay2)

// 矩形Bの座標

// (bx1, by1)───────────┐

//      └───────────(bx2, by2)

if (((ax1 < bx2) && (ay1 < by2))

    && ((ax2 < bx1) && (ay2 < by1))){

  // 衝突？

}

そして、誰もこのことに気づかないままゲームは出荷されたのでした。境界値テストは重要ですね。