【Unity】RTS:かんたいプロジェクト 砲弾

砲弾がまともに機能するようにした。目標に当たると距離に応じてダメージを与える。徹甲弾扱いなので影響を与える範囲は砲弾の進行方向になる。実際の仕組みはとても単純。

のらりくらりしてると流産しそうなので、７月末までに無理やりゲームを完成させることにした。

【Unity】RTS:かんたいプロジェクト 土台

立方体の土台の上に設置された砲塔

モジュールに「土台」を追加した。普通、砲塔などのモジュール類は船体にめり込ませないといけないが、土台の上に設置するとその条件を免れる。土台の上に土台を載せることもでき、今のところ重心の概念はないのでいくらでも積み重ねることができる…
　
　船の設計データはCSV（！）で読み書きしていたが、これをJSONに転換しようとしている。そこで設計担当のクラスとデータ読み書きのクラスの間にアダプターをかませて転換準備をした。DLLを利用したらあっという間にJSONでの読み書きが可能になった。

【Unity】RTS:かんたいプロジェクト AIと目標選択

　目標補足後に距離と砲塔の指向角度によって重みを計算して、選定に役立てるようにした。AnimationCurveを利用して最大索敵範囲に対する目標までの距離の割合などから重みを計算する。以前にもあったけど改良した（今後もっと調整が必要になるだろう！）

　またAIは船の操舵についてランダムに目標周辺を目指すモードと目標の船の進路方向をトレースするモードを切り替えるようにした。これによってより「生き生きとした」動きができるようになっている。ただし相変わらず衝突回避は出来ないので時々目標に突っ込む。

　今後はもう一度造船に戻って船の設計の機能を高める。

【Unity】RTS：かんたいプロジェクト AIの開発

プレーヤーの船（奥）を不器用に追跡するコンピュータの船（手前）

前回からだいぶ時間が経ってしまったので何を作っていたのか忘れてしまった。プロジェクトファイルがまるで古文書のようだ。考古学者並みの丹念さで自分のプログラムを読み解くことに成功した。（どうやら昔の僕はAIを作りたかったようだ…。）
　
　そこでコンピュータ側の船を操縦するAIを作った。このAIは一見考えて動いているように見えるが実は何も考えてない。単にプレーヤーの船の周りに配置された見えないビーコンをランダムに選んで目指しているだけだ（プレーヤーの船自体を目指さないのがみそ）。プレーヤー用の船にAIスクリプトをアタッチするだけで動く。プレーヤーが移動指示を出すのと同じ方法でAIも船に移動を命じているからだ。共通のユニットを敵味方が使う場合はプレーヤーが扱えるのはもちろん、コンピュータにも扱い易い仕組みにしておくことが大切だと感じた。

【Unity】RTS:かんたいプロジェクト 建造から進水まで

　砲塔と火器管制のスクリプトを書き換えてようやく連動するようになった。妥協によって以前より挙動が単純になり、砲塔が火器管制がリストアップした標的リストから目標を勝手に選んで勝手に攻撃するようになっている。これによって個々の砲塔を集中管理することは難しくなったが、艦船の建造から進水までの負担が小さくなった。

　本日の改善によりとうとう船の設計から実戦までを通して行えるようになった。細かいところはほっぽいてAIの設計に移る。

ほかにも幾つか修正をしてカメラ操作はマウス中ボタンホールドで視点の角度を変えられるようにした。またいずれ砲弾の威力と貫通について調整が必要になるので砲撃をテストするシーンをつくっておいた。

委員会

　新しい試みとしてしばらく前から委員会制度を使っている。これは「(^_^)ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝ？？」な自分がシーン上で分散していろいろなところで稼働しているスクリプトを集中管理できないかと思って始めたもので、おおまかなタスクごとに委員会を設けその下に仕事を行う複数のマネージャーを置いた縦割り型の仕組みになっている。委員会はシングルトンでマネージャークラスや設定クラスなどの名簿をもっている。他のマネージャを含めたゲームオブジェクトは委員会の名簿を参照することで他のゲームオブジェクトにアクセスできる。
　今回の場合は「艦船建造委員会」と「艦船戦闘委員会」がありそれぞれ艦船の建造と戦闘（ゲームの進行）に責任を負っている。艦船建造委員会の管理下には「建造マネージャ」や「部品マネージャ」などがある。建造マネージャはユーザーアクションに対して部品を生成したり、位置を記録したりする。部品マネージャは建造マネージャの要請に応じて管理している部品群から実際の部品を生成する。委員会とそのマネージャ群は基本的に一つのスクリプトにまとめたほうがいい内容だがわかりやすさを重視してあえて分散させている。
　初期化についても集中管理の方法を試している。AwakeやStartはともするとNullでエラーが起きやすい。いまのところAwakeでは参照するクラスの登録などに処理を限定している。集中管理の方法として初期化のためのInitializeメソッドを設けて委員会管理下のマネージャで順番に各ゲームオブジェクトのInitializeメソッドに点火していくことを考えている。

【Unity】RTS：かんたいプロジェクト 未来位置とマニピュレータ

　火器管制を改造する途中で船の未来位置を計算する必要があったので実装した。これが一筋縄では行かなくて２日もかかってしまった。結局１秒と２秒前の船の直進進路ベクトルと船の位置の遷移ベクトルから船の実際の進路方向ベクトルを割り出して経過時間に応じて現在位置に加算することで未来位置を求めた。上の写真では黄色から赤色までのマルが5〜35秒後の位置を示している。この時点で船は円を描いて周回しいて、航跡と予測位置がほぼ一致しているのが分かる。Bwarsではただ単に車両から伸びる前方ベクトルに速度と時間を掛けた単純なものだったのでこうした苦労は必要なかった。

　艦船設計のマニピュレータも直した。３６０度どこからでも正確に移動させることができるようになった。またx-z平面に対して並行で動かせるようになった（ｘ，ｚ軸ごとに動かす手間を省ける）。カメラから伸びる線分とx-z平面の交差点を基準にしてマニピュレータが動くようになっている。ｙ軸方向の移動はよくわからない仕組みでうまく動いている。

【Unity】RTS かんたいプロジェクト 接触の判定

各種モジュールの種類を増やして（砲塔・弾薬庫・エンジン）相互に連関するようにした。これはとても面倒な作業で、モジュール同士の接触判定とその処理を作りなおすことになった。

【Unity】RTS かんたいプロジェクト 弾薬庫など

前回からだいぶ経ってしまいましたが、お休みしていたわけでなく、こつこつと艦船設計の仕組みを作っていたのです。つまりモジュールに３つの種類の探知機―ある箇所が空中にさらされているか、船体に埋まっているか、他のモジュールと干渉しているかを調べる―を使って総合的にモジュールが正当か調べる仕組みを作ったり、伸縮するモジュールに探知機がきちんと追随するようにしたり、ハンドルで位置のみならずスケールも変えられるようにしたり、モジュールの種類を整理して再編したり、読み書きするCSVファイルのフォーマットを更新したり、艦船設計モードの司令系統を再構築したり、よくわからないバグと格闘したり、モジュール管理のｆｄｊさｌ；ｊふぁいぉｆｄｊｓ：ｄさｄかｍさｓ：

艦船に弾薬庫がつきました。弾薬庫に接する砲塔は発射速度が向上します（予定）。しかし船体外苑に近くなるほど弾薬庫は被弾の可能性が高まり、当然ですが、被弾すると爆発します。

最近Bitbucketを導入してうちと仕事場でゲームを作っています。この方法のメリットはたいして働いていないのに、達成感をもって家に帰られることにあるのではないでしょうか。

【Unity】RTS：かんたいプロジェクト プレハブの生成

右の船が設計中で、左の船が設計に基づいて生成されたもの

艦船モデルを設計してその設計を元に実際に稼働する（戦闘可能な）プレハブを生成するところまでできた。つまりプレーヤーが設計した船が実際に動き出す。

2015年目標

あけましておめでとうございます。今年がいい年になるように目標を宣言します。