ゲーム開発

XNAさえ出来れば

myugaru (myugaru@wankuma.com) — Wed, 26 Mar 2008 13:31:00 GMT

そうなんです！XNAがうちのPCで動けば、そもそもこんなに悩むこともなかったんです。

いやひょっとしたらわんくま同盟に加盟もしてなかったかもしれません（＾＾；；；

12月くらいにDirectXやってて1月にふいにXNAを発見したのです。

1月4日

http://d.hatena.ne.jp/myugaru/20080104

「今日から少しずつXNAについて勉強して行こうと考えている。・・・」

でも

http://d.hatena.ne.jp/myugaru/20080106

「どうもノートPCではこのXNAが簡単には動作しないのだ。」

となりまして

http://d.hatena.ne.jp/myugaru/20080111

「結論：5年越しのノートPCじゃ無理」

なのであります。

先日NyaRuRuさんとコメントで話をさせていただいたときに判明したのですが

http://blogs.wankuma.com/myugaru/archive/2008/03/16/127910.aspx

以下わたしのコメントより

「P.S.先に書いたとおりIntel82852の問題は私は自分でDirectXで今もテストプログラムを書いていますがずっと発生してました。リファレンスモードなどに変えたら発生しないというのも気付いていました。友人にプログラムを試してもらうと私のノートより輪郭が鮮明だというのも気付いていました。もとをただせばうちでXNAが動かないというのも含め全部チップのせいだろうと認識していました。また改めてこの件についての奮闘記は書かせてもらいたいと思っています。」

たぶん5年前のPCにはドライバー的にあんまり高級（高度？）な処理をできるような仕組みが備わって無いようです。あるいは備わってるんだけど既にサポート外になっててドライバーが更新されて無いのかどっちかのようなのです。

・・・ということで私にはXNAは現在無理なのであります(T-T)

DirectXは無理でした

myugaru (myugaru@wankuma.com) — Wed, 26 Mar 2008 12:32:00 GMT

ブログをはじめるにあたって、

DirectXとゲームと画像処理の３つを柱に勉強とかしようと思っていた。

でも、

●ギブアップから始まる物語

実はDirectXのお勉強を早くもギブアップいたしました；；

せっかくNyaRuRuさんともお近づきになれた（と勝手に思ってますが）のに自分が情けないですが・・・。

myugaruの最終ステータス：

Direct3D：2DTextureを2Dスプライトに貼り付けて描画できる。背景をSuefaceに読み込んで表示できる。ビューポートを使って描画範囲を制御できる。

DirectSound：Waveが読み込める。同時に複数鳴らせる。

DirectInput：キーボード入力とジョイスティック入力を判定できる。

たぶん、これらを組み合わせたらゲームは作れるんだと思う。

でも例えば「背景に流星群」とか言われると詰まる。

ドットを表示する方法が私のステータスでは厳しい。

私のステータスで考えられる手段はSurfaceにColorFillとかいう矩形塗りつぶしメソッド。

試しに１×１の矩形塗りつぶしで流星群を表現してみた・・・

GDI+のドットルーチンより遅いOTL

まず思ったのは、きっとたぶんバックバッファをメモリに取っておいていきなりbyte配列アクセスで色を設定してフロントバッファと交換する、みたいなのが出来るんでしょう。

●しかし、もうギブアップです

前にも何回も書いてますがGoogle先生に聞けば何とかなるんです。確かに。

でもモチベーションがだんたん持たなくなってきました。

こんなところで詰まってたら本当の目的に進めません。

●禁断の箱を開く

１２月くらいからDirectXで結構がんばったよ。自分。

・・・もういいよね。

そして、知ってたけど敢えて見ないようにしていた禁断の箱を開けます。

http://gamdev.org/

ここに紹介されているライブラリ群に答えがあります。

たとえば

Luna http://luna.sumomo.ne.jp/

とか結構気楽に使えます。

気楽と言えば、やねうらおさんの偉大なライブラリの方がずっと安心して身を委ねられそう。

YaneuraoGameSDK.NET http://yanesdkdotnet.sourceforge.jp/

IDEの開発するのが目的だからマルチプラットフォーム付きライブラリだとちょっと重いかな・・・。

ゲームが作りたいだけならもっともっと簡単な逃げ道もありますよん。

・HSP＋hspdx.dll

とか。さすがにここまで逃げるのだけは踏ん張りたいところ。（もはやC#でも.NETでもなくなってるし＾＾；；；）

●今後の作業手順

・・・などと。うだうだ想像してても始まりません。

まず、ほとんどがC++向けなんよねー。なので、

１．とりあえず片っ端から簡単なC++アプリを作ってみる。

２．それをC#移植してみる。

３．手間と時間の計測

うん。ちょっとだけ楽しくなってきた（笑

（ブログのサブタイトル変えなきゃ・・・何にしよう；；）

私が作ろうとしてるのって

myugaru (myugaru@wankuma.com) — Wed, 12 Mar 2008 08:37:00 GMT

最近何となく分かってきたのですが、

私は某A●CIIから昔発売されていた幻のツクールシリーズ

「シューティングツクール」（※シューティングツクール - Wikipedia）

を作ろうとしているような気がしてきました。

これはすごいですよ。ある種の３階層アプリです。

●描画エンジン・・・今はDirectX。それもいまだとManaged DirectXのSpriteしか使えません。３Dになったらお手上げです。そのうちXNAにするかもですがそっちも全然知りません。既に私は時代遅れ人間です・・・。

●ライブラリ・・・今のところGUI無し。とりあえずGUI無しで何か作品作ったらだんだんGUIが出来てくる気がする。（作るのは私ですが）

●ビジネスロジック・・・いわゆるこれがゲームデザイン部分ですが。私ははっきりいってその方面の才能とかありません。絵も音楽もできません。なのでここは誰か有志を募ろうかなとか思っています。

ってことでやっぱり私の居場所はライブラリしかなさそう。

身の振り方はとりあえずライブラリが出来たら考えよう（笑

＃ひょっとしたらライブラリも、やねうらおさんの偉大なライブラリに置き換えができるかも知れない。

＃ってことは私の居場所はビジネスロジックを組み立てるIDE（GUI）デザインだけになるのか？

あれこんなのがあったのかあ。私は世間のことを何も知らない人です。

シューティングツクールXPを待ち続けるスレ Part5

じゃあ目標はここで晒されるってのがいいですかね？ｗ

コルーチンのyieldはDoEventsです

myugaru (myugaru@wankuma.com) — Tue, 11 Mar 2008 14:35:00 GMT

前エントリー：http://blogs.wankuma.com/myugaru/archive/2008/03/10/127092.aspx

siokoshouさんのコメントを拝見しまして私の説明力・説得力の無さを痛感しました。
ちょっと悔しいので今日は別の切り口で説明のリベンジをしたいと思います。

（また失敗に終わる予感もしますが・・・）

話はWindowsプログラミングです。

ボタン１をクリックすると画面の中央に
「ボタン１が押されました」
という文字が0.5秒間隔で点滅し、
ボタン２を押すとそれが消える

と仮定してください。

以下のようにプログラムを作ったとします。

ボタン１クリック()
{
　while (ボタン２フラグ == OFF) {
　　while (0.5秒間)
　　　「ボタン１が押されました」表示
　　while (0.5秒間)
　　　//何もしない
　}
}
　
ボタン２クリック()
{
　ボタン２フラグ = ON
}

一見仕様は満たされています。しかし上のプログラムは上手く動作しません。
ボタン１をクリックしてしまうと画面が真っ白になってしまうことでしょう。
誰でも一度くらいは経験があるフリーズという状態です。
タスクの切替が考慮されていないために起こる現象です。

改良したボタン１クリックが次のプログラムです。

ボタン１クリック()
{
　while (ボタン２フラグ == OFF) {
　　while (0.5秒間) {
　　　「ボタン１が押されました」表示
　　　DoEvents();
　　}
　　while (0.5秒間) {
　　　DoEvents();
　　}
　}
}

DoEventsはここではWindowsへ制御を渡す役割をする関数と思ってください。
・・・長く説明すると馬鹿にしてるとお叱りを受けますからここでやめます（苦笑

コルーチンで同じことを考えましょう。
ボタン１クリックは次のように書けます。

ボタン１クリック()
{
　while (ボタン２フラグ == OFF) {
　　while (0.5秒間) {
　　　「ボタン１が押されました」表示
　　　yield return 適当;
　　}
　　while (0.5秒間) {
　　　yield return 適当;
　　}
　}
}

コルーチンのyieldは状態をレジュームしメインループに制御を戻します。
次回の呼び出し時はyieldの次から再開されます。
DoEventsと全く同じですね。ここは大丈夫ですよね？

さてまたWindowsへ戻ります。
このボタン１クリックを呼び出しているのはWindowsならばWinProcに当ります。
そこにメインループが書かれています。

WinProc()
{
　while (true) {
　　switch (イベント) {
　　　case ボタン１:
　　　　ボタン１クリック();
　　　　break;
　　　case ボタン２：
　　　　ボタン２クリック();
　　　　break;
　　}
　}
}

上のコードには実は隠された処理が多く存在しています。
たとえばDoEventでの処理中断再開の機構が見えません。
しかしここで全て書くにはあまりに膨大です。
それにWindowsも一般的になってきたので省略します。

余談ですが。昔々~~Windows98がまだ健在だった時代。~~今も健在だとお叱り受けますね＾＾；；
自分の会社が初めて業務でWindowsを扱うことになった頃に上のような処理で、
「ボタン１の処理中にどうしてボタン２へ飛んでいけるのか」
を何日も何日も何日もかけて上司に説明した事を思い出しています（笑

話を戻します。私が実装を予定しているゲームメインはこうなります。
WinProcでは隠されていたと説明した部分もここでは露見します。

GameLoop()
{
　IEnumerator ボタン１タスク = ボタン１クリック();
　IEnumerator ボタン２タスク = ボタン２クリック();
　List タスクリスト
　タスクリスト.Add(ボタン１タスク)
　タスクリスト.Add(ボタン２タスク)
　while (true) {
　　　foreach (タスク in タスクリスト)（★１）
　　　　if (!タスク.MoveNext()) {
　　　　　//終了したタスクを除外
　　　　　タスクリスト.Remove(タスク)
　　　　}
　　}
　}
}

★１：（15:40追記）実際には私の独自実装をほどこしたLinkedListを用います。

説明の本質から外れるので便宜上foreachを用いましたが現実のC#言語のforeachはノードを削除することはできません。

削除を考慮した独自のLinkedList拡張→http://blogs.wankuma.com/myugaru/archive/2008/03/06/126581.aspx

Windowsでの実装とコルーチンでの実装をご覧いただきました。
両者は

「処理を一旦中断し別タスクへ処理のチャンスを渡す」

という全く同じ基本思想で成り立っています。

●では再度お尋ねします。コルーチンのyieldは何を返すのでしょうか？

コルーチンのyieldが返す値についてもう一度だけ考えてみてほしいと思います。
列挙のyieldではありません。コルーチンのyieldです。

WindowsのDoEventsととらえてこれを再考するといかがでしょうか？
例題を見てもらうと両者の位置付けは全く同一です。
果たしてDoEventsは何を返すべきでしょう？ボタン１クリックの返値ではありませんよ。
yield returnがCurrentを返すと考えると上記でのDoEventsにとってのCurrentに該当するものは一体なんなのでしょうか？
ボタン１の所属する・・この場合はFormになるのでしょうか？
そうでなければ何であれば適当ですか？

またコルーチンを列挙とどうしてもとらえたいという方にはボタン１クリック()というハンドラーを列挙と捕らえることにどういう意味があるかを再考いただければと思います。

前エントリーから私の意見は「コルーチンのyieldの返値は無意味であり不要である」です。
DoEventsだって返値は現実にありませんものね。

お時間ありましたら再度皆さんのご感想などいただけたらうれしく思います。

ここまで読んでお付き合いくださった方に感謝いたします。ありがとうございます。

C#のyieldに対する誤解と私の見解

myugaru (myugaru@wankuma.com) — Mon, 10 Mar 2008 20:26:00 GMT

コルーチンの話を進める上でどうしてもC#のyieldを理解してもらわなくてはいけません。

凪瀬さんも少し誤解されているように感じました。

ここで少し解説したいと思います。

●実は何も返してないyield return
ご存じなければ驚くかもしれませんがyield returnは正確には何も返していません。
まずMoveNextの返値ではありません。
MoveNextの返値はMoveNextの成功可否をboolで返します。
つまり列挙が継続可能かを返します。
ではyield returnは何を返しているかというと、
IEnumeratorインターフェースのCurrentプロパティの内容を更新しています。
言語構文上returnという単語を用いているだけなのです。
なので「何か返している」という誤解が生じているように思います。

using System;
using System.Collections;
namespace CoRoutine
{
    static class Program
    {
        [STAThread]
        static void Main(string[] args)
        {
            IEnumerator e = TaskA();
            for (int i = 0; i < 10; i++) {
                bool b = e.MoveNext();
                Console.WriteLine(e.Current);
            }
        }
        static IEnumerator TaskA()
        {
            while (true) {
                for (int i = 1; i <= 3; i++) {
                    yield return i;
                }
            }
        }
    }
}

●Currentで表現できる状態変化
具体的なゲームの話をしましょう。
「男の子がまばたきしている」
ことを考えます。
Boyには状態を変化させるUpdateメソッドと
現状を画面へ表示するRenderメソッドがあります。

Boy boy = new Boy();
while (boy.生きている間)
{
    boy.Update();
    boy.Render();
}

Updateメソッドの実装は次のようになるでしょう。
３項演算を使えばもっとシンプル化も可能です。

void Update()
{
    if (this.eye == CLOSE)
       this.eye = OPEN;
    else
       this.eye = CLOSE;
}

ここでは目というプロパティに値を代入することで
状態変化を表現しています。
これはyield構文を使うとこのように書けるでしょう。

class Boy
{
    IEnumerator enumerator;
    public Boy()
    {
        enumerator = GetEnumerator();
    }
    void Update()
    {
        enumerator.MoveNext();
        eye = enumerator.Current;
    }
    IEnumerator GetEnumerator()
    {
        while (true) {
            yield return OPEN;
            yield return CLOSE;
        }
    }
}

●Currentでは表現できないケース
さて別の実装を考えます。
「女の子が携帯メールを打ちながら笑いながら歩いている」
ことを考えます
GirlはBoyと同じく状態を変化させるUpdateメソッドと
現状を画面へ表示するRenderメソッドがあります。
メインループはBoyと同じなので省略します。
yieldを使わない場合、今回のUpdateメソッドはこのように
なっているとします。

void Update()
{
    // メール内容を追加する
    string s = GetNextMailSentence();
    this.phone.Add(s);
    // 歩く
    MoveStep();
}

状態変化はすべてメソッドによって実装されています。
この場合、反論はあるかも知れませんが私はyieldの実装はこのようにするのを理想と考えています。

class Girl
{
    IEnumerator enumerator;
    public Girl()
    {
        enumerator = GetEnumerator();
    }
    void Update()
    {
        enumerator.MoveNext();
    }
    IEnumerator GetEnumerator()
    {
        while (true) {
            // メール内容を追加する
            string s = GetNextMailSentence();
            this.phone.Add(s);
            // 歩く
            MoveStep();
            yield return 0;
        }
    }
}

●私の見解
状態変化が１つのプロパティの代入による場合、
yield returnの返値としてそれを表現することができます。
しかし現実には
・複数のプロパティによって表現された状態
・代入で表現できない状態変化
などは多くありますので一般論的にみるとyield returnによる一つの値の上書きには意味を持たせる必然性は全くないと私は考えます。

むしろyieldを思想として列挙を考えていない別言語のyieldになぞらえて使用しているのである、という意思表示のためにもコルーチンとしてのyieldは無意味な値を返すべきだと考えます。
それはコルーチン向けの言語で返値が存在していない理由の一つだとこじつけられそうにも思います。

コルーチンはマイクロスレッドでありファイバーである

myugaru (myugaru@wankuma.com) — Mon, 10 Mar 2008 17:09:00 GMT

（前エントリー：http://blogs.wankuma.com/myugaru/archive/2008/03/10/127005.aspx）

前エントリーのコルーチンという概念は様々な人が独立して発見しているようです。

（人間って素晴らしいですね！）

なので色々な単語で表現されているようです。

そのなかでもマイクロスレッドやファイバーが有名みたいです。

（あと今回は~~面倒なので~~言及してませんがtry～catch構文とか
C言語のlongjump()とか古いBASICのON ERRORからのRESUMEなんかでも
同一概念を表現する手段としてひょっとしたら使い道がありそうです。）

●まずマイクロスレッドの紹介です。全くコルーチンと同じ内容です。

前エントリーで凪瀬さんが返値を使っていないのがキショクワルイとの指摘でしたが、

このマイクロスレッドの参照ＵＲＬにかかれている例をみてもらうと返値を使っていないという

例にもなっています。そしてとても完成度が高いドキュメントです。（ゲームも完成度は相当高いです）

＃この仕様はさっそくそのまま模倣させてもらおうかとｗｗ

マイクロスレッド講座 - 弾幕風Wiki

東方弾幕風 - と～ほ～GC

●つぎにファイバーの紹介です。

と思ったのですがゲーム的な説明ページを見つけられませんでした。

ファイバーというのはRuby言語にそのものずばりのクラスが存在しています。

ここは、

Ruby言語にお詳しい方にエントリーを書いていただいてトラックバック

いただけるととても嬉しいです（タリキホンガンといいますｗｗ）

class Fiber - Rubyリファレンスマニュアル刷新計画

17:50追記

シャノンさんよりWIN32APIにCreateFiber()なるものがあるとのご指摘をいただきました。

なのでこちらについてもお詳しい方からのトラバを（ｒｙ

シャノンさん、ありがとうございました。

コルーチンと運命の出会い

myugaru (myugaru@wankuma.com) — Mon, 10 Mar 2008 11:34:00 GMT

ああ、とうとう出会ってしまいました。たぶんちょっとゲームに詳しい人ならば「myugaruはいつこれに気付くのだろう？」とか思っていたのではないでしょうか？

かれこれ３ヶ月くらいかかってやっと出会いました。

コ　ル　ー　チ　ン

今かなり笑われてる気がするけど気にせず感動に浸っておきます。

なんて素敵なコルーチン。

おかげで私が考えていた「ややこしいタスクシステム構想」はほとんど０に帰しましたｗ

じゃあこっから真面目にコルーチンについて語ります。

コルーチン - Wikipedia

この構造をゲーム関連の情報集めをしている際に見つけた。
なるほどこれは確かにすごい発想だと思う。
そしてC#のyieldは正にこの機能を実現するためにあると思った。
色々やってみると２つの利点が見えた。

第１の利点．ゲームでのタスクシステムに利用できる

もちろん一番はっきりとした利点はこれである。
簡単に説明すると例えば並列動作する２つのゲームタスクを考える。
タスクＡは３つの状態を繰り返しタスクＢは２つの状態を繰り返すと仮定する。
実際には足踏みをするキャラだったり煙突から上がる煙だったりするかも知れない。
コルーチンによる驚異的明瞭コードはこうなる。

using System;
using System.Collections;
    
namespace CoRoutine
{
    static class Program
    {
        static int stateA, stateB;
    
        [STAThread]
        static void Main(string[] args)
        {
            var a = TaskA();
            var b = TaskB();
            for (int i = 0; i < 10; i++) {
                a.MoveNext();
                b.MoveNext();
                Console.WriteLine("A{0} B{1}", stateA, stateB);
            }
            Console.ReadLine();
        }
    
        static IEnumerator TaskA()
        {
            while (true) {
                for (stateA = 1; stateA <= 3; stateA++) {
                    yield return 0;
                }
            }
        }
    
        static IEnumerator TaskB()
        {
            while (true) {
                for (stateB = 1; stateB <= 2; stateB++) {
                    yield return 0;
                }
            }
        }
    }
}

第２の利点．リバースエンジニアリングを阻止できる

先日リバースエンジニアリングの話題を出した。
http://blogs.wankuma.com/myugaru/archive/2008/03/06/126503.aspx
内容は私が他人のプログラムを解析する話になっていたが、
これが逆に私のプログラムを誰かに解析されるって事になると、
ずいぶんと勝手な言い分だけどあまり嬉しくはない。

だがここで朗報はyieldによるコルーチンは少なくとも現バージョンのReflectorでは元のソースに復元が出来ないのだ。

更に好都合なのはコルーチンにこそゲームの核となるビジネスロジックの大半が記述されるのである。

試しに上のソースをReflectorにかけてみた。結果は上のたったあれだけのソースがgotoの応酬でとんでもない事になっている。（応酬ってほど多くは無かったね＾＾；；）興味のある方はリンク先をご覧いただきたい。

上のソースのReflectorの出力結果→http://myugaru.wankuma.com/20080310CoRoutine.txt

?Ｐ．Ｓ．もしyield returnに対応したリバースエンジニアツールをご存知ならご一報くださいね＾＾；；；

ボトムアップで行こう～

myugaru (myugaru@wankuma.com) — Wed, 13 Feb 2008 16:52:00 GMT

ゲームってのは真剣に作るとOS作りに匹敵する作業がある。あと今の世の中、もう一から素人でもゲームが作れるようなスクリプト形式のゲーム作成ツールが多くあるのも知っている。それでも敢えて私は今から一からゲームを作ってみようかなって思っている。きっかけとなった出来事がいくつかあるので思いつくまま書いてみよう。

出来事１．組み込みで小さいOS作りに参加したことがある。その頃の私はなぜいまさら一からOSを組み立てる必要があるのか？とかなり気乗りしないままに参加した。しかし参加して本当によかったと今では思っている。WindowsのAPIバイブルとかかなり簡単に読めるくらいにOSそのものの理解が増えたからだ。さらに先日、知り合いから数年の歳月を経てそのOSの派生が某社のカーナビゲーションに組み込まれているのを聞いた。なんだか自分はほとんど無関係といえるくらいの端っこのPGなのだがかなり嬉しかった。

出来事２．最近ゲームセンターに行かなくなった。それまで実は私はかなりのゲーム好きで一週間のうち３日以上はゲームセンターに居るような人間だった。それがどうしてゲームセンターから離れてしまったかというと友人がこなくなってきたからである。みんな大人になったんだなあって最初は思っていたが、どうもそれだけではない何かがあるような気がしている。

ゲームセンターが次々と閉鎖する裏にWiiの躍進

まあこの人のWiiが全ての悪という感じの意見はちょっとこじつけ過ぎると思ったが、実際問題としてゲーセン人口がどういうわけか減っており、その結果私のような飯よりゲームが好きだった人間もいつのまにか足が遠のいている。

出来事３．C#が楽しすぎる。この言語が１０年前のVC言語バリバリで仕事をしていた私の前に出現していたらなあ。そしてなぜだかMicrosoft様はC#でゲームを作れと言っている。XNAがどうしてVBではなくてC#なのかは私のような凡人にはわからないが・・、とりあえずC#はがんばればゲームにとても相性のよい言語らしいという理解でOKでしょうか？＞Microsoft様。

とまあ。色々とほかにも小さい事件もあったりして私はゲームを作ろうとしているわけである（よくわからないですね＾＾；；；）

ということで早速何か始めるのだが。初めに私は何をやるにしても次の二者択一から始めている。

１．トップダウンで行く～

２．ボトムアップで行く～

やっぱゲームってのは自分にとっては未知数部分が多いのでしっかりしたライブラリやらフレームワークやらをくみ上げて挑んだほうが後で泣かなくて済みそうな気配がするのだ（弱気。そんなわけでボトムアップで行く～ことにした。まずは頻繁に発生しそうでライブラリ化したいところをちょこっと列挙してみようかなあ。

・テクスチャからスプライトを切り出して描画するところ

・ゲーム中で使われるオブジェクト（敵とか弾とか自機とか）の管理

・画面の全オブジェクトを更新→全オブジェクトを描画→全オブジェクトを(ryって繰り返すところ

・画面の現在の状況に応じたイベント処理をするところ

書いてたら本当にゲーム作りってのはOSなんだなあって分かる。ちょっと怖いけどあせらず気長にがんばろう。

ということで今日は一行もC#書かずでした＾＾；；

C#とManaged DirectX

myugaru (myugaru@wankuma.com) — Mon, 11 Feb 2008 23:09:00 GMT

世の中はC#とXNAなんだろうけど、うちのしょぼいノートPCではそもそもXNAが要求しているピクセルシェーダ２．０うんぬんを満たしていない。かといって無理やりソフトエミュレートなモードでXNAを実行すると・・・とてもじゃないがゲームどころのスピードが出ない。

仕方ないので、すでに開発が途絶えているとの悲しいうわさのManagedDirectXでがんばってみようと思う。

といってもRPGみたいな系はとてもじゃないが気力が持ちそうに無いので、なんかカードゲームっぽいのとかシューティングっぽいのは作れそうなのでそのへんを目指そうかなあ。