解析中ー

■Update周り
Game1クラスのUpdateの中身
    ・待機状態のプレイヤー2のスタートボタンが押されたらプレイヤー2を初期化する。
    ・総経過時間に前回のUpdateからの経過時間を追加
    ・プレイヤー1のUpdateを呼び出す
        ObjectStatusによって処理を振り分ける。Stateパターン
    ・プレイヤー2のUpdateを呼び出す
    ・敵群のUpdateを呼び出す
        敵はStateの配列で状態を保持してるのみ。Stateによって処理を振り分ける
    ・GamePlayHostのUpdateを呼び出す
        SpawnWavesを呼び出す。条件が揃えば次の敵のウェーブを作成する
        当たり判定をする。総当り
        SpawnSeekersを呼び出す。スコアが一定値を超えていたら、次のパターンへ入る？
        敵の数だけUpdateSeekerを呼び出す。Statusに応じて処理を振り分けてる。移動など


■気になったとこ
GamePlayHostは当たり判定したりする関係で、Game1クラスへの参照を持ってる。確かにこの設計の方がスッキリしてるな。
「ref waves[i]」refってなんだろ、見た感じ参照を渡してるっぽい
UpdateでいちいちGameTime渡してるのは何故だろ、必要だってのは分かるけど他に方法あるんじゃないのか
「？」の条件式がいまいち使い慣れない。

Seeker情報は何故GamePlayHost側のUpdateで操作されてるのか。当たり判定との順番の兼ね合いだろうけど。
これならGamePlayHostのUpdateの中でプレイヤと敵のUpdate呼んでもいいんじゃね。なんかスマートじゃない気がするんだけど
ていうかEnemiesのUpdateとUpdateSeekerを分ける必要ってどこにあるんだろ
要検証

TopDownShooterは別にチュートリアルじゃないよね

書店で「ゲームコーディングコンプリート」立ち読み中。流石に買えないぜ…

■イベントっていう考え方

クラス間で情報をやりとりする場合、参照を持たせ合っていたら何がどれを持っているかわけわからなくなる。
つーかincludeがえらいことになる。
だから参照を持ったクラスを一つ用意しておいて、そのクラスにイベントを投げてデータを処理してもらう。

■プロセス
イベントは瞬間的に発生するもので、プロセスってのは数Fに渡って持続する状態。他オブジェクトのプロセスを変更したい場合も、一つのクラスを経由してやれば参照を持たせあわなくて済む？
プロセスマネージャの具体的な実装を見てみよう



今日のTopDownShooter解析～

とりえあずF11連打で動きを見る。


■Avatarクラスのリセットの作り方
引数付きリセットは、引数の受け渡しを済ませてから引数なしリセットのメソッドを呼び出してる。
リセットの内部ではリスタートのメソッドを呼び出して、変数を初期化してから、ステートを非アクティブ状態にしてる。

何が言いたいかってと、同じコードは2度と書かん！ってこと


■ContentManagerクラス
http://msdn.microsoft.com/ja-jp/library/microsoft.xna.framework.content.contentmanager.aspx

どうやらこれを使えば、外部データを読み込むのに便利らしい。XMLからオブジェクトデータを流しこんでた。

BasicInfo.XCurve = content.Load<Curve>("XCurve1");

こんな感じ。
contentはContentManagerクラスの参照。XCurve1はプロジェクトにコンテントとして登録されているxmlファイル。

■GameStateManagement
GameScreenクラスをScreenManagerクラスに登録していく。スクリーンごとにグラフィックデータを持たせる。ポーズ画面など、画面の切り替えが必要な場合有用。


■敵の動きについて
シューティングの敵って外部の情報に全く影響されないんだな。出現時間と経過時間の差で自分の位置を算出してる。弾が当たったら死んで消えるけど、動きを変更させる要素があるわけでもない。これは意外と盲点だったので書いとく

はじまりはじまり

VisualC#2008 ExpressEditionとXNA GameStudio 3.1を入れるだけで1日、友人が来てたので1日サボって今日から始めます。
とりあえずXNAに慣れないと話にならないので、手っ取り早くチュートリアルをなぞっていきます。
ヘルプに載ってる[XNA Game Studio 3.1>プログラミングガイド>拡張チュートリアル>TopDownShooter]を進めていきます。

http://msdn.microsoft.com/ja-jp/library/dd282449.aspx

コード改造してオリジナルっぽいゲーム作りたいなー

1年経っとる！

ちょいと思うところがあるので、ゲーム制作を再開します。
日に1,2時間程度、隔日のペースなのでのんびりと飽きるまで更新し続けます。

さて、ToDoリストとしては
・XNAの習熟を目的とした、小作品の作成。
・XSIを使ったモデリング。これは急がずに超のんびり
・音楽素材の自作に関する勉強。これもあんま急がない
・とあるシナリオの書き溜め。あじさい的な何か。吉里吉里にてゲーム化する予定だが、これものんびりと。

とりあえず小品を作れるようになって自信を付ける。

具体的な時間割は、6時くらいから9時まで(食事当番じゃない場合)と。11時くらいから1時くらいまで。
前者は別な創作活動に充てる場合があるので、実質1日平均2時間程度。

やったことをメモ書きしていきます。

とりあえずXNA入れてきますね。。。

目標：格闘ゲームを作れるようになる。

1．ハードウェア依存コード、描画とかサウンドとかマルチスレッドとかの習得。
基本はDirectXをC++で。Mac用にOpenGL、ruby+SDLなど

ファイル操作　データの読み込み、書き出し
フォントの表示　デバッグ、簡単な文字

入力、ジョイパッド、キーコンフィグ、同時押しなど

2．シーン遷移のプログラミング
オープニングシーン→
    メニューシーン→
        キャラクターセレクトシーン→
            対戦前演出シーン(ローディング)->
                対戦シーン
例えば対戦演出シーンは、選択されたキャラクター情報が必要になる。キャラクターセレクトシーンからなんらかの方法で選択されたキャラを知る必要がある。
キャラクターデータの読み込みはマルチスレッドで裏読みしておきたい。キャラセレシーンで既に読んでおければいいが、キャンセルされた場合、読み込みを途中でストップして破棄する機能が必要になる。
次のシーンのデータを裏読みする場合、次のシーンは前のシーンの内部に存在する子要素にするか、データをどこかグローバル領域に確保しておき、次のシーンはそのポインタから参照するようにするか。
前者はシーン遷移がややこしくなりそう。後者はデータの扱いがややこしくなりそう

3．アクションゲームのプログラミング
上のシーンで言うと対戦シーンの中身。単純な格闘ゲームならば、ステージは長方形でキャラがステージ外へ出ないようにすればいいが、直線ではない地面や、画面端以外の壁を実現する場合はステージとの衝突判定、衝突応答を設定しなければならないだろう。
キャラクター以外のオブジェクト、箱やらアイテムやらが出てくる場合も、キャラクターが押せるようにするのか、立てるようにするのか、上に立ったままオブジェクトが移動した場合どうなるのか、オブジェクト同士の衝突は判定するのか、などを設定する必要がある。
まぁ普通の格闘ゲームにはそんなの無いのでここでは考えない事にする。

操作キャラクター同士の衝突判定。攻撃判定と被攻撃判定の当たり判定。オプション(飛び道具など)の攻撃判定と相殺判定。当て身、投げ、ガードなど