メンバー向けブログです。 2008-09-07T20:14:48+09:00 ho-senka 忍者ブログ wire12aldente.blog.shinobi.jp://entry/10 2010-06-25T02:02:56+09:00 2010-06-25T02:02:56+09:00 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を分ける必要ってどこにあるんだろ
要検証
]]> ho-senka wire12aldente.blog.shinobi.jp://entry/9 2010-06-24T02:18:12+09:00 2010-06-24T02:18:12+09:00
■イベントっていう考え方

クラス間で情報をやりとりする場合、参照を持たせ合っていたら何がどれを持っているかわけわからなくなる。
つーか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クラスに登録していく。スクリーンごとにグラフィックデータを持たせる。ポーズ画面など、画面の切り替えが必要な場合有用。


■敵の動きについて
シューティングの敵って外部の情報に全く影響されないんだな。出現時間と経過時間の差で自分の位置を算出してる。弾が当たったら死んで消えるけど、動きを変更させる要素があるわけでもない。これは意外と盲点だったので書いとく
]]> ho-senka wire12aldente.blog.shinobi.jp://entry/8 2010-06-22T01:01:54+09:00 2010-06-22T01:01:54+09:00 とりあえずXNAに慣れないと話にならないので、手っ取り早くチュートリアルをなぞっていきます。
ヘルプに載ってる[XNA Game Studio 3.1>プログラミングガイド>拡張チュートリアル>TopDownShooter]を進めていきます。

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

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

]]> ho-senka wire12aldente.blog.shinobi.jp://entry/7 2010-06-17T23:54:40+09:00 2010-06-17T23:54:40+09:00 日に1,2時間程度、隔日のペースなのでのんびりと飽きるまで更新し続けます。

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

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

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

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

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

]]> ho-senka wire12aldente.blog.shinobi.jp://entry/6 2009-06-10T11:07:44+09:00 2009-06-10T11:07:44+09:00 基本はDirectXをC++で。Mac用にOpenGL、ruby+SDLなど

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

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

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

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

操作キャラクター同士の衝突判定。攻撃判定と被攻撃判定の当たり判定。オプション(飛び道具など)の攻撃判定と相殺判定。当て身、投げ、ガードなど
]]> ho-senka wire12aldente.blog.shinobi.jp://entry/5 2008-11-08T13:41:10+09:00 2008-11-08T13:41:10+09:00
■InputManagerクラスの実装
シングルトンでGameAppからInit、Releaseされる。
initメソッドでInputクラスの初期化、コンフィグ読み込み、コンフィグメニューから呼び出すことも考えて独自メソッドにする。
Inputクラスをvectorで保持する。具体的にはPlayer1のパッドや、Player2のパッドに対応。多人数にも対応するかも
updateメソッドでInputクラスのupdateメソッドを呼び出して入力データを一挙更新する。
コンフィグデータと照会して方向キー＋4ボタンの入力を抽出。
＊余裕があれば、押し、離し、溜めたフレーム数なども格納できるようにしたい。あと押し込み深度とか？いらんけど
＊さらに余裕があれば入力の履歴を取って格納しておくクラスも作りたい。コマンド入力判定、リプレイに使用する。

//キャラクタなどの制御でどう使われるか
InputState input01 = Input().P1().getInput();
if( input01 & BUTTON_A)
    //ボタンAを押された時の処理
else if(input01 & BUTTON_B)
    //ボタンBを押された時の処理

定数はマクロで宣言。Input.hに記述。

■AnimationManagerの実装
CharactorObjのinitメソッドでm_pAnimationManager = new AnimationManager;　とする
抽象クラスで宣言するか？→AnimationしないObjもあるかもしれない、保留
initメソッドで初期化、AnimDataに外部ファイルからデータ読み込み。画像ファイルロード。
CharactorObjのRunメソッド(毎フレーム呼ばれるメソッド)で、キャラの更新が終わった後にm_pAnimeManager.update();を呼び出す？Drawの直前のがいいか
updateメソッドではキャラの状態、フレーム数と、動作の全体フレーム数、キーフレームの位置から描くべき画像の位置を算出して格納する。返すだけでいいかな
CharactorObjはそれを受け取って、Drawメソッドで描画する。

■描画の仕組みなど

]]> ho-senka wire12aldente.blog.shinobi.jp://entry/4 2008-11-05T11:38:46+09:00 2008-11-05T11:38:46+09:00 www21.atwiki.jp/ntgrock/pages/5.html
wiki更新しました。

てなわけでコミケに受かってました。12月29日月曜日、２日目。
マスター作ってインストーラー作って、CDに焼いて飾り作って、説明書みたいなのでっち上げる期間考えたら７週間くらいしかない
最低限盛り込む要素を考えてみる。
www21.atwiki.jp/ntgrock/pages/75.html

一番ネックになりそうなのはストーリーモード。ノベルパートのスクリプトとCPUの動きを作るのがヤバそう。いざとなったらストーリーモードごとぶった切るしかない。

シーン間でのデータの渡し方について
特にCharaSelectSceneで選んだキャラとステージをBattleSceneに受け渡す場合なんだけど
・CharaSelectScene内でSceneDataクラスをnewして、SceneManagerに引っ掛ける。BattleSceneに遷移したらコンストラクタでSceneDataクラスを漁る。漁った後はdeleteする？
こんなのでいいのかしらん。シーンからマネージャの中身を漁るのはオブジェクト指向的にスマートじゃない気がするんだけど、CharaSelectSceneが存在する限りBattleSceneは存在できない設計だからデータはどこかに明示的においとかなきゃ行けないわけで、だからといってGameAppに引っ掛けるのもなんだかなーと。
やっぱこのシーン遷移の方法がマズい気がするんだぜ。だけど引き返せないこの現実。

キャラクターの制御について
void CharactorObj::updateFrame()が毎回呼ばれてキャラクターの動作を制御する。
先ず自己の状態(enum CharaState)により呼び出す制御関数を決定する。ex. void onWalkFoward();
そしてその状態になって何フレーム目かによって制御を変更する。そこでInputコマンドを取って状態を変更したり、加減速をつけたりする。
最後にその状態になって何フレーム目かをインクリメント

状態を変更するにはchangeState(CharaState cs)を呼び出す。
状態変数を変更、状態フレーム数を初期化。0にするか1にするかはインクリメントする場所を通るかどうかによる。

上の制御とは別に、全状態共通の制御処理も行う。ex. 重力加速度の追加、摩擦からの減速を追加。
加速度による速度の適用、速度による位置の更新。


全オブジェクトの更新が完了した後に相対的なイベントの取得を行う。あたり判定とかそういうの。
衝突判定、振り向き、着地や、壁際の位置補正もこれに分類する。
こいつの実装を考えてはいるんだけど、あんまパッとしないんだよな]]> ho-senka wire12aldente.blog.shinobi.jp://entry/3 2008-10-14T11:31:23+09:00 2008-10-14T11:31:23+09:00 http://9arrows.com/index.html
オンラインの工程管理ツール。
紹介記事
http://www.moongift.jp/2008/09/9arrows/

日本語対応しててもっと使い勝手のいいのがあるかどうか探索中。つーかどう使うかもよくわかりませんが。

◇用語メモ
＿WBS(Work Breakdown Structure)
プロジェクト計画手法の一つ。プロジェクトの成果物を細かく設定し、それに必要な作業を考えて人員を配置していく、らしい。
ゲームだったらハード寄りのシステム管理(描画、サウンド、入力)や、シーン管理、スクリプト管理
、スクリプト作成、素材管理、素材作成、などに分かれる？

_Gantt chart(ガントチャート)
工程管理に用いられる帯状グラフ

_成果物
プロジェクト計画策定時に作成、開発、製造が計画された上で作られるもの。顧客への納品する品物だけじゃなく、プロジェクトに関わる書類などもこう呼ぶらしい。

_マイルストーン管理
中間目標地点のようなもの？工程遅延の許されない大きな節目のこと。マイルストーンへの進捗を監視し、適宜工程の修正を行って新たな計画を立て、再び実施する形でプロジェクトを進行する。


]]> ho-senka wire12aldente.blog.shinobi.jp://entry/2 2008-09-08T00:12:43+09:00 2008-09-08T00:12:43+09:00 「人と共同でプログラムを組み上げる」

この取り組みは始めてだ。しかも複雑なゲームプログラミング。
こいつぁ厄介だぜ…

不安はあるけど面白そう。やるからにはええもん作り上げるぜー！

9月の目標
・中旬までに基幹プログラムの概念を理解、後シングルトンパターンもね。
･10月までにはサークルロゴ→タイトル画面の流れを組み上げる。


仕事が定時で終われる今のうちに出来ることはやっとかなあかんな…

]]> ho-senka wire12aldente.blog.shinobi.jp://entry/1 2008-09-07T20:15:48+09:00 2008-09-07T20:15:48+09:00 現在の作業進捗、サークルについてやってることを報告するブログです。

※例
■やってること
-　DirectAudio周りの制御クラス構築中。
-　オブジェクト指向についての本、170Pまで読了。440あるわこれ･･･

■やりたいこと
-　キャラクター動作の仕様を最終決定したい
-　キャラクターアニメーションに関する設計を済ませたい。ツールも含めて

まぁ伝わるように好き勝手に書けばいいよ。
さぁみんなで、やってるのをアピールだ！！]]> ho-senka