【Unity RTS】Bwars2 開発日記 #1

　みなさん、こんにちは。今日は次回リリース予定のバージョン0.7についてお話しましょう。0.6のリリースにより私はBwars２は開発上の一つの段階を達成したと考えています。0.6では地形・ユニットエディタを備え、間接兵器を除く陸海空のユニットの運用が可能になりました。荒削りながらも完成されたゲームが備えている基本的な機能をほぼ実装したプレイ可能なベータ版です。

　そのため私は次の開発に進むまえに、この機会に大規模なリファクタリングを実施してデバッグ機能を強化して0.7以降の開発がスムースに進むようにするべきだと感じました。リファクタリングは先日行い、名前空間とファイルの構成の整理によってプロジェクト全体の見通しがよくなりました。Bwars2ではロジック担当のメインシステムを基幹とし、ビジュアル担当のスキンがそれを監視して描画を行うことでメインシステムを修正すること無くスキンの交換によりゲームの見た目を変更することを目指しています。現状はメインシステムからスキンが情報を引き出す部分がやや複雑なのでここを整理すればリファクタリングは一旦完了と言えるでしょう。またこれまでの開発を通して必要と感じたデバッグ機能を実装していきます。現状のデバッグ機能は行きあたりばったりで偏屈なのでゴミ箱に破棄されるでしょう。サヨナラ！

　0.7では地形が強化される予定です。現状の0.6では高低差が大きな地形を作るとユニットの経路探索がうまくいきません。これはUnityのナビメッシュが急斜面では機能しないためです。そのため経路探索を改善する方法を考えてこの問題に対処することになるでしょう。これが完了したら山脈や渓谷などよりダイナミックな地形を扱えるようになります。

　また0.7では地形の描画が改善される予定です。１つはランドマークでこれはユーザーが作成した３Dの地物モデルを配置できるようになります。例えば東京タワーなどです。これはマップにフレーバーを加えるのに役立つでしょう。将来的には地形のスペックの上書き（例えば要塞を設置した場合）を行いますが、0.7ではひとまずゲーム上では特に影響を持たいない、純粋にアイキャンディとしてランドマークは実装される予定です。もう一つは電線です。地形上の構造物の種類は点（一本の大木など）、線（道路など）、そして面（市街地など）に分類できます。そのうち点はランドマークが担うとして、面はすでに市街地や森林を実装しているので達成されています。私は線は地形にフレーバーを与えるのになかなか重要だと感じています。道路がすでに実装されていますがさらに電線を加えることでよりリアリティーが増すでしょう。戦場となる地形は市街化していない場所が多いので電線は相性がいいとも言えます。そうしたわけで0.7ではより魅力的なマップが提供されるでしょう。（おわり）

【Unity】RTS Bwars2 β ver 0.6.0リリース

Bwars２ベータ版ver0.6.0を公開しました。

ダウンロードはポータルサイトから

前回からの変更点
・地形タイプに水面を追加
・水上ユニット追加
・地形による移動制約
・マップの追加
・マップエディタの追加
・UIの大きさを設定する機能
・マニュアル更新：遊び方のページ以下に、「メニュー」「マップエディタ」「設定項目」を追加
・視点操作の改善

【Unity】RTS Bwars2 β４公開

Bwars２ベータ版ver.4を公開しました。

ダウンロードはポータルサイトから

前回からの更新点
・セクターの廃止。ユニットはどこでも戦えるようになった。
・道路とファストムーブの実装。Fキー＋左クリックでユニットは道路上を高速移動します。
・勝利条件の追加。ユニットを失うごとに減っていくスコアが０になったほうが負け。
ポータルサイトの「遊び方」に加筆しています。

【Unity】RTS Bwars2 至近の課題

Bwars2開発にはやるべきことがたくさんあるが、至近のやることは３つある。それは射撃処理の洗練化、地物の生成、道路だ。

射撃処理の洗練

射撃は今は１つの砲弾ごとに命中・ダメージ判定を行っているが、高レートで連射した場合処理負荷が集中する可能性がある。例えばシルカ対空戦車は機銃を４門装備し一斉に射撃すると毎分数千発を射撃することになり、１秒あたり５０発以上を発射する。これ１発１発について命中を判定しダメージを適用するのはあまり賢くなさそうだ。そのためある程度ゴマカシが必要になる。

そこで一定時間内に発射される砲弾をまとめて１つの砲弾として扱う。（まだ手法は考えていないけど）処理を一括して行うことで負荷の軽減が見込める。　この方法は弾の着弾地点が１箇所になる欠点がある。つまりきちんと１発ずつ計算していいれば複数弾の着弾地点はバラけ、様々な場所のユニットにダメージを与える可能性があるがこの方法では範囲が限られてしまう（その分範囲内のユニットには複数弾の合計されたダメージが入る）。そのためあまり多くの砲弾をまとめるべきではない。一方で簡略化は避け得ないのでやむを得ない方法だ。

また砲弾の処理に用いる入力パラメータを使い回すことでも処理を軽減できる。厳密に言うと敵味方のユニットが移動している場合、距離などのパラメータは刻一刻変化するので砲弾の発砲ごとに最新のパラメータを入力して命中判定などを行うのが望ましい。しかしパラメータの変更は計算のやり直しを招く（判定のしきい値がその都度再計算必要になる）。そのためある程度の時間内は同じパラメータを続けて使用するようにする。もちろん時間が経過することに状況は変化するのでなるたけ短時間の使用が望ましい。この同じパラメータを利用する連射を同一射撃と言うことにしよう。同一射撃時間は例えば１秒とする。この場合１秒の間はたとえ目標が破壊されたりロストしてもとにかく同じパラメータを利用して撃ち続ける。そして射撃開始から１秒後まだ目標が有効であり、かつリロードなどもクリアしていれば最新のパラメータを取り込み再び１秒撃ち続ける（パラメータは別のゲームループで更新されているので前回と同じ場合もありうる）。この場合見た目上はひたすら計算を行い連射しているように見えるが実際には１秒毎に計算が行われていることになる。同一射撃時間はそのままクールダウン時間となり、射撃開始後、同一射撃時間内は新たな発砲はできない。

以上２つの方法を用いる場合、射撃レートごとに以下のように利用することになる。

・高レート
同一射撃を開始する。例えば１００発を同一射撃時間内に発砲するとしよう。それを２５発ごとに１つの砲弾として同じパラメータを使って処理を行う

・低レート
同一射撃を開始する。４発を同一射撃時間内に発砲するとして、個々の砲弾ごとに同じパラメータを使って判定を行う。

・単発
戦車砲など毎分１０発前後の場合は同一射撃終了後、リロードを挟んで再度射撃を行うことになる。

こうした処理を行うために、射撃制御クラスを作る。各ユニットの武器クラスは同一射撃時にパラメータを制御クラスに渡しあとはお任せすることになる。

地物の生成

今は地形の特性はテクスチャに描かれた図形で表現されているが、やはり立体のほうがいい。ただしBwarsは低スペック・旧PCにも対応したいのでGPUをブン回して描写を行うことは避けたく、またユーザーが手軽にmodを作れることを目指しており、加えて基本的には遠くから俯瞰しながらプレイするゲームであることから地物はとても簡略した描写に抑えたい。市街地や森ではたくさんの建物や木を並べて高密度さを表現したいがGPUインスタンシングでも数が多いと負荷は馬鹿にならない。そこでこうした高密度オブジェクトは連続したポリゴンを生成し描くようにする。これはGoogle Mapの３Dと同じような感じになる。郊外や茂みなど低密度な地域は一つ一つ地物描くようにする。ポリゴンの生成とLOD処理が課題になる。また地物ポリゴンが省略された場合でも自然に見えるマップテクスチャの生成も必要だ。

道路

個人的には道がないテラインは梅干しがない白米みたいだと思っていて、道路の実装は必須だ。道路はノードで定義され、各ノードは座標と接続ノードの情報を持っている。課題がいくつかある。１つは道路のノードの編集で、エディターなどを整備しないといけない。また実際にノードから地形に沿って目に見える道路を生成する必要がある。これには橋やトンネルも含まれる。最後に道路を全体の経路探索に組み込み、ユニットが道路に対応し道路上を移動できるようにしなければならない。課題は多いがRTSゲームではコンプレックスな道路の実装は少なく（せいぜい川に橋がかかるだけ、都市系シムと比べると特に見劣る）、実装できればマップの表現や戦術に新しい光を当たることができるだろう。

【Unity】RTS Bwars2 ベータ版ver3 公開

ベータ版３を公開しました。

https://sites.google.com/view/bwars2/%E3%83%9B%E3%83%BC%E3%83%A0/%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AD%E3%83%BC%E3%83%89

・士気の実装。士気はユニットアイコンの枠線で示され、低下するとユニットが逃亡する。
・アタックムーブの実装。Qキー＋左クリックでユニットは移動を行い、途中攻撃範囲に敵が入ると停止する。
・AOE（範囲ダメージ）の実装。いくつかの攻撃は着弾地点周辺のユニットにもダメージ・士気の低下を及ぼす。
・新ユニット特殊部隊追加。３つの武装を持ち、内グレネードランチャーは士気を低下させる効果が大きい

【Unity】RTS Bwars2 ベータ版ver2 公開

ベータ版ver２を公開しました。

https://sites.google.com/view/bwars2/%E3%83%9B%E3%83%BC%E3%83%A0

・視界システム・戦場の霧を実装

・地形による遮蔽：射線や視界は地形で制限される

・新しいユニットスペック

【Unity】RTS Bwars2 ユニットパラメータの刷新

嫌で仕方がなかったユニットのパラメータの仕組みを刷新した。攻撃力や移動速度などユニットのパラメータはJSONで指定できるが、以前からあまりいい設計と感じていなかったので変える必要があった。今回の変更で例えば攻撃力はターゲットの防御属性の種類の数の分存在することになった。別の例では射程距離と命中率も回避属性分存在（車両とか飛行機とか）する。この変更をしたくなかったのは設定読み込み処理の加えて火器管制AIや対戦AIなど広範囲な修正が必要だったからだ。しかし避け得ないことだった。

また数時間を費やして汎用的で視覚的なデバッガも改良して以前よりゲームの状態を掴めやすくした。上の写真ではAIが適切と考えるユニットの配置場所が立方体の大きさで示されている。

【Unity】RTSゲーム Bwars2 エフェクトやユニット購入やAI

ささやかなエフェクト―砲火や爆発―を追加した。自分同様慎ましいので誰も気づかないかもしれない。
　セクターから収入が得られるようにして、一定時間ごとに資金に加算されて購入したユニットが戦場に現れる。上の写真でも購入用のUIやセクターごとの情報を表示するUIを確認できる。これは試み的な工夫の一つで比較的長い間隔による更新でRTSにありがちな刻々増える資金に常に注意を払いお金が貯まるやいなや購入コマンドを押す操作を軽減する目的がある。初心者にとって戦場で戦闘の指揮を行いつつ随時ユニットを追加する操作は難しい。この仕組なら一定時間内の好きなときに資金を確認し必要ならユニットを購入することができる。購入実装に伴いAIもユニットが購入できるようにした。
　戦力をセクターに分配するアルゴリズムを新しい理屈に基づいて改善した。セクターへの戦力分配は大まかにセクターの重要度と危険度で決定される。重要度はセクターからの収入や生産施設の有無で変化する。危険度はステップ数に基づくセクター間の経路探索を実装したことで敵セクターまでに経由するセクターとステップ数を調べることが可能になったので、例えば敵セクターとの間に味方セクターを挟む場合は危険度を低下させることができるようになった。実はこれまでセクターの重要度などは与えていたが、これでAIが動的にセクターの価値を測定し戦力を決定できるようになった。
　火器管制システムをGame空間に移管させた。話すと長いしつまらないのでこれは省こう。
　ユニットに属性を設定することを考えている。例えば回避率は戦車であれ装甲車であれ地形別の変化量は同じ傾向になると仮定することができる。そこでこれを属性とすることで各ユニットでは基本回避率と属性を指定するだけで手軽に各地形での回避率を設定することができるだろう。

* エフェクトの強化
    * 火器管制システム
    * セクターUI強化
    * セクター兵站制限によるペナルティ
    * ユニットの生産
    * --------------↑やった↑------------------
    * AI改善
        * セクター戦力分配
        * 地形の効果的な利用
    * ユニット駒モデル
    * LOD
    * 操作性の改善
        * UIの改善
            * ユニット選択
            * ユニット購入
    * ゲームスタート・終了機能
    * アルファ版
    * 経路探索
    * 地形の立体化
    * 射線・視界の判定
    * AIの改善
    * ベータ版
    * 間接・範囲攻撃
    * シナリオイベント

マップを大きくしたら木を描画しきれなくなたのでLODを実装する必要がある。
うまくすれば来年の１月にα版を公開できる。

【Unity】RTS Bwars2 くっつくUI

以前からユニット同士が近いとUIが重なってしまっていて気になっていたので直すことにした。UIが重なっているのか判定する必要があるので四分木とモートン順序を利用して空間分割のアルゴリズムを実装して千コ矩形を置いて重なった矩形を赤く染めて（上の写真）ヤッタヤッタと喜んでいたがUIの整列にはもうひと工夫必要だった。結局重なったUIでグループを作って並べるようにした（下の写真）。

　その仕組み上グループに属して再配置されたUIと一匹狼のUIや他のグループUIは重なってしまうがたぶん問題ない（ほんとかな？）。UIも再デザインした。こうして見るとWargameの横長のUIはうまく出来ているなと思う。ユニット名が長くても表示できるし、プレイされることが多い横長モニタと相性がいい。まねっこになるからまねしないけども。AIも改良し以前に比べ大幅に良くなった。引き続きUIの実装に努める。

【Unity】RTS Bwars2 UIの実装の続き

多少UIのデザインを考えたのでUIの実装をしている。その一環で地形上のセクターの境界に線を引くように改良した。またいくつかユニットの種類も増やした。ユニットの追加はユニットを３Dモデルからイメージに変えたので、もともと動的にデータからユニットを生成する仕組みと相まって比較的容易だ。一方でどうしても３Dモデルの臨場に比べると迫力の無さは否めない。ユニットのイメージは描く予定でいま絵を練習している。この後もう少しUIの実装に努めたところで再度AIの改善に戻るだろう。その前にはユニットや地形などもろもろの設定を一度きちんと決めてやる必要がある。その情報を使ってAIがもう少しマシな判断が下せるように助けるようにしよう。

【Unity】RTS Bwars2 地形とUIの実装の開始

前回行っていたクラスの再編成が完了した。クラス大きく分けてゲームの運用を行うGame空間とゲームの情報から戦術判断を下し命令するAI空間に二分された。両空間は疎結合でAI空間からGame空間に指示を出してユニットを動かすことに成功した。上の写真はAIが指示したユニットの移動先や敵ユニットの予想位置を赤青のシンボルで示している。

　これで一応ゲームは動くので外見上の改善に手を付け始めた。ひとまず旧プロジェクトから回収したコードを使ってマップに木を生やした（同じく上の写真）。次にユニットのシンボルを実装しようと思う。下の写真はイラレで作成したデザインの案だ。

ユニットのシンボルは距離によって変更する予定だ。より近づくとシンボルから具体的な絵や写真に変わる。ひとまず遠目から見たUIを実装して満足しよう。

【Unity】RTSゲーム Bwars2 クラス再編成

戦術AIがユニットの配置とセクターの制御点の占領ができるようになった。これで（一応）ゲームが可能になった。そこでこの機会に現状のクラスを再編成しゲーム運営部分とAIの完全な分離を目指し始めた。クラスは名前空間Game, Agent, AIのいずれかに所属するようになる。Gameはユニットの移動や攻撃の命中判定などゲーム全般の運営を行う。AgentはGame空間からユニットの位置などAIの判断に必要な情報を吸い出してAI空間に渡す。AIは受け取った情報を元に決定を下し、Agent空間に決定事項を伝達する。Agentはその内容をGame空間に命令する。GameとAIの間にAgentをかませるのは将来的にAIは外部アプリケーションに任せてBwarsから完全に独立させようとしているからだ。こうすることで誰でも彼でもAIのカスタマイズが可能になる。この再編成は最高に面倒な作業だ。

【Unity】RTSゲーム Bwars2 戦術AIの実装

　前回各セクターにユニットが配られるようになったのでセクターごとに与えられたユニットに指示を出す戦術AIの実装を始めた。戦術AIは与えられたユニットを効果的に利用し戦闘を有利に進めなければならない。戦術AIの仕事は究極的には１つしかない―ユニットに任意の場所への移動命令を出すことだ。そのためおおまかに２つの演算を行う。１つ目は敵ユニットの位置の予測で、２つ目はその位置に対する効果的な味方の配置場所を計算することだ。１つ目については隣り合うセクターの支配権や実際に確認されている敵に応じて候補地（理想的にはセクター全域が対象となるが演算コストの理由から相当間引いている）にスコアを与えスコアの高い順から敵予想値位置とする。２つ目は味方ユニットの現在位置と移動速度、敵味方の攻撃範囲の内外などの要素から同じくスコアにより移動先位置を決定する。上の写真では敵の予想位置に球体が置かれている。決して現状精度が高いものではない。しかしプロセスは正しいと感じている。ゲームの他の部分との開発と二人三脚でAIもよりましなものに変わっていくだろう。

【Unity】 RTS : Bwars2 ユニットをセクターに送り込む

　前回AIがセクターごとに戦力の配分を決定できるようにしたので、その戦力配分に従い管理するユニットを実際に各セクターに派遣できるようにした。セクター無担当のユニットからセクターが割り当てられていく。戦力配分は随時更新されるので戦力要求に対して過剰なユニットを抱えるセクターはユニットを「クビ」にする。クビになったユニットは別のセクターが割り当てられてそこに向かう（Bwasは優しい世界なのだ）。敵が担当セクターにいる場合は当然戦闘になる。いまのところユニットはセクターの制御点を目指すので戦術も何もないが、これでセクターの奪い合いができるようになった。上の写真は同じセクターで鉢合わせした敵味方のユニットの戦闘の様子を示している。

　上の写真を載せててアレだが、ユニットは３Dモデルでなく絵（シンボル）にしようと考えている。モデルを作るのは大変な手間で１つのモデルを作る間に同じクオリティの絵が１０枚はできる。加えてモデルは戦闘時の効果の設定（例えばモデルのどの部位から砲火が生成されるかなど）やアニメーションまで含めると大変厄介だ。もちろんモデルを使用した場合の臨場感・迫力は素晴らしい。でも個人のリソースでは市販のゲームには敵いっこないのだ。また今回はmodの利用を前提にしている。Rimworldなどのmodを見て思ったのはちょいちょいと絵を描いてちょいちょいとxmlを書いてできるような手軽さが理想的と感じた。モデルを利用した場合作るのも読み込む仕組みを作るのもとても手間がかかってしまう。シンボルのデザインはまだ考えていないが多分カメラの距離の応じてシンボルや兵種の表記が変わるようになるだろう。

　現状ではセクターごとの戦力の配分しか決められないので各セクターごとに戦術AIが思考し担当セクターに与えられたユニットを効果的に使えるようにする必要がある。ここはいま仕組みを考えているところだ。話はそれるが考えを練るときにMacではOmni Outlinerを愛用していたがWindowsでは気にいるものが見つからなくて諦めていた。しかしあらためて探したところUV Outlinerという良さそうなソフトが見つかり最近利用し始めた。とても使いやすいソフトだ。

【Unity】RTS Bwars 2 : セクターごとの戦力の割当

戦場を区切るセクターごとにどの程度の戦力を割り当てたらいいか計算する仕組みを実装した。ここでの戦力とはユニットのコストのことでコストが高いユニットほど強いという前提に立っている。この戦力の割当に応じて全体を管理する戦略AIが管理下のユニットの担当セクターを決めていく。さらにセクターごとの戦術AIが割り当てられたユニットをうまくつかってなんとかする。

戦力の割当は大まかにまず当該セクターとその隣接するセクターの支配陣営を調べて安全度を算定し戦力を分配する。そのうえで更にセクターごとの彼我の現在の戦力に応じて調整を行う。この調整についてはデバッガーを作成し、テストデータを入力・保存できるようにした。特に保存は重要で似たようなテストを繰り返すのでそのたびにいちから入力していると大変な手間になる。

戦力の割当に基づくユニットの担当セクターの割り当てはデリケートな問題だがひとまず要求戦力に比して現有戦力が少ないセクターは近い無担当ユニットから割り当てられていくように今実装している。

新規まき直しからの目標である制御系と操作系の明確な分離の原則に従いAIが処理で必要な情報は直接ユニットやセクターのクラスに書き込まず、別途完全に独立したクラスで管理するようにしている。

【Unity】RTS : Bwars 2 ゲームループ

　

死んだ戦車が黒色になっている

セクターを実装し、データファイルから生成されたセクターの制御点にユニットを置くとセクターを占領できるようにした。まだ効果はないが産出するスコアや補給量の指定もできるようになっている。またデバッガークラスを開発して様々なクラスから気軽にギズモやテキストを表示できるようにした。これは今後の開発に役立つだろう。
　

セクターごとの制御点の有効範囲が赤の円で示されている

　ゲームループ（ゲーム中に実行される定期的な処理）は３つに落ち着きそうだ。一つ目はごくごく普通のUnityの毎フレーム呼ばれるUpdateでここでユニットの移動や砲塔の回転などを行う。二つ目は１秒毎に実行される処理でセクターの占領状況やスコアの更新を行う。最後が不定期な処理でここでは全ユニットのステータス更新・索敵の実行とその最新の状況を分析したAIによる指揮処理を行う。不定期なのはAIの処理が終わるのを待って次の更新を行うからだ。このAIの処理は別スレッドで実行している。今のところパッシブな役割の火器管制AIのみだが、これに能動的にユニットを動かすいわゆるゲームAIが加わるので処理時間は長くなるだろうがそれでも１秒以内には収めたい。

【Unity】RTS : Bwars2 ゲームのルール

　地形やセクターの生成ができるようになったので、今はユニットの性能を基本の値から上下させるブーストシステムを作っている。このブーストの例としてはあるセクター内のユニットの移動速度が上昇したり、特殊ユニットの近くにいるユニットの武器の命中率が上昇することなどが挙げられる。ブーストは基本的にある条件を満たす場合のみ適用され、条件が満たされなくなると効果は取り除かれる一過性のものだ。これはなかなか難しいもので旧プロジェクトでも実装時にあれこれ考えたことがある。上の例に沿うとあるユニットがあるセクターに入ったときに速度を上昇させ、出ていったときにその上昇分の速度を取り除く必要がある。そこで今回はブーストのチケットを発行し、適用対象のユニットに渡して以後条件が満たされ続ける限り同じチケットをユニットに渡し続ける仕組みを考えた。ユニットの方としてはチケットを初回に受け取ったときにブースト効果を適用するとともにチケットを保存し、以後同じチケットが来る限りなにもしない。チケットが来なくなったら保存していたチケットの効果を取り除きチケットも破棄する。この仕組によって後に書くようなセクターやヒーローによるブースト効果の仕様を実現しようと考えている。

　前回のプロジェクトが破綻した理由の一つは制御系と操作系のプログラムがくっついてしまったことだが、他にも大きな要因としてゲームのルール・方向性が決めきれなかったことがある。今回いろいろ考えて、新しく以下のような仕組みで行こうと考えている。

セクター
セクターは戦場を複数のエリアに区分けられたもので戦場のあらゆる地点はどれかのセクターに属している。セクターでは補給物資が産出されるが、あまりの多くのユニットを１つのセクターに配置すると補給物資を食い尽くしてしまい、ユニットは行動にペナルティを受ける。１つのセクターは１つのコントロールポイントを持つ。コントロールポイントにユニットを移動させることでセクターを占領でき補給や戦闘などでセクター内の友軍ユニットがメリットを受けることができる。

エース
前プロジェクトでは指揮官は複数のユニットを管理する立場としたが、今回は１ユニットを指揮するエースとしての立場を考えている。位置づけとしてはWarcraftのようなヒーローユニットのように自身の戦闘や周囲のユニットになにかしらのブーストを与える。ユニット自体をエースとしてもいいが、キャンペーンを想定した場合ユニットの技術ツリーなどを考えないといけなくなるので、あくまであるタイプのユニットに搭乗（指揮）できる独立した個人を考えている。例えば第２次大戦でティーガー重戦車で多くの戦果を上げた戦車乗りオットー・カリウスを考えたら分かりやすいだろう。

勝利条件
勝利条件はいくつか設定できる。代表的なものはスコアでユニットの撃破やセクターの占領維持で得られるスコアで相手を上回ると勝利となる。他には特定セクターの占領や特定ユニットの撃破が条件になる。勝利条件がスコアのみ場合は様々な方法でスコアが稼げるのでいろいろな方法で勝利が狙えるようになるだろう。

【Unity】RTS:Bwars2 外部からの火器管制

動的にユニットと地形を生成し、移動・戦闘が出来るようにした。今回のプロジェクトの一番重要な目標はコアとなるクラス群は必要最小限のゲーム進行しか担当しないということにある。これは地形の生成においては地形データを画像を始めとするデータを与えることで仕組みで叶えている。上の写真は予め準備した画像を与えて地形を生成させた結果を示している。コアクラス群において地形のデータ自体を生成することはない。ユニットの生成についても前回の投稿の通りJSONデータにより生成しているがここで少し詰まった。当初、最初にユニットの雛形を作成し、ユニットが必要になった時点で雛形をInstantiateしてユニットを複製する仕組みを作った。ユニットの基本性能値はユニットの種類ごとにおいて共通だから別途MonoBehaviourを継承しない普通のクラスで性能値を定義し、個々のユニットを管理するクラスに紐付けることで個々のユニットの性能を定義しようとした。しかしInstantiateはコンポネントしか複製しないようで、雛形でユニットの管理クラスに紐付けていたはずの性能定義クラスはそのユニットの複製品ではリンクが切れていた。仕方がないので複製後に性能定義クラスを紐付けることにした。

　今回コアクラス群では最低限のことしかしないのでユニットのどの武器を使ってどの敵を攻撃するかは別途命令してやる必要がある。ユニットの管理クラスは攻撃面においてはユニットが所持する武器と補足した敵の情報を与えるメソッドと個々の武器に攻撃目標を割り当てるメソッドを提供しており、これを利用して攻撃の指示を出すことが出来る。本プロジェクトでは必要な情報を提供し、命令を受け取る機能を用意すればコアの外部からでも十分操作可能であるはず、という考えを採っている。そこで攻撃範囲に入った敵を攻撃するというパッシブな外部AIを作成してうまく動作させることが出来た。これは前のプロジェクトではユニット管理クラスに内蔵されていた機能で、このために操作と処理の機能が混ぜ合わさりどうにもできなくなっていたが、本プロジェクトではそれを分離し操作は外部からすべて行うことで解決しようとしている。この火器管制AIの成功は本プロジェクトの指針が正しいこと示しているように思える。

【Unity】RTS: Bwars2 新しいプロジェクト

　Bwarsの開発は以前は力強く、いまもよちよちと続いている。いい知らせもある。以前のプロジェクト「バターチョコレート」に変わって新たに「レッドパイ」プロジェクトが始動した。バターチョコレートの膨大なコードはいっさい捨て去られ、レッドパイの綺麗な鼻がカーテンから突き出ている。―つまり、いちからBwarsを作り直している。

　バターチョコレートの死は避けられなかった。ユニットの制御系スクリプトとそれに指示を出す操作系スクリプトがぜんざいの餅と小豆のように融合して分離は不可能だった。シナリオの演出は出来ない。動的にユニットを組み立てる仕組みも貧弱でユニットの追加には対応できそうにもなかった。

　レッドパイはこうしたことへの反省をもとに制御系と操作系を明確に分離している。制御系への指示は特定のプロトコルで窓口を通さないとできない。バターチョコレートでは制御系のスイッチをオンにすると魂がないのにさまようお化けのようにユニットが動いていたがレッドパイではオンにしても明確に指示しない限り指一本動かない。ユニットも動的に組み立てる仕組みを最初から前提として組み込んでいる。下の写真はJSON設計データをもとにメッシュだけのゲームオブジェクトにスクリプトを適切に貼り付けてユニットになった戦車を示している。

【Unity】RTS:Bwars 2 戦術ヘクス

　ボードゲームではおなじみのヘクス（六角形）の仕組みを導入することにした。ヘクスはルート検索やユニットの影響力の評価に使われる、地形上の最小単位となる。これを戦術ヘクスと呼ぶ。ただしAIの処理の関係上より大雑把な戦況の評価に用いるには戦術ヘクスは小さすぎるので戦術ヘクスを集めたより大きな統合戦術ヘクスも実装した。マップ全体を区分けするゾーンはヘクスの導入以前に作っていたものでヘクスとは関係がないので両者を関係づけるのに相当苦労した。上の写真では２つのゾーンにまたがる戦闘が発生し、戦闘地域に指定された統合戦術ヘクスが表示されている。この戦闘地域内の統合戦術ヘクスに属する戦術ヘクスのなかでのみユニットは展開・移動ができる。基本的には戦闘グループのAIが管理下のユニットに統合戦術ヘクスへの移動を指示して、各ユニットのAIが指定の統合戦術ヘクス内のどこの戦術ヘクスに移動するか決める仕組みにする予定だ。