プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
攻撃任務詳細画面01
開発中の戦闘任務詳細画面
選択項目が多いので2つの表に分割された。重要な項目は左側に配置されているようだ。



◎衝突判定の変更

前回コメントで、vDog IkumoさんからBoundingBoxよりBoundingSphereの方が負荷が低いと教えて頂きましたので、拠点の衝突判定をBoundingSphereに変更しました。

既に0.1msだったので、改修後の効果は確認できません(誤差の範囲)が、衝突判定は増加予定ですので今後も参考とさせて頂きます。

vDog Ikumoさん、どうもありがとうございました!^^



◎ネームスペースの活用

開発を始めた当時、まだネームスペースがどういうものか知りませんでした。後でネームスペースを活用した方が良いことに気付いたものの、途中で変更するとぐちゃぐちゃになりそうで、先延ばしにしてました。

その間にもソースファイルは増え続け、80本を超えました。それらを全て1つのネームスペースで管理しています(爆)

駐留任務が一段落して区切りが良いので、ここでネームスペースの適用を図ります。

えーと…ネームスペースとクラス名が同じ名前だとまずいのか。とりあえず複数形のsを付けて、フォルダ名も同様に変更して、呼び出し側にusing付けて…ブツブツ。

…終わりました。
コンパイル速度が若干早くなったような…気のせいか?w



◎テーブルイメージ取得

今回から攻撃任務の開発に着手します。まずは任務指定画面を作成するために、攻撃任務のテーブルイメージを取得しましょう。

tableImage003old

このまだと縦が長すぎて1画面に納まらないですね。2つに分割しましょう。

tableImage003   tableImage004

これで1画面に納まりますね。



◎選択肢を横に並べる

さて、問題は2つの表を横に並べて1画面に納めるか、2画面切り替えて順番に指定するか…プレイヤーは前者の方が把握しやすいと思うので、横並び方式としましょう。これは従来方式と異なるのでプログラムがちょっと面倒ですが、操作性優先で頑張らないといけませんね。

攻撃任務詳細画面01   任務確認画面01

「攻撃目標」「移動方針」は既存の別画面で指定可能です。
開戦時機の「日付指定」「合図指定」は未作成です。
(ゲーム時間確定後に作成予定)

任務確認画面は、項目が多すぎて入りきらないので、顔画像を上側から左側に移動して全体的に横長としました。


任務情報画面01

任務情報画面もレイアウトを少し変更したのですが、攻撃任務は項目が多いので縦長ですね。レイアウトは後日また調整するかもしれません。

ちなみに、攻撃任務を指定すると、部隊が攻撃目標に向けて移動を開始します。目的地に到着すると駐留しちゃいますけどね(笑)



◎次回予告

攻撃任務の画面系は概ね完成しました。

次回は移動処理を見直します。

スポンサーサイト

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

| BLOG TOP |
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

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

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
二列縦隊
開発中のメイン画面
伝令システムを仮作成し、連隊への任務指示が配下部隊に伝えられて目的地に移動するようになった。部隊の陣形も追加された。



◎スタートとゴール座標のズレ

今回最初の課題は、拠点座標と部隊表示位置のズレの修正です。

これは計算式の補正値がズレていると予想したのですが、原因はちょっと意外なところにありました。

部隊移動関連整理01

部隊は、シュウの手前(南)と、葉の右手前(東南)に集合しています。

部隊移動経路は、配列座標 → マップ座標 に変換した座標としています。これは変換前のセル(マス目)の中心座標であり、スタートとゴールもセルの中心座標となってました。
(初動がおかしなケースがあると思ったら、原因はコレかw)

部隊移動経路データの最初と最後(スタートとゴール)に、マップ座標系のスタート座標とゴール座標をセットします。(以前はセルの中心座標がセットされてました)

部隊移動関連整理02

部隊は、拠点の真上で停止しました。
ズレが修正されました^^

後日、拠点付近に到着したら部隊を消す(入城)処理を追加します。部隊がいきなり消えると不自然なので、少し工夫が必要ですね。



◎陣形追加

『二列横隊』陣形で部隊移動すると、兵士が道をはみ出て見た目がイマイチなので、『二列縦隊』陣形を追加しました。

二列縦隊

陣形は移動速度や戦闘力に影響する予定ですが、効果パラメータは未実装なので、今回は位置パラメータのみです。

いずれ方向転換や戦闘アニメも整備しないと(^^;



◎マップ外の拠点

移動不可の拠点が存在するようなのでチェックしたら、マップ外に配置された拠点がありました。

部隊移動関連整理03

何故か部隊が到着しちゃいました(笑)

・移動不可時の処理が未実装
・先程の修正でゴール座標をセット

上記2点の影響で、マップの角端まで最短経路で道なりに移動し、そこからゴールまで一直線で移動しました。
(以前はエラーになったのに)エラーが回避された要因はコレかw



◎伝令システムの仮作成

ここからが本題。
駐留任務の駐留目標と、部隊の移動経路を連動させます。

…いや待てよ?連隊の駐留任務詳細画面等は実装済ですが、ゲーム時間や伝令システムは未実装なので、連隊任務が部隊まで伝達されません。また、部隊の駐留任務詳細画面等は未実装なので、部隊任務を直接指定することもできません。

とりあえず今回は伝令システムを仮作成し、連隊任務を各部隊に反映することとします。

1 伝令クラスと伝令管理クラスを仮作成する

2 連隊駐留任務決定後、各部隊向けの
  伝令インスタンスを作成する

3 伝令インスタンスは、3秒後に各部隊へ
  連隊任務を伝える(経路変更)

4 伝令インスタンスをリストから削除する

実装して動かすと、4番の「リストから削除」でエラーが発生しました。

コレクションが変更されました。列挙操作は実行されない可能性があります。

foreachの中でリストからインスタンスを削除したことが原因らしいので、foreach → forに変更したら、エラーが出なくなりました。

…こんな対応で良いのだろうか?(汗)



◎任務と部隊移動の連携

連隊任務が伝令によって各部隊に反映されました。次に、各部隊が駐留目標へ向かうようにします。

部隊移動関連整理04   部隊移動関連整理05

静止画だとわかりませんが、以下のように動きます。

徐晃連隊は宛に向けて移動中
 ↓
徐晃連隊に樊城への駐留任務を指示
 ↓(3秒)
徐晃本隊停止、各部隊へ任務指示
 ↓(3秒)
各部隊停止、経路探索開始
 ↓(?秒)
経路探索完了した部隊から、樊城に向けて移動開始

経路探索に時間がかかるのが難点ですが、任務の伝達と部隊移動はきちんと出来ています^^



◎おまけ(デバッグ小話)

目的地到着後、その場で反復運動(反転&微小移動のループ)する現象が当初から発生し、長らく原因不明だったのですが、これはゲーム時間の理解不足に起因するものでした。修正すると、反復現象が解消し、移動がとても滑らかになりました。

…修正前は、奇数フレームのみ移動してました(爆)



◎次回予告

伝令システムは時差/偽報/誤報など大幅に拡張する予定ですが、とりあえずベースが出来て「任務指示 → 伝令 → 移動」と一通り繋がったのは嬉しいです^^

次回は拠点入城処理を実装します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
三国志大戦
三国志大戦
セガのオンライン対戦型カードアーケードゲーム。盤面のカードを動かすことで画面内の部隊も移動するという画期的なシステムで人気を博した。その後バージョンアップや続編が登場し、DSにも移植された。



◎6月の目標達成度

・活動時間月72時間以上

実績:57h(達成率:79%)


・部隊移動処理の実装(32h)

実績:33hで実装中(達成率:80%)


・駐留任務効果の実装(16h)

実績:未着手(達成率:0%)


・ブログ更新/HP更新(24h)

実績:21h(達成率:100%)


・予定外作業

実績:3hで拠点座標修正

6月前半は身内のフォローに奔走してました。後半の進捗もいまいちでした(--;



◎作業時間分析

作業時間集計2011年6月(PDF形式)

○良かった点
・技術的に難しそうな問題を解決した
・長いこと先送りしてた問題を解決した

○悪かった点
・後半は余裕があったのに活動時間が少ない
・1日当たりの活動時間が非常に少ない

拘束時間は少ないので時間的余裕はあったのですが、どうしても考え事が頭から離れず、開発に専念できませんでした。
(余計な事考えても時間の無駄!…と分かっていても止められない)

また、夏の生活時間帯は夜型を理想としていますが、日中に突発的な用事が増えて、生活時間帯が安定しなかったことも敗因かな?



◎身内の話

以前記述した通り、6月前半は甥の事件フォローや家庭教師等で開発に専念できませんでした。中旬は父が癌手術を行い、(手術は無事成功したのですが)母が看護疲れで体調を崩すに至りました。

子供達が看護や家事の応援に駆け付けたのですが、母はどうにもじっとしてられない性分らしく、体調が少しでも回復すると家事を再開し、また体調が悪化するという無限ループ…。「病気の時ぐらい大人しく寝てろ!」と言っても聞く耳持ちません。困ったものです(苦笑)

そんなこんなで6月はいろいろありましたが、事件は収束し父も退院したので現在は落ち着いています。これまで身内のトラブルは殆ど無かったのに、来る時は一度に来るものですね。



◎騒音対策

以前から道路工事が度々行われ、「同じ場所を何度も掘り返すのは何故か?」と疑問を抱いていたのですが、これはいわばプロローグに過ぎなかったようです。7~9月に近所で新築工事が予定され、施行主と工事業者が粗品持って挨拶に来ました。

昨年も旧宅裏の建替工事に悩まされ、騒音から逃げるように新宅に越してきたのに、またしても工事騒音に悩まされるとは…これはもう宿命か?(爆)


避難と様子見を兼ねて、実家に戻る回数を増やそうかと考えていますが、夏の自転車移動は汗だくで大変だし、実家側の都合もあるので、どれくらいの頻度になるかわかりません。

もし(実家避難も含めて)外出回数が増えるようなら、ノートPC新規購入&開発環境移行も検討します。



◎節電目標

私は昨年「7月は冷房自粛!」を目標に掲げ、達成しました。お陰で健康と電気代と地球環境には良かったのですが、肝心の開発進捗はボロボロで、「夏の冷房は必須オプションだ!」と痛感しました(笑)

しかし脱原発派を自称する身でありながら、冷房無制限というわけにもいきません。やはり節電目標を掲げて自制すべきでしょう。

A案:室内温度30度以上の場合のみ冷房許可

B案:冷房使用日を10日以内とする

C案:電気使用量を例年比25%削減する

A案は「ほぼ毎日30度以上なので節電効果低い」、B案は「使用日は無制限に使用できてしまう」、というわけでC案とします。


具体的な数値目標を算出します。

・春/秋/冬の平均使用料160kWh、電気代3500円

・夏の電気代は6000円台 → 使用料は320kWhと推算

というわけで、7月の使用量目標は240kWhとします。
(数値目標は目安なので、基本料等の細かい計算は省きました)



◎進捗状況チェック

既に1カ月以上遅延しています。半分は不可抗力、半分はサボリです(汗)


今夏は工事騒音と冷房制限という2大要素が加わります。我慢大会会場でデバッグしてペースが上がるとも思えず、進捗はさらに悪化する見込み(ーー;



◎7月の目標

・活動時間月100時間以上

・移動処理関連整備(16h)

・駐留任務効果の実装(24h)

・攻撃任務画面の実装(32h)

・ブログ更新/HP更新(28h)

・電気使用量:240kWh以下

騒音も暑さも7月がピークと予想してるので、何とか今月を凌ぎたいところです。

電気使用量は、たまにメーターをチェックしながらペース維持を図ります。



◎次回予告

次回は部隊移動関連の整備を行います。

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

| BLOG TOP |

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