このあたりを見ながらほそゞゝとAIが判断材料とする戦況マップを実験している。青丸と赤丸が部隊の位置で距離に応じて影響度が低下する。黒い部分は両軍の影響力が拮抗しているか、ない場所を示している。基本的に黒い戦線が遠ければ進軍する…という方法がとれそう…と考えている。
2016年3月23日水曜日
2016年3月12日土曜日
【Unity】RTS:AI
引き続きAIを作っている。撤退したユニットが司令部近くで回復できるようにしたのでAI同士の軍勢が押し合いへし合いするようになり見ていて面白くなった。 近い目標地点には微速で移動しながら回転したり、退却時の移動を最適化。ここに来てこつこつ作っていたユティリティクラスが役に立ち始めた。例えば指定地点まで移動するのにかかる時間を返す関数は複数の移動先の選択肢から最適なものを選んだりするのに幅広く役立っている(単に距離をスピードで割っているだけだが)。他にもある地点は何時方向になるだの、何時方向にいくら移動した地点はどこだのといったことを調べる関数が役立っている。戦術的に正しい動きを実装する上でストレスなくアイディアを表現できるのは嬉しい。
当然といえば当然だが、機能と思考を徹底的に分離して実装することが大切だと常々感じるようになった。例えばシャーシクラスはユニットの移動を担当するが、あくまで目標地点まで円滑に移動するだけの機能しかない。ユニットがダメージを負って退却するのを命令するのはユニットAIクラスだ。またシャーシクラスには近隣の味方を発見して回避する関数があるが、自身で発火させることはない。これもユニットAIクラスが適切なタイミンで発火させる。もし自動で回避するようにしていたら敵前で横っ腹を向けるような運動をしかねないからだ。このように各機能はあくまで命令を与えられた時のみ稼働して最適な方法で目標を達成することにとどめ、一つの思考をもったクラスで各機能を集中管理・使用するのが望ましい。
2016年3月8日火曜日
【Unity】RTS:AI
Behavior Designerを使ってビヘイビアツリーによるAIの実装を始めた。AIは指揮官AIとユニットAIに分かれている。まずユニットAIでステータスのリセット、ヒットポイントや攻撃してくる敵の火力などの状況に基づいたステータスの更新を行う。次に指揮官AIでユニットAIのステータスを確認した上で戦術の基本方針―攻撃・防御・撤退―を決定する。最後にユニットAIが指揮官AIの決めた戦術に従って行動を起こす。これを1ルーチンとして定期的に実行される。今日で一応AI対AIの戦闘ができるようになった。上の写真ではブルー国とレッド国がそれぞれのAIに従って戦っている。ときどきフシギな振る舞いが観察される。
ツリーのデザインはオンラインでチャートを作成できるCacooを使って先週の金曜に設計した。指揮官AIは指揮下のユニットを幾つかのチームに分けて運用することができる予定であり、今後はチーム運用の機能を実装していく。
2016年3月3日木曜日
【Unity】RTS:AIとナビメッシュ
AIは現在のところユニットに搭載され索敵の評価や退避などを行うユニットAIとユニットの集合体を指揮する指揮官AIの二つがある。AIにはビヘイビアツリーを利用する予定だ。少し変わっているのはプレーヤーの操作するユニットにもAIがあることで、これは実際にユニットを動かすことはないが、敵味方のAI同士が交信してより的確な戦術決定を下す助けになることを狙っている。これは別にプレーヤーが不利になるということではない。このゲームには戦場の霧はないし、あったとしてもその場合はAIが共有する情報に適切な制限をかければいいだけだ。
2016年2月24日水曜日
【Unity】火器管制装置
ここ数日はずっと煩瑣なユティリティのメソッドを作っていた(地点Aから地点Bを0時として指定時間方角で地点Aから指定距離離れた座標を返すとか)が、今日は思い切って火器管制装置を改修した。
各タレットは使用する弾薬の威力と砲の発射速度から対装甲種ごとに分間攻撃力(DPM)を算出し、火器管制装置がこれを集計する。これがそのユニットの火力の評価となる。
レーダークラスは探知距離内に確認された敵情報を火器管制装置に渡す。火器管制装置は与えられた敵をまず攻撃優先度でソートして、ついで管制下のタレットに目標として割り振る。優先度を測るために敵の火力から脅威度を評価する。まずこちらを射程に収めてかつ火力の高い敵が上位を占めて距離が離れるごとに優先度が下がっていく。優先度が決まると今度はその敵の装甲種を確認して最も効果的なダメージを与えれるタレットに攻撃目標を割り当てる。割り当てるに際してはタレットがまだ目標を指定されず、目標を射程に収め、ダメージを与えられるか判断される。目標がタレット数を下回る場合は一番優先度が高い目標に複数のタレットが割り当てられる。
上の写真の例では右端のレッド国のタレットが3つある(!)戦車が左二つのブルー国と戦闘をしている。レッド戦車のタレットの向きから優先度の高い至近のブルー戦車にタレットを二つ、もう一つのブルー戦車に一つを割り当てていることが分かる。この火器管制装置は(処理が許す限りは)戦車のような火砲が数個のユニットから戦艦のような数十の火砲を持つユニットを一律に制御ができる。とてもいい話に聞こえるが、もちろん、ネックは処理負荷だ。
しばらくこれで火器管制装置はほっぽくが今後の改善としてはタレットから目標に火線が通るかの確認、角度が限定されたタレットへの対応、ユニットのダメージに応じた優先度決定ロジックの選択、また攻撃対象への攻撃予約の確認が考えられる。攻撃予約とは攻撃が決まったユニットに対して予想される与ダメージ量を伝達することで味方ユニットの火力が過度に一つの目標に集中することを防止するアイディアだ。この場合、責任交戦距離の短いユニットからチェックを行うべきだろう。そうすれば至近の敵歩兵に対しては味方歩兵が対応し、戦車は(敵歩兵にすでに十分な攻撃量が予約されているので)より重要度の高い目標を攻撃することができる。
2016年2月9日火曜日
【Unity】砲弾工場
前から(ずっと前から)実装しようと思っていた、キャッシュした砲弾を使う仕組みを作った。これで一度作った砲弾を使いまわせるようになった。全体を統括する委員会クラスの管理下に砲弾工場が作られてここで初期化時に適当な数の砲弾が直ちに生産される。砲弾は倉庫に保管される。一方でタレットは砲弾を発射するタイミングで工場に発注をかけて、それを受けて工場は砲弾を倉庫から取り出してタレットに渡す。砲弾は種類ごとに動的にプロダクトIDが割り当てられてそれが発注番号となる。砲弾はどこかに衝突すると工場に送られてきれいに洗浄された後また倉庫に保管されるという環境負荷が小さなシステムだ。下の写真では飛び交っている砲弾がアクティブになっていて保管されている砲弾は眠っている。
基本的にはユニットの情報を集中管理するという考え方は間違ってないと思う。ただユニットの数が増えると索敵のコストも高くなるので最適化が必要になるだろう。
Labels:
Unity
2016年2月2日火曜日
【Unity】キングオブザヒル
前回のビヘイビアツリーがうまくいったので、戦車を作ってAIとして搭載してみた。戦車といってもキューブのシャーシの上に小さなキューブの砲塔が載っているだけの代物だが。戦車は次のようなスクリプトを積んでいる。
シャーシ。指定された場所に移動する。
タレット。指定された目標に指向し弾丸を発射する。
ファイアーコントロール。初期化時に全タレットを登録する。攻撃目標をスキャンしてタレットに攻撃させる。
ヒットポイント。ダメージを管理してHPが0になると破壊する。
IFF。敵味方を指定する。
それにAIを積んでいる。AIは前回作ったニパ・ビヘイビアツリーを使った。このAIはシャーシ・ファイアーコントロール・ヒットポイントと連絡して状況を把握して命令を下す。この戦車を使って単純なキングオブザヒルのゲームを作った。青赤両軍はそれぞれ補給所(HPが回復)を持ち、中央にある党の占領を目指す。AIはまず戦車のHPをチェックして半分以下なら補給所に向かう。次に塔から離れていたら塔に向かう。その次に敵がいたら追い回す。最後にアイドル状態になる。両軍にこの戦車を配備してゲームを開始すると上の写真のようになる。
もし戦車に5つの砲塔を搭載したらどうなるだろうか?
圧倒的火力!しかしまだ偏差射撃が出来ない上ファイアーコントロールは一度に一つの目標しか捕捉できないのでタレットに複数の目標を振り分けることが出来ない。残念!
Labels:
Unity
登録:
投稿 (Atom)













