NPC をコーディングして領地経営するゲーム開発（リリース版のゲームまわりを見直す）

リリース版の動作確認というか見直しをしています。前回の記事ではタイトルシーンからステージ選択、ゲームシーンの UI までを見直しました。
今回はゲーム中の操作や UI の見直しをやっていきます。

やったこと

ゲームをプレイしながら気になった点を列挙していきます。

ヘルプパネルを表示するボタンのアイコン変更

アイコンを変更しました。

↓ 変更前（左）、変更後（右）

ダンジョン表記について

フィールドに「ダンジョン」と呼んでる敵との戦闘を行う状態のタイルがあるんだけど、今はアイコンでしかわからない。

↓ ダンジョンの表示

これについては、カーソルをあわせたときに「ダンジョン」とか「敵がいる」とか「どう対処する必要がある」というのをわかるようにしたいです。

一応、ダンジョンについてのヘルプはあるのですが、この表示だけを見て「むむむ、これはダンジョンなのでヘルプを見よう！」とはならないので。

↓ ダンジョンのヘルプ表示

考えた案としては

• カーソルを合わせると「敵が占拠してダンジョンと化している、冒険者ギルドから冒険者を送り込んで敵を倒そう」というメッセージと敵構成の Tooltip を表示する。
• プレイヤーに冒険者ギルドの建物の情報を開きたいが、開かせる方法がわからない。
  • カーソルを合わせたときに「冒険者ギルドで」と書いておいて、ヘルプから調べてもらうのを期待する？
• ヘルプで表示するメッセージ中の「冒険者ギルド」という文字にカーソルを合わせると、Tooltip 表示できるとよいか？

なんというか、フィールドからの情報と、ヘルプと建物とアイテム一覧の情報とが連携できてないのが気になります。

また、ダンジョン探索させる建物である冒険者ギルドについても、レシピを見ても何ができるかよくわからないのが気になりました。

↓ 冒険者ギルドでのレシピの表示

これについては items.FindQuest.Description に「ここで３人がワークすると、その３人が最寄りのダンジョンまで移動して敵と戦う」的なメッセージを書けばいいのかもしれません。

他の気付き

• ゲーム開始直後の情報量が多い。
• どうプレイするゲームなのかは、説明を繰り返す必要がありそう。
• ここまでを意識して最初の数ステージを作る。

とかです。

まとめと今後の予定

今回は、ダンジョン探索まわりのゲームプレイを見直しました。このゲームの大きな要素としては「物流とクラフト」「建築」「ダンジョン探索」「敵軍の撃退」があると思っていて、それぞれはチュートリアルのステージで説明するとはいえ、もう少し説明というかわかりやすい必要があるなと思いました。

このあたりは、なんか大切そうなのでちゃんと改善案を考えて着手したいです。次回は、このあたりの続きか、チュートリアルの最初の数ステージの作り込みをやろうと思います。がんばります。

ねこ巫女籠城ゲーム開発（敵の移動の作り直し）

敵の移動で使う壁の高さまわりが動作したので、敵専用の移動処理に着手します。
今までは味方用の移動処理で敵を動かしていました。

やること

敵の移動をどうするか

このゲームはフィールドが１タイルの辺が 2m 相当のタイルで表現しています。そして敵の移動においては、このタイルごとに「こっちに移動すべき」というのを８方向を定義して移動させる予定です。

• 経路探索してどの方向に移動すべきかをタイルに８方向の分解能で割り当てる。
• 敵ユニットに速度を保持させる。
  • 保持している速度にタイルの速度を加味して移動させる。
• Update() 処理ごとに高さ方向の移動量を計算し、高いほど水平移動を遅くする。
  • 垂直に近い移動のときには「壁登りモード」として特別な処理に切り替える。

といった処理にする予定です。

敵以外の移動をどうするか

敵については拠点である神社に集まるように攻め寄せるので上記の処理にするのですが、敵以外の「自キャラの移動先指定移動」「住民」「ビルダー」「キャリアー」なんかは、タイルの中心を移動するタイルベースの移動をさせるつもりです。

例えば、資源を運搬するユニットであるキャリアー同士については「本拠地への資源の運搬経路が複数あると効率がよくなる」的なことがやりたいので、厳密に管理できるタイルベースの経路移動をさせる予定です。後でまた考えます。

やったこと

最終的には経路探索した結果をタイルに移動方向として割り当てるのですが、とりあえずデモシーンでは一方向にのみ動かします。移動方向が変わってユニットの向きを変えるあたりは別のデモシーンで調整しようと思います。

やることとしては

• 今までの移動処理を削除する。
• とりあえず水平方向に一定速度まで加速するようにして、速度を保持する。
• 地面、建物や壁の上を移動するようにする。
• 移動して高低差があったときの速度調整を行う。
  • どうすればいいのか後で考える。
• 垂直に登るためのステートと、自由落下のステートとを定義する。

という感じです。
とりあえず、今までの処理を削除して一定速度で移動する実装を記述しました。
あと、最大速度と加速度も定義しました。よいです。

↓ とりあえず左に等速させるようにした様子

最大速度は units.yaml に定義して、開発用に速めの値を設定しました。よいです。

まとめと今後の予定

小難しい実装である敵の移動まわりの実装に着手しました。よいです。

次回は この続きか、ゲームとして最初から遊んでみるあたりに着手する予定です。がんばります。

NPC をコーディングして領地経営するゲーム開発（リリース版の見直し、タイトル）

早期アクセスでのリリース予定まで１ヶ月をきったので、リリース版の動作検証もやっていきます。これからリリースまでの作業は

• リリース版でのテスト
  • 不足している機能の追加
  • 不具合の修正
• 新しい機能の追加
  • Python 対応や、Steam Workshop でのステージデータ共有など
• リリースまでに何をするかの検討

といった内容になります。

やったこと

ビルドして Steam にアップロードして起動からテストを行った

これについては、不要なファイルを Steam に登録していたので修正しました。
具体的には Python まわりの pycache フォルダが生成されていました。アップロードの際に削除するよう修正しました。よいです。

タイトルシーンのテスト

とりあえず各ボタンを押して適切な動作するかを確認しました。気付きとしては、

• オプションパネルを閉じるときに効果音が鳴らないのが気になる。
• クレジット、変更履歴を交互に開くと表示すべきテキストが表示されない。

です。
テキスト表示されない不具合が今頃になって見つかったのは割とショックです。
効果音については修正しました。よいです。

テキスト表示については、使っているアセットに原因がありました。
テキストエリアに配置した「閉じる」ボタンをクリックしたときに、そこにカーソルが移動した扱いになって、かつ、長いテキストを表示した後で、短いテキストを表示させると「テキストが（短くなって）もうない箇所にカーソルがあるのでエラー」になっていました。
こういう「買って実際にアセットを使うまでわからなかった問題」は、あるあるだと思います。

どう対処するか悩みましたが、例外を無視するための try-catch を追加して対処しました。あまりよい対処ではありません。

ステージ選択シーンのテスト

気付き

• 「難しい」のメッセージをもっと簡略化したい。
• ワールドの項目にカーソルを合わせたときに、そのワールドのステージ名を Tooltip 表示してもいいかも。
• 右上の「スクリプト言語」「難易度」がださい。
  • ボタンをクリックしたときに効果音が鳴らない。
• UI に動きがない。
  • タイトルシーンと同様に背景がスクロールしてもいいかも。

↓ 難易度の説明が細かすぎるあたり

難易度の説明については、最初のが行を「最低限のファイルしか作られません。だから自作してね」という内容に変えました。
また、タイトル同様に背景画像が動くようにしてボタン押下時の効果音再生も行いました。よいです。

ワールドのステージ情報を Tooltip 表示するのは後回しにします。

ゲームシーン

とりあえず UI まわりを確認しての気付きです。

• 建物で何を生産できるかわからない。
• 建物を建築するために必要な工具がわからない。
  • 木槌、金槌だけなので明記しなくていい気もするが、明記してもよさそう。
• 建物のフレーバーテキストがない。

• アイテムがどの建物で生産できるかわからない。
• アイテムに必要な素材が建物を建築するまでわからない。
  • 同じアイテムでも違うレシピのことがある。
• アイテムごとのフレーバーテキストがない。
• アイテムの属性が多いと表示がはみでる。

• 称号（スキル相当）の情報表示の機能がない。
• ダンジョン探索中のパーティメンバーの情報表示機能がない。

• Lua 対応のドキュメントはあるが Python 用のものがない。
  - 併記するか切り替えるかとか、いろいろ決めてない。

• フィールド表示をホイール操作で小さくした後でリロードすると、デフォルトの大きさで表示された後に、カーソルが UI から外れると即座にリロード前の大きさになる。

ここまでをまとめると

• フレーバーテキスト等を考える。
• どこで作れるかの情報や、どんな効果かの情報を記述する必要がある。
  • 表示枠に収まらなさそう。
• Python 用のドキュメントをどうするか。

という課題があるのがわかりました。

建物とアイテムの情報表示をどうするか

左側の一覧パネルには最低限の情報（名前と１行説明とコスト）だけ表示して、詳しい情報は Tooltip 表示するのがよいかな、と思います。次回以降の作業で着手します。

Python 用のドキュメントをどうするか

早期アクセスの段階ではドキュメントはこのままでリリースしようと思います。Python は実験的な位置づけにしようと思うのですが「Python 対応って書いてあったから買ったのに、使えねーじゃん」ってなるのも嫌なので Python 対応については慎重に扱いたいです。

まとめと今後の予定

タイトルシーンからゲームシーンの UI までを見直しました。必要な機能が実装されてないのがわかります。

特に「この建物はどうすれば建築できて、何ができるの？」とか「このアイテムはどの建物で生産できるの？ コストは？」といったあたりは遊んでいてイライラに直結する問題なのでリリースまでに解決します。

次回は、建物とアイテムの情報まわりに着手するか、今回の続きをやって課題の確認だけを先にやるか、のあたりに着手しようと思います。がんばります。

ねこ巫女籠城ゲーム開発（移動用のメッシュの高さデータを保存するあたり）

敵が壁を乗り越えるときに「この建物、壁はこういう高さになってる」を定義するメッシュをゲームプレイ時に動的に生成していたのですが、生成されないことがあるようなのでどうにかします。

やったこと

高さが定義された疎な点列データから細かいグリッドの高さを計算する

疎な点列データからメッシュを描画する。
yield return new WaitForEndOfFrame();
Raycast を細かく分割したグリッドごとに実行してメッシュの高さを取得する。

という処理で、点列からメッシュを描画してちょっと待ってから Raycast を実行していたのですが、このちょっと待つ時間を yeild return null; などで１フレーム待つ、などにすると、Raycast の結果が適切にならないことがありました。 0.1 秒と長めに待つと動作します。こうなる理由はよくわかりません。

これを

• 疎な点列データから Raycast で計算した結果をファイルに保存する。
  • 疎な点列データが更新されたときのみ、このファイルを作り直す処理を行う。

という処理にして動作しました。
これで、必要なときのみ 0.1 秒と長めに待つメッシュ処理が実行されるようになりました。よいです。

メッシュ高さと乗り越えコストについて

いくつか未実装ですが、建物と壁との移動用のメッシュが定義できたので、これを敵が乗り越えるあたりの調整をしていきます。

↓ 現状の移動メッシュによる敵の移動軌跡

今は等速で乗り越えてしまうのですが、これを建物や壁ごとに「移動しにくさ」として定義したパラメータが使われるようにして、かつ「垂直な壁の場合には専用のモーションを使う」といった実装にしていきます。

とりあえず、乗り越えにくさを建物の移動メッシュごとに定義しました。

右端の数値が「乗り越えにくさ」です。１つの建物の複数のメッシュに同じ値を指定している点については、後で「最初に指定された値を同じ建物で利用する」みたいな実装に変えようと思います。

そして、この移動しにくさを移動メッシュに乗ったときに適用するあたりですが、

• 水平方向の等速移動ではなく、移動メッシュの斜面の上を等速移動するように変更する。
• 移動メッシュの移動時に乗り越えにくさを利用する。
• そもそもユニットごとの移動速度を定義して利用する。

とかの要素が絡んで小難しいので実装は次回にやります。

↓ 水平方向の等速移動でなく移動距離を考慮して移動させたい図

まとめと今後の予定

移動メッシュの評価結果をファイルに保存して利用されるようにするあたりと、その移動メッシュをどう利用するかについて検討しました。よいです。

次回は、今回の続きの「移動メッシュに沿って等速運動させる」か、雑多なタスクに着手しようと思います。がんばります。