味方の攻撃やローグライト要素などの仕様検討（巫女＆築城＆防衛アクション）

ゲームとしてどうしたいかを検討します。

仕様

ゲームのプレイモード

今のところ

• フリープレイ ... 築城して防衛アクションをするメインの遊び方。
• シナリオ ... ステージごとに決められた目標を達成していく遊び方。ストーリ付き。
• アクションプレイ ... クリアデータを使う。築城まわりはクリアデータの操作を再生して利用し、アクションまわりだけをプレイし直す遊び方。他人のクリアデータも利用できるようにする。

を考えていて、チュートリアルはシナリオに含めます。
設定方法は未定ですが、敵が出なかったり資源が無限だったりは「フリープレイ」で実現します。

また「シナリオ」では他人の作ったものも遊べるようにしたいです。

そして「アクションプレイ」では、他人のクリアデータで遊べることで城郭の建て方を知れたらいいなとか、部隊操作はクリアデータの設定を使うかをオンオフできたらなと思っています。クリアデータを気軽に Steam Workshop にアップロードできて、それが簡単に閲覧できて「お、新しいクリアデータがあるし遊んでみるか」みたいなことを実現したいです。

また後で考えます。

ローグライト要素について

フリープレイではランダム生成されたフィールドを見て「今回はこのフィールドの湖畔の脇に城郭を作るかな」みたいな遊び方を想定しています。とはいえ、城郭の作り方は各人によって固定化されそうで、多少のゆらぎを提供するために３択のスキル取得を考えています。

ぶっちゃけるとスキルまわりは Death Must Die というゲームを参考にしようと思います。話題にしておいてなんですが「スキルは３択で選択できるようにしようかな」くらいしか考えていません。また後で考えます。

また、フリープレイのモードでは所定のラウンドまでの生存でゲームクリアです。（継続プレイもできる） そしてゲームクリアのときにプレイ開始時の難易度の設定に応じて勝利ポイントが得られて、それで何か永続強化できるようにしたいのですが未定です。

ローグライトなゲームに多い「ゲームオーバーでそこまでのセーブデータを消す（もしくはセーブできない）」の仕組みは取り込まない予定です。（プレイ中に作った城郭自体を成果物とみなしたいため）

しかし「固定された難易度のステージをクリアするために永続強化していつか勝つ」みたいなゲームにしたいわけでもないので、永続強化をどうするかは悩ましいです。強化ではなく「要素のアンロック」にするのがよいかもしれません。また後で考えます。

敵味方の攻撃について

敵の攻撃判定をどうするかと、味方部隊と自キャラについてくる随伴兵の攻撃判定について考えます。

敵からの近接攻撃

このゲームではグリッドについて、ユニットの大きさである「タイル」、その倍の大きさで建物の配置に使う「ブロック」、タイルの半分の大きさの「サブタイル」という定義をしています。

敵が建物を攻撃する際の判定については「敵が移動してサブタイルの座標が変わったときに、移動方向の先の位置のブロックに建物があれば、それを攻撃する」というロジックで実装済みです。

敵が味方部隊や随伴兵を攻撃できるかは、味方部隊や随伴兵の側から射程判定をして「攻撃できる」と判定したときに「敵からも攻撃できる」ものとして扱うようにします。

敵からの遠距離攻撃

攻撃対象を敵共通の情報として保持しておいて、最も近い対象を攻撃するようにします。
攻撃対象に登録するのは「移動先にある建物」「攻撃してきたユニットがいた位置の建物」「攻撃してきたユニット」です。

基本は敵ユニットが移動してタイルが変わったときに攻撃できる対象があるかを判定します。小難しくなるのですが、ここで扱う攻撃対象は位置が変わらないものとして判定します。

位置が変わらないものを対象にすることで、移動して新しく射程に入ったブロックのみの判定で済みます。

味方部隊からの攻撃

味方部隊のユニットは停止しているときのみ攻撃できるものとします。
そして、停止したときに周囲のブロックに「ここは攻撃できる」という登録をしていきます。この登録したブロックに敵が入ったときの攻撃の開始に利用します。この登録はユニットが移動したら無効にします。

随伴兵からの近接攻撃

随伴兵の数は最大８体と少ないので、ベタに近くのタイルにいる敵とで射線判定をします。

随伴兵については「待機」と「突撃」の２つの指示を行えるようにする予定ですが、近接攻撃については指示に関係なく判定を行います。

随伴兵からの遠距離攻撃

指示が「待機」のときには、味方部隊と同様に「ここは攻撃できる」判定を事前に行うことにします。

指示が「突撃」のときも基本は同じなのですが、移動してブロックが変わると射程内のブロックすべてで射線判定をやり直すべきなので、どうするか悩ましいです。

KDTree を使って近い順に数体の敵を取得して射線判定を行う方法で良い気もするのですが、敵の総数を決めて評価してから考えようと思います。この処理負荷が大きくないなら指示が「待機」のときも同じ処理でよいかもしれません。

射程と移動があるときの敵味方の射程判定は、私には小難しいです。

やったこと

スキルをくれる神のイラスト探し

Death Must Die でスキルをくれるのがイラスト付きの神なので、それを真似るために和風の神のイラストを探していました。

なかった…

神っぽいイラストはもちろんあるのですが、和風で好みの絵柄で種類もあってライセンスも問題ない、とかの条件で探すと見つけられませでした。なので、神さまはあきらめて見つけた妖怪娘のイラストを使うことにします。予定は変わりましたが、これはこれで良いと思いました。

妖怪娘立ち絵素材、妖怪娘立ち絵素材2

↓ 使用イメージ

スキル取得の仮 UI 作成

３択でのスキル選択まわりも仮作成しました。

こういう作業はもっと後に着手するべきなんだよなぁ、と思いながら作りました。

ビルドサイズの削減

テストのため、ここまでの実装をビルドして Steam にアップロードしたところパッケージのサイズが 900 MB になっていて「なんか大きくない？」と思ったので調べて削減します。

Clean Build して Open Editor Log でログを確認したところ、PixelHeroes アセットの使ってない画像までが含まれていました。

その理由を調べるために、下記ページを見ながら Dependency Viewer パッケージをインストールして調べました。

https://light11.hatenadiary.com/entry/2022/12/21/193109

調べたところ、FantasyHeroes/Resources/SpriteCollection.asset のパスの通り、このアセットの画像を登録したものが Resources フォルダ以下にあったのが原因でした。
いったん Resources フォルダから移動させてビルドしたところ、無事にコンテンツサイズが 941 MB から 200 MB になりました。

↓ 変更前のサイズ

↓ 変更後のサイズ

よいです。

ビルドログには他にも除去していいファイルがありましたが、いずれまた着手します。

まとめと今後の予定

どういうゲームにしたいかを考えて、敵味方の攻撃をどう実装するかを考えました。よいです。

次回は、味方部隊からの攻撃まわりに着手しようと思います。がんばります。