プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
陣形情報画面01
開発中の陣形情報画面
陣形情報画面が追加された。指示ボタンを押すと、陣形変更の指示が可能になるらしい。



◎陣形情報パネルの改修

前回、陣形情報パネルをラベル部品で作成しました。これをボタン部品に変更し、陣形ボタンを押したら陣形情報画面が表示されるようにします。

部隊情報画面02

使用可能な陣形のみ、ボタンを押せるようにしました。



◎陣形情報画面の作成

グラフィカルなデザインをイメージしていたのですが、実際に作ろうとしたら、ちょっと無理がある(画面に入りきらない)ことが判明しました。

どうしたものかと悩んだのですが、(今後パラメータが増える可能性もあるので)結局いつものラベル方式で作成することにしました。

陣形情報画面01

うむむ…(~_~)

文字が多くて圧迫感ありまくりです。
過去最悪のデザインかもしれません><

いずれ作り直すつもりですが、この画面のデザインはゲーム性に直接影響しないので、当面はこれで凌いで、他の開発を優先します。



◎次回予告

陣形を指示する画面を作成したので、次回は、陣形変更機能を実装します。

スポンサーサイト

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
陣形追加01
開発中のメイン画面
10種類の陣形が追加され、見た目が賑やかになった。速度や戦闘力が部隊毎に異なり、ゲーム展開に抑揚がついた。



◎陣形調査

三国志の陣形についてネットで調べようとしたのですが、なかなかコレといった情報は掴めません。

こちらの記事から抜粋すると、

『どんな布陣でどんな戦闘をしたのか記録を残したら、それが敵国に渡って研究され、裏をかかれるかもしれない。だから、そういう記録は残さなかった』

とのことです。他の記事も散見しましたが、結局この記事を超える情報は見付からなかったので、この記事をベースに陣形データを作成します。


…実際にデータを作り始めると、特性が少なくて差別化が足りない陣形もありますね。史実よりゲーム性を重視して、こちらの記事の解釈も一部採用しましょう。

陣形データ(PDF)

鋒矢は差別化のためwikiをベースに解釈しました。司令官を最後尾、副官を先頭と想定し、副将の能力の方が戦闘力に影響するものとしました。軍師タイプの司令官と武将タイプの副官という組み合わせに最適と思われます。

他の陣形の差別化については、上記データ右端の説明欄をご覧ください。

ところで、雁行は最初の記事の解説が納得できますが、そうなるとwikiの武田八陣形の雁行の図面は、左右逆のような気がするのですが…??



◎突破力と包囲力

突破力とは、敵陣を突破して壊滅させる破壊力です。
クリティカル発生率と言った方がピンとくる人が多いかも。
発動すると、敵部隊に大損害を与え、混乱や潰走に至らしめることもあります。


包囲力とは、敵部隊を包囲殲滅する攻撃力です。
言い換えると、包囲殲滅モード発生率です。
発動すると、敵部隊の動きを封じ、多大な損害を与える状態となります。これは敵部隊が包囲を脱するまで続くので、上手くいけば、そのまま敵部隊を殲滅できます。
(武将の捕獲率も高い)

但し、発動期間中でも敵部隊の反撃は有効なので、少兵力で大兵力を包囲するのは難しそうです。また、敵部隊のクリティカル/計略/援軍等で包囲が突破されたり、逆にピンチに陥ることもあります。武将の能力や兵数も影響するので、状況に応じて作戦を変えた方が良いでしょう。

(今回は仕様検討のみ、上記実装は次回以降)



◎陣形変更ルールの検討

陣形の変更中は、攻撃力が0となり、防御力や堅牢性は半減します。
(反撃不可、被害増大、混乱しやすい)

また、陣形変更に要する時間は、既存の陣形や武将特性に影響されます。猪武者が鋒矢から他の陣形に移行すると、(致命的になるほどの)長い時間を要しますが、軍師タイプの智将が方円陣から他の陣形に移行するのは素早くできます。

陣形変更は、通常は各武将の判断で自動的に行われますが、プレイヤーが細かく指示することも可能です。
但し、遠距離の部隊には伝令到着まで時間がかかります。
また、必ず指示に従うとは限りません。

(今回は仕様検討のみ、上記実装は次回以降)



◎武将の差別化

既存ゲームの中には、武将毎に使用可能な陣形を制限して、武将の差別化を図るものがあります。

三国志軍記は、横陣と長蛇を全武将使用可能とし、武将によって他の陣形を追加しました。

武将データ(一部抜粋)(PDF)

武将と副官が居る部隊では、両将の陣形が全て使用可能です。

尚、武将不在の「支隊」は横陣と長蛇しか使えないので、単独の戦力としてはあまり期待できません。
ですが、敵部隊の側面/背面に向けた一斉攻撃や、味方部隊の側面/背面の防護役として欠かせない存在です。



◎実装

陣形関連のプログラムを改修します。

・陣形クラス/陣形リストクラスの作成
・陣形データの読み込み
・攻撃を受けた方向を判定し、戦闘結果に反映
・陣形パネルの作成
・武将情報画面/部隊情報画面の改修

部隊情報画面01   陣形追加02



いい感じになってきたと思うのですが、いかがでしょうか?



◎次回予告

陣形の解釈はゲームによって異なるようですが、リアリティより面白さ優先で、好きに解釈させて頂きました(笑)

次回は、陣形情報画面を作成します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
乱戦パフォーマンス改善01
開発中のメイン画面
乱戦時は3fpsまで低下していたパフォーマンスが60fpsまで改善され、快適にプレイできるようになった。



◎現状分析

部隊移動の調整が進むと、パフォーマンスが劣化してきました。負荷が高いのはDraw()です。
(Update()は定期探索により負荷を一定に保っています)
モーション切替の多発が原因と考えて間違いないでしょう。

乱戦時は5fpsを切ることもありますが、非戦闘時でも回避移動が多発すると20fpsを切ることがあります。

非戦闘時の回避移動は「移動 ←→ 停止」のモーション切替(=テクスチャ切替)が多発します。また、戦闘時は「移動 → 停止 →攻撃」のように遷移するケースも多いので、‘停止’がキーポイントと考えています。

実は‘停止’アニメは歩行アニメの1コマ目の画像をループ描画しているだけなので、「移動 ←→ 停止」はテクスチャ切替が実質的に発生しているわけではありません。

しかし、コード上は‘参照先が同じ別画像’という扱いになるらしく、エフェクト切替処理が発生するようです。これがパフォーマンスの劣化原因と思われます。



◎裏付け調査

モーション切替処理をコメント化して、現状分析が正しいか確認します。

○現状(非コメント化)
・通常移動時:10~60fps(8~90ms)
・数部隊の戦闘時:10~30fps(10~90ms)
・乱戦時:3~15fps(10~120ms)

○停止モーションのみコメント化
・通常移動時:30~60fps(8~10ms)
・数部隊の戦闘時:30fps(8~20ms)
・乱戦時:5~20fps(10~120ms)

○全てコメント化
・60fps(8~10ms)

()内はdraw時間


通常移動時や数部隊の戦闘時は、確かに停止モーションがネックとなっているようです。

停止モーションの改善案はあるのですが…問題は乱戦時ですね。この様子だと、停止モーションを改善しても、乱戦時はほとんど効果なさそうです。



◎開発順序の検討

「(簡単そうだから)停止モーションを先に改善する」という進め方もありますが、

・乱戦のパフォーマンス問題は放置不可
 (いずれ何とかしないとゲームにならない)

・乱戦のパフォーマンス問題が改善できた場合、
 停止モーションも同時に改善されている可能性が高い
 (その場合は停止モーション改善工数が無駄になる)

というわけで、(難しそうですが)乱戦時のパフォーマンス改善にチャレンジしましょう。



◎乱戦時のパフォーマンス改善案検討

「ゲームデザインの調整によって乱戦発生率を下げる」という回避案はありますが、多数部隊が入り乱れる乱戦の魅力は大きいので、この回避案は採用したくありません。
他に良い案はないでしょうか?

案A
・移動/停止/攻撃モーションを1枚の画像に収めて
 切替頻度を低減する
 (計略その他のモーションは画像切替方式とする)
 →1コマ当たりの画像解像度は落とさず、
  アニメ数を減らす方向で検討する
  (歩行開始モーションや攻撃開始モーションを削る)
 →近距離と中距離の攻撃モーションは同じとする
  (弓兵の近距離攻撃モーション等は作らない)

案B
・敵部隊認識中は(移動中でも)常時攻撃モーションとする
 →攻撃モーションを見直して、違和感を軽減する


案Aは、歩行開始モーションや攻撃開始モーションを削る(いきなりループモーションに入る)ので、モーションを切り替える瞬間は不自然に見えますが、パフォーマンスは裏付け調査の「全てコメント化」と同等になります。


案Bは、移動中でも攻撃モーションとなるので不自然に見えますが、やってみると違和感は案外少ないかもしれません。

例えば、戦闘中は部隊が停止しますが、槍騎兵の攻撃モーションは、馬が走り続けていても違和感を感じません。冷静に考えるとヘンですが、しかし馬は走り続けた方がカッコイイのです。
(これはゲーム的表現の「お約束」と言えるかもしれません)

そう考えると、騎兵と一緒に戦っている槍兵も走った方が自然かもしれません。というわけで、部隊が移動中でも停止中でも違和感を感じないように攻撃モーションを見直す、というのがB案です。これにより、画像切替負荷は最初の敵部隊を認識した1回に低減されるので、大幅な改善が見込めます。
(パフォーマンスは「停止モーションのみコメント化」数部隊の戦闘時と同等以上になります)


どちらの案も悪くなさそうですが、「それなら最善のパフォーマンスを目指そう!」というわけで、A案の検討を進めます。



◎アニメ画像の編集方法

移動/停止/攻撃モーションを1枚の画像に収める方法は4つあります。

A1案
・Softimageモデルの3つのモーションを連結し編集する

A2案
・アニメ画像を画像ツールで手動編集する

A3案
・既存のアニメ画像取得ツールを改修して編集する

A4案
・アニメ画像を結合して編集するツールを新規作成する


理想論で言えばA1案がベストですが、この案は問題があります。

1つは、Softimage標準のアニメ編集機能はXNAランタイムで非サポートなので、モーションを手動で編集し直す必要があるということ。

もう1つは、騎兵はまだSoftimage化されていないので、騎兵は1から作る必要があるということ。これはかなりの期間を要するので、今は避けたいです。
(馬を作り直すぐらいなら、先に弓兵を追加したい)


A2案は、アニメ画像を見て断念しました。1枚の画像に32方向×12コマあるので、最低でも64回以上切り貼りする必要があります。兵種を追加したり、モデルやモーションをちょっと手直しする度に毎回手動で切り貼りなんて、とてもやってられません。


残るはA3案A4案ですが、正直どちらも気が進まないです。

既存ツールは、SoftimageやACLのモデルから32方向分のスクリーンショットを取得してアニメ用に並べ替えるという複雑なプログラムになっているので、さらに例外処理を加えるのは避けたいです。しかし移動攻撃モーションのみ別ツールで2段階作業とするのも、いまいちすっきりしません。

どちらがマシか判断できないので、とりあえずA4案でやってみて、気に入らなければA3案とする(機能移植する)ことにします。



◎画像編集ツール作成

画像編集ツールを作成して、新方式用のアニメ画像を出力します。

SpearMan01_MoveAttack01

○従来
攻撃モーション:12コマ(攻撃開始モーション含む)
移動開始モーション:12コマ
移動ループモーション:12コマ

画像解像度:2048×2048
1コマ当たりの解像度:100×100
最大コマ数:20×20=400コマ
使用コマ数:32方向×12コマ=384コマ


○新方式
停止モーション:1コマ
移動モーション:6コマ
攻撃モーション:6コマ

画像解像度:2048×2048
1コマ当たりの解像度:96×96
最大コマ数:21×21=441コマ
使用コマ数:32方向×13コマ=416コマ


上記のように、12コマ×3枚のアニメ画像を、13コマ×1枚に集約しました。解像度はほとんど変わりませんが、移動ループモーションのコマ数を半分に減らしたのが少し気掛かりです。

尚、今回作成した画像編集ツールはわりとシンプルなコードで出来ました。ですが、この機能を既存ツールに集約するとかなり複雑になりそうなので、このまま独立させておきます。



◎実装

メインプログラムを修正し、新方式によるアニメ描画&モーション切替を実装します。



やりました!本当に60fpsを達成しました!
(思わずガッツポーズw)

アニメの劣化は気になる程ではありません。乱戦が快適に展開されて、動作テストが楽しくなってきました^^



◎次回予告

最近は3fpsまで劣化してたので「こんな調子でまともなゲームになるのか?」と内心かなり不安だったのですが、為せば成るもんですね!(^^)

部隊移動が一段落したので、次回は陣形を追加します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
部隊移動調整03
開発中のメイン画面
部隊が川に侵入するバグが多発していたが、ようやく解消されたらしい。



◎侵入不可地形への侵入

先日の改修により、全般的に動きが良くなった反面、侵入不可地形に侵入するケースが増えてしまいました。その部隊を攻撃しようとした敵部隊が「ターゲットへの移動経路無し」状態になるなど、2次的な問題を伴うので、かなり支障があります。

侵入不可地形に侵入するケース01

上図の地形において、部隊が橋(道路)の対角線から少しでも外れると、移動途中で侵入不可地形に侵入するケースが発生します。

このケースが非戦闘時も発生する理由が判らず悩んでいたのですが、

・中継地点到着判定の変更(完全一致 → 不完全一致)
・回避移動時の中継地点はセル中央を目標としない

上記改修によって、対角線から微妙に外れるケースが増えてしまったようです。



◎検討

前出のような地形で、(乱戦時においても)移動不可地形への侵入を防ぐには、仕様を根本から見直す必要があります。

A案
・部隊はセル単位で移動するよう徹底する
 →移動の途中で戦闘が発生しても、
  必ずセル中央まで移動する
 →回避移動等で後方に移動するケースを甘受する

B案
・移動可否判定において、斜めは不可とする
 →前述の地形は移動不可となる
 →マップの再デザインが必要
 →侵入不可地形の近辺では90度単位の移動となる

いずれの案もリアルさが従来より低下しますが、そもそも移動可否判定がセル単位(正方形)である以上、避けられないと思われます。

で、どちらがマシか考えると、B案は内陸部では従来通り(45度単位又はフリー)で動くので、こちらの方が影響が少なさそうな気がします。



◎試行

地形画像を作り直すのは大変なので、とりあえずカラーマップとプログラムだけ修正して試してみましょう。

あれ?何も変わらないような…あっ、経路探索で移動可否判定が呼び出されてないですね!(既存バグ発覚)

通常は経路探索で道路沿いに移動するので気付きませんでしたが、道路が無くても斜めの川を横断可能だったようです(汗)


既存バグを修正し、初期配置方法も変更して試すと…(再現性は激減したものの)侵入不可地形に侵入するケースがありました。

…何故?
理論上の問題?
プログラムの問題?



◎原因調査

調べてみると、経路探索移動で侵入不可地形を斜めに横切るケースがあるようです。…えっ?経路探索を修正したのに、何故このケースが発生するの?

…このケースは経路候補エッジから除外されていることを確認しました。では何故経路候補エッジに存在しない経路が選択されてしまうのか?

…わかりました!
経路探索処理の最終段階で、最初の経路にスタート時の座標をセットしていたのですが、これによって最初の経路が上書きされて消えてしまったことが原因でした。
(これも既存バグ)

最初の経路を上書きした場合

回避移動処理をコメント化すると現象が発生しないので、てっきり回避移動に問題があると考えていたのですが、通常の経路探索に問題があったのですね。

…修正後は、侵入不可地形に侵入するケースが解消されました!!

(補足:乱戦になっても現象が発生しないのは、新方式の効果です)



◎マップイメージ再作成

プログラム的にOKとなったので、新方式に沿ってマップイメージを再作成します。

マップイメージ再作成01

うーん…道が太い所はちょっと不自然ですね。
新方式のルールに反しない範囲で、なるべく自然になるよう作り直しましょう。

マップイメージ再作成02   部隊移動調整02

…こんなもんかな?

部隊移動が安定し、見た目も不自然にならずに済んだようなので、とりあえず一安心です(^^)



◎次回予告

長く悩まされ続けたバグの原因が、ようやく特定できました。
それにしても、たった1行のミスで…プログラムの怖いところですね(^_^;

移動経路が安定したので、次回はパフォーマンスの改善に取り組みます。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
部隊モデルの色変更05
半年前のメイン画面
部隊が動く方向は、半年前までランダムだった。今年度前半期に、部隊の移動経路探索や近接戦闘が実装された。



◎活動時間と成果の確認

年間スケジュールは5月に作成したので、5~10月の半年間の活動時間を集計しました。

2011年活動時間集計(5~10月)

実績時間平均2桁は過去最低です>_<


で、何をやったかというと、

・部隊移動(経路探索)
・部隊戦

半年前は部隊を個別に動かすことが出来ない状態だったことを考えると、一歩ずつ完成に近付いていることは間違いありません。しかし、3か月ぐらいで出来そうなものを、半年かかったというのが問題です。要するに

・活動時間がとても少ない
・作業効率(作業時間に対する成果)も芳しくない

ということですね。



◎検証と考察

作業時間が少なく進捗が遅延した理由を列挙します。

・震災の影響
 →情報収集/考察/発信時間の増加

・身内のトラブル
 →甥のいじめ対策、家庭教師、父の入院等

・環境の悪化
 →工事騒音、猛暑、節電

・サボリ

こうして見ると、不可抗力的な要素が多いですね。特に6~8月はトラブルや環境悪化のピークだったので、進捗が悪いのも頷けます。しかし9月はサボリ癖が抜けず酷かったので、10月からペナルティ制度を導入しました。

今後は悪化要因が減るので、作業時間や進捗が伸びることを期待しますが、他の悪化要因が発生しないとは限りません。むしろ半年間「何事もない」方が珍しいと考えるべきでしょう。

また、作業別に予定と実績を振り返ると、「(予定よりも)順調なケースは少なく、苦戦するケースは多い」ので、進捗が‘理想論で組んだスケジュール’より遅れるのは必然と言えるかもしれません。

改善案としては「スケジュールは余裕を持って組み、予定より遅れたら罰則規定を設ける」というのがありますが、スケジュールに追われて中途半端なゲームにしたくないので、「進捗が遅いからから罰則規定を設ける」というのは反対です。
(サボリ対策としての罰則規定はアリですが)



◎改訂版

あれこれ考えながら、年間スケジュールを以下のように改定しました。

2011年度開発スケジュール(2011年11月版)

計略/一騎打ち/エフェクト/BGM等は来年度以降とし、今年度は移動と戦闘(中距離、攻城戦含む)に専念して、ゲームの基礎を固めます。



◎今年度の目標

・「地味だが意外と面白い」と思える状態まで作りあげること
・希望者には配布可能な状態とすること



◎次回予告

次回は部隊移動の調整に戻ります。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
三国千軍伝
三国千軍伝
基本無料の戦略シミュレーションブラウザゲーム。16勢力のいずれかに参加して天下統一を目指す。戦場マップはレトロゲーム風、顔CGは漫画風のデザイン。



◎10月の目標達成度

・活動時間月160時間以上

実績:111h(達成率:69%)


・部隊戦の実装/調整(8h)

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


・モーション切替パフォーマンス向上(32h)

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


・部隊回避移動の実装(24h)

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


・陣形追加(8h)
・モデル個別移動の実装(16)
・戦闘モーションの作成(32)

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


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

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


進捗や作業時間が芳しくなく、総合評価は低いです。
しかし、ペナルティ期間中の奮闘や部隊戦の向上など、一部評価できる点もあります。



◎作業時間分析

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

○良かった点
・回避移動の実装が進み、部隊戦が向上した
・ペナルティ期間中は時間目標を達成した

○悪かった点
・3週目の作業時間が極端に少ない(週7h)
・HP未更新

ペナルティ制度のインパクトは絶大で、2週目(10~16)と4週目(24~30)は週40hを達成する一方、3週目(17~23)は反動でボロボロでした。効果が高くとも反動が強すぎると採算が合わないので、改善が必要ですね。

尚、10月は雨が多かったためか、工事騒音は9月に比べると大分マシになりました。今月は悪化しないで欲しい。



◎ペナルティ制度について

サボリ対策として『一週間の活動時間が40h未満だったら、翌週一週間ゲーム/アニメ禁止!』としました。その効果は絶大で、ペナルティ期間中は生活様式が一変したと言っても過言ではありません。依存度が想像以上に高いことを実感しました。

ペナルティ期間終了後の反動が問題で、数日遊びまくり。
気が付くと今週はあと僅か。
翌週はペナルティ確実なので、「じゃあ残り数日は来週の分まで遊んでおこう!」
子供かっつーの!(笑)


ともかく、先月のルールでは月160hに届きそうにないので、ルールを少し変えます。

『1日の活動時間目標が達成できなかったら、翌日はゲーム/アニメ禁止!』

単位を短くすることで、ペナルティ期間終了後の反動が少なくなることを期待します。



◎今後の課題について

回避移動は予想以上に時間がかかっていますが、少しずつマシになっている実感はあります。最終的に自分が納得できる状態に仕上げる自信もあります。

今後の課題としては、パフォーマンスの劣化の方が気になってきました。

[従来]
・パフォーマンスのネックは移動経路探索
 (経路探索が完了するまで待たされることが多い)

[改修]
・改善やデバッグが進んで部隊が常時動くようになる

[現在]
・モーション切替が短期間に頻発し、
 パフォーマンス劣化が激しくなった
 (乱戦中は5fps以下になることも)

Update()の所要時間は少ないので、ネックは(回避移動ではなく)モーション切替と思いますが、あまり良い解決策が浮かんできません。
(最終手段があることはありますが…)



◎進捗状況チェック

現在4カ月遅れです。年間スケジュールは次回見直します。



◎11月の目標

・活動時間月160時間以上

・年間スケジュール見直し(8h)

・部隊回避移動の調整(24h)

・陣形追加(8h)

・モデル個別移動の実装(24)

・モーション切替パフォーマンス向上(24h)

・戦闘モーションの作成(32)

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

HPも更新したいのですが、最近は技術ネタがありません。久々に企画ネタをやりたい気もしますが、余計な事する時間があるなら、その分開発を進めるべきなんでしょうねぇ…。



◎次回予告

次回は年間スケジュールを見直します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
回避移動06
開発中のメイン画面
拠点付近の不審な動きや、後方に移動するケースは低減されたらしい。しかしまだ課題が残るようだ。



◎課題

前回に引き続き部隊移動を修正します。現在気になる点は以下の通り。

・拠点付近に部隊が多数集結すると挙動不審な動きをする

・斜め後ろに回避移動することが多い

・稀に侵入不可地形に侵入することがある

・橋の位置で進行方向が逆の味方部隊と向き合うと、
 両部隊共に立ち往生してしまう

・パフォーマンスの低下が激しい



◎拠点付近の不審な動き

拠点付近に部隊が多数集結すると挙動不審な動きをします。原因を調べると、以下のようなプロセスになってました。

1 拠点の範囲内に部隊が移動すると一旦入城する

2 任務が異なる場合はすぐに出陣する

3 移動先に味方部隊が存在すると部隊は停止する

4 拠点の範囲内で停止すると一旦入城する(1へ)

というわけで、入城→出陣→移動→停止→入城→…のループに陥ったようです。

ちなみに、先行部隊が移動すれば解消されるので無現ループではなく、ゲーム進行に影響はありません。とは言え、見た目はとても不自然なので、やはり改善は必須です。



◎仕様変更

この現象を回避する手っ取り早い方法は『中継拠点に入城しないようにする(仕様変更)』でしょう。

そもそも中継拠点にわざわざ入城する必然性は無く、単に「部隊が拠点の上を素通りするのは不自然に見えるから」という理由なので、見た目がマシな方を選択します。

…改修しました。挙動不審の問題は解決しました。

「部隊が拠点の上を素通りするのはいいのか?」

微妙なところですが、他の課題と比べると優先順位はかなり低いので、検討は先送りします。



◎後方に回避移動する問題

後方(斜め後ろ)に回避移動する原因がわからず悩み続けてきましたが、もしかしたら、移動経路にスタート地点のセルの中心座標が含まれていることが原因かもしれません。

移動経路にスタート地点のセルの中心座標が含まれる

というわけで、移動経路からスタート地点のセルの中心座標を除きました。

…以前より初動がスムーズになった気がします。
それは良いのですが、後方への回避移動が減ったようには見えません。

その後、目的地への到着判定や方向転換等を修正したものの、現象変わらず。プログラム的な問題ではなく、仕様上の問題かもしれません。



◎後方に回避移動する理由

仕様とプログラムの動きを細かくトレースして、ようやく気付きました。

後方に回避移動するケース01A   後方に回避移動するケース01B

1 前方が味方部隊で進めないので、移動経路を左前に変更する(左図)

2 左前セルに向かおうとするが、前方セルは味方部隊で侵入不可と判定されるため、移動経路を左セル又は左後セルに変更する(右図)

部隊の角度によって回避先が変わったり、移動速度が早いと前方セルを通過する(左前セルに行く)こともあります。再現性がバラバラで掴みどころが無かったのですが、ようやく原因が判明しました。



◎対処案検討

原因が判明したので、対処案を検討します。

案A
・現座標のセル中央に移動してから、回避先に向かう
 →現座標のセル中央に向かうということは、
  後方に移動すること
 →現象は軽減されるが、解決にならない

案B
・回避要否判定を前倒しにする
(部隊がセル中央に居る段階で回避要否判定を行う)
 →同一セルに複数部隊が侵入するケースが多発しやすい
 →乱戦になると不都合が多い

案C
・左右セルに移動してから斜めセルに向かう
 →左右セルの中央座標は目指さないこととする
  (斜め後ろに移動してるように見せないため)

というわけで、案Cを採用します。図に描くとこんな感じです。

案Cの回避経路01   案Cの回避経路02

回避移動の方向が45度単位から90度単位になるので、リアルさは若干低下しますが、同一セルに複数部隊が侵入するケースを減らすことを優先します。

尚、完全包囲を目指すなら、右図の経路A又はBが必要です。従来は経路Aでしたが、90度単位になると後方移動に見えるので、経路Aを廃止して経路Bを新設します。



◎実装

実装すると、全体的に良くなったようですが、不可解な動きも発生しました。

例えば、回避移動後に停止したまま方向転換のみ繰り返すケース。回避移動関連をチェックしても異常は見当たらず、少々悩まされたのですが、原因は別の所にありました。

次の移動経路に到着したかチェックする箇所で、高度(3次元のY座標)を含めた距離で比較していたため、移動経路にセル中央から外れた座標を指定すると、微小な誤差で「次の目標座標に永久的に到着しない」状態となってました。

この箇所はとりあえず2次元でチェックするよう改修します。

回避移動06

・停止したまま方向転換のみ繰り返すケースは無くなった

・通常移動の渋滞で後方に移動するケースは無くなった

・乱戦時の右往左往率は従来より低下したが、後方に移動するケースがある

・侵入不可地形に侵入するケースが増えた

侵入不可地形に侵入するケースは、通常移動から戦闘状態に突入するケースだろうと予想したのですが、このケースは非戦闘状態でも発生するようです。うむむ…。



◎次回予告

11月になったので、次回は「10月の総括と11月の目標」です。

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

| BLOG TOP |

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