プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発

開発中のメイン画面
入城処理を実装し、拠点間の移動が可能となった。拠点の連隊一覧画面で連隊に任務を与えると、新しい目的地へ向かって出陣する。



◎到着判定方式の検討

今回は部隊を拠点に入城させます。まず最初に、拠点到着判定方式を検討します。

手っ取り早く実装する方法として、シューティングゲームの衝突判定方式があります。これは、対象ユニットと拠点の距離が一定以内なら到着とするものです。チェック対象が多数の場合、その数だけチェックを繰り返すので、負荷が増大します。

これに対し、2DタイプのRPG等では、マップ上のオブジェクトの位置をセル(マス目)で管理する方式が一般的です。セル座標を指定すると、そのセル内に存在するオブジェクトを取得できるので、オブジェクト総数が多い場合は、衝突判定方式より負荷が軽減されます。

というわけで、セル管理方式にしようと思ったのですが、現在はマップオブジェクトの配置がフリーなので、判定が偏る可能性があります。

例えば、拠点がセル内の上側に配置されていた場合、部隊が上から近付くとギリギリの位置で到着しますが、部隊が下から近付くと少し離れた位置で到着します。

えーと…マップオブジェクトはセルの中央に配置するよう制限すれば、問題を回避できますね。

でも、部隊索敵範囲の判定は衝突判定方式だから、マップオブジェクトだけセル方式としても、あまり意味ないかな?そもそも、アニメ描画負荷に比べれば、数百個の当たり判定なんて、全然大した負荷じゃない気が…。

…あれこれ悩みましたが、結局衝突判定方式とします(^^;



◎BoundingBoxの引数

最初は拠点の到着判定(衝突判定)を矩形で管理しようとしたのですが、XNAのRectangle 構造体はint型なので、float型の座標管理には使えません。float型の矩形構造体は無いのかな?…ああそうか、XNAではBoundingBoxを使うのですね。

実を言うと、BoundingBoxは一度も使ったことがありません。コンストラクタの引数

min
BoundingBox に含まれる最小ポイント。
max
BoundingBox に含まれる最大ポイント。


minとmaxの意味が理解できず挫折した過去あり(爆)


…改めて考えると、左上隅と右下隅の座標を指定しろってことじゃないですか!

こんなことに悩んでいたとは…(>_<)


今後は、全てのユニットにBounding~を持たせ、オブジェクトの種類や陣形によって大きさを調整する方針とします。



◎実装

拠点クラスにBoundingBoxを持たせて、部隊の中心座標が含まれるか衝突判定を行い、衝突したら部隊を非表示とします。

拠点入城処理01   拠点入城処理02

拠点に到着したら、部隊が消えました。見た目は良さげですが、フレームレートは60→30fpsまで落ちてしまいました。Updateが0.5msぐらい加算されたようですが、そんなに重い処理かなぁ?

ちなみに、60fpsになるようにギリギリで調整していたので、少し負荷が増えるとすぐ落ちます(汗)



◎遅延の原因

衝突判定が遅い原因を考えると、

80部隊 × 116拠点 = 9280回

衝突判定(BoundingBox.Contains)を9千回呼び出したら0.5msかかった、ということらしい(>_<)

ちなみに、通常のシューティングゲームの場合は、自機&自弾×敵&敵弾=数百回程度として、0.03ms。無視できるレベルですね。


実は、この方式で問題が無ければ、全てのマップオブジェクト(木や柵など)を同様に管理するつもりでした。

しかし、このままでは遅すぎて汎用的に使えません。衝突判定を高速化できないでしょうか?



◎BoundingBoxの連結

BoundingBoxには連結機能があります。試してみると、個別に80回呼び出すよりも、連結箱の衝突判定を1回呼び出した方が格段に早いようです。

拠点は動かないので、予めBoundingBox.CreateMergedで全ての拠点を連結しておくと、高速化できるかもしれません。

連結箱の作成と衝突判定のサンプルコード(一部抜粋)


連結箱と衝突する場合は、衝突対象をチェックするため、個別に衝突判定を行います。衝突するケースが多いと、却って遅くなる可能性もありますが…実際にやってみると、負荷は半分になりました!

森や柵など、静止オブジェクトの衝突判定は、連結方式が良さそうですね。

さらに、拠点数を最多予定数の38に減らしたら、最終的に0.1msぐらいになって、60fpsに戻りました!^^



◎仕上げ

仕上げに以下の処理を行います。

・各部隊にBoundingSphereを用意し、衝突判定は拠点のBoundingBox(連結/個別)と部隊のBoundingSphereで行う

・到着判定は目的地付近のみ行う(負荷軽減のため)

・内部情報を更新する(拠点の駐留連隊リスト等)

・拠点情報画面から駐留中の連隊情報を確認可能とする

・情報画面表示中に他の情報画面は表示不可とする



駐留中/移動中/停止中の連隊に、他の拠点への駐留任務を与えると、新しい目的地へ移動します。
(伝令の到着と経路探索のため、出発までタイムラグがあります)

駐留任務は完成ですね!^^



◎次回予告

移動&駐留任務が完成したので、ようやくゲームっぽい操作が可能となりましたw

次回から戦闘任務に着手します。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

コメント

衝突判定の処理負荷軽減

こんにちは。
久々に拝見してだいぶゲームらしくなってきましたね。
私も衝突判定の処理負荷軽減に苦戦したので参考にできたらと思います。

BoundingBoxは6つの平面を扱うため処理負荷が高めです。
Sphere同士の判定は2点間の距離の計算だけなので処理負荷があまりかかりません。

拠点に沿うようにキャラクターを移動させたい時に衝突面との反射ベクトルを取得する際に必要ですが、拠点に近づきキャラクターを消す程度のなら処理負荷がかからないSphere同士の衝突で問題ないかと思われます。

また、Y軸方向に重なる衝突判定を行うオブジェクトがなければXZ平面のみの衝突判定を行えば更に処理負荷を抑えると思います。

こんにちは~

当初は拠点通過中部隊のモデル形状変更を考えていたので、拠点の衝突判定をなるべく厳密にしたかったのですが、この案は描画負荷やゲーム性に懸念があるので保留となりました。

当面は部隊を消すだけの処理とするので、アドバイスに準じてSphere同士の衝突判定とします。(最終段階でXZ平面判定にするかもしれません)

わかりやすいアドバイスどうもありがとうございました!^^

コメントの投稿


管理者にだけ表示を許可する

トラックバック


この記事にトラックバックする(FC2ブログユーザー)



copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。