NPC をコーディングして領地経営するゲーム開発（Python 対応の RPC に着手）

Python 対応を進めます。NPC を制御する Python コードを個別に実行して、ゲーム側のサーバと TCP/IP 通信して必要な情報を送受信して動作させようとしています。

やったこと

主に Python クライアントとゲーム側サーバとの通信まわりを実装していきます。

ゲーム側のサーバを起動する

とりあえず、ゲーム側で各クライアントからの接続を過去に実装した TcpipServer.cs クラスを使って Listen できるようにしました。

よいです。

Python クライアント側の調整

Lua も C# もそうですが、Python も詳しくないので PEP8 のドキュメントを読んだり、実行して pdb モジュールが返す文字列を読み解いて実行時エラーの修正をしたりしていました。

それから、ログを見ていて「複数の Python スクリプトの pdb のログが１つのコンソールに表示されると混ざってわからない。コンソールは複数にする必要があるのでは？」と思ったりしました。少なくとも stderr として出力される情報は Python スクリプトごとに確認できた方がよさそうです。
ログまわりの UI をどう変更するかは少し考えます。

クライアント用のモジュールの実装予定

そして Python スクリプトとゲーム用サーバで通信して情報のやり取りを行うわけですが、例えば keep = world.keep() という Python のコードがクライアントで実行されたら

• world モジュール経由でゲーム側サーバに TCP/IP 接続を行う。（未接続ならば）
• world.keep, 引数なし、という内容をゲーム側サーバに送信する。
• 城塞(Keep) の位置情報を受信する。（位置情報をキーとして利用する）
• 位置情報で初期化した Building クラスのオブジェクトを作って返す。
  • 不変なデータである Name を受け取って初期化してもいい。
• 以降は Building オブジェクトのメソッド呼び出しでゲーム用サーバと通信して情報のやり取りや制御を行う。

という処理を行います。
思ったように実装が進んでいなくて、このあたりは次回に行います。開発に着手できたのは大変よいです。

VS Code で追加パスにあるモジュールを認識せずにエラーになるのを修正した

このゲームの Python モジュールは sys.path.append() で追加しているのですが、そのパスを VS Code の Pylance が検出しないらしくて、調べて対処しました。

結論としてはこのサイトにある設定を追加したら動作するようになりました。よいです。
sys.path.appendで追加したパスがPylanceで認識されない

雑多な実装

荷馬車のドット絵を清書して、発車時の効果音を適用した

動作するのを確認しました。よいです。
荷車のドット絵はもう少し汚した方がよさそうですが、また後で検討します。

まとめと今後の予定

Python 対応の実装を少し進めて、実行時のエラーを修正して TCP/IP でどういう通信するかを確認しました。よいです。

次回は、この Python 対応の続きを少しでも行います。がんばります。

NPC をコーディングして領地経営するゲーム開発（Early Access 版の機能を決める）

そろそろ７月の Early Access 版のリリースに向けて、何の機能を実装するかを決めます。

やりたいこと

このゲームは 2024 年の７月に Steam で Early Access リリースして、2025 年の７月に正式リリースします。つまり、作業できる時間はあまりありません。

実装済みの要素と Early Access に含めたい要素

現在、動作するけど完了はしてない要素というか実装済みのコンテンツとして

• チュートリアルが Lua スクリプトでクリアできること自体は確認済み。
  • 要素というかボリュームの調整はしてない。
• チュートリアルの各ステージ最初の会話の作成は、後半ステージで未着手。
• 日本語対応は完了、英語対応は 80% くらい。
  • 日本語で開発した後で英語リソースを追加している。

となっています。
このままでは 「チュートリアルをプレイし終えたら遊ぶコンテンツないじゃん？」 となるので、エンドコンテンツが必須なのですが未実装です。

また、今はゲーム中で NPC の行動を記述するのに使えるのが Lua 言語だけなのですが、ゲームのプレイ層を増やすために Python 対応もしたいと思っていて、これも Early Access に含めようと思っています。

また、ゲームはリリースした瞬間が１番注目されると思っていて、Early Access 開始の１年後に正式リリースする場合であっても、なんというか正式リリースのタイミングでは注目されないと私はみなしています。（私が宣伝めんどうで何もしてないのもあります）

そういうわけで、これから７月の Early Access までに実装したい項目としては

• エンドコンテンツの作成（必須）
  • ランダムマップを生成して難易度調整して遊べる仕組みを作成する。
• Python 対応（必須）
• チュートリアルの各ステージの会話テキストを考えて書く（必須）
• パラメータ調整とメッセージの英訳（必須）
• MOD で自作したワールドやステージを共有する機能（最低限でいいので提供する）
• 3D 表示モード（途中まででいいのでやる）
• MOD で建物やアイテムを追加、変更する機能（やる時間なさそう）
• 各アイテムのフレーバーテキスト作成（やる時間なさそう）

になります。
これ以外にも、開発用に各種機能をテストする仕組みなんかも必要です。

やるべきことを書き出してみて 「これ、絶対に間に合わないじゃん」 としか思わないのですが、書き出して確認したことは大変よいです。

やったこと

Early Access に含めたい機能なのに仕様検討が終わってない項目について考えます。

ランダムマップを生成して難易度調整して遊べる仕組み

既存の固定パラメータのステージを遊ぶ仕組みではなく、

• フィールドをランダム生成し直せる。
• 各種パラメータを変更できる。

ようなゲーム画面になって、それで諸々のパラメータを設定してからゲーム開始できる仕組みを提供したいです。

最終的にはパラメータを入力する UI もスクリプトから指定できるようにしたいのですが、とりあえず決め打ちで作成します。詳しいことは後でまた検討します。

MOD で自作したワールドやステージを共有する機能

あるディレクトリにあるファイルを使ってゲームをする機能はすでにあるので、

• Steam Workshop にワールド、ステージ用のファイルをアップロードする機能
• Steam Workshop にあるワールド、ステージのファイルをプレイする機能
  • サブスクライブの実行は Steam クライアントからでいい。
• サンプルステージの Steam Workshop へのアップロード
• ステージの作り方のドキュメント作成

なんかを順に実装していけば終わります。
細かい仕様を決めつつ動作確認しながら実装していけば終わってほしいと思っています。

開発用に各種機能をテストする仕組み

正直、Python 対応をするにあたって色々と変更していて、過去に動作していた Lua 用の機能が実装するか自信がありません。というか「テストしてない機能は動作しない」という意見もありますし、テストする仕組みを考えて実装します。

今は「プレイ中のワールドの全ステージを最高速でプレイする」という機能だけ実装されていて、これでもある程度の機能はテストできるのですが、これだとエラーが発生するかなどの異常系のテストができないので、なんか考えて実装します。

雑多な修正

７月に Early Access でリリースしたいのにもう５月なので、少し焦り気味で作業したいです。

↓ 総チケット数 1,130 くらいに対して終わったチケット数が 960 くらいなので、残チケットが 170 くらいの様子

キャラクターがアイテムを持ったときの向きを修正した

↓ 修正前（左）、修正後（右）

修正前は料理を食べる動作のときに上下逆に画像を表示してしまって違和感が大きかったので修正しました。アイテムを鏡像反転してしまっていますが気にしないことにします。よいです。

まとめと今後の予定

７月の Early Access 版リリースに含めるコンテンツを確認してどうするか検討しました。よいです。

次回は、Python 対応かエンドコンテンツまわりの実装に着手します。がんばります。

NPC をコーディングして領地経営するゲーム開発（倉庫と荷馬車の実装）

以前の記事で検討した「倉庫」と荷馬車を実装していきます。

やったこと

倉庫の建物を追加する

↓ 倉庫っぽい絵を微調整して、ゲームで表示されるようにしました。

ストレージのスロット数と最大アイテム数も調整しました。よいです。

荷馬車の見た目を準備する

↓ 荷馬車の見た目を作成して、アニメーションするように調整しました。

よいです。
馬と荷車に影がないとか、車輪の回転速度が合ってないとかの見た目の調整は後でまたやります。

倉庫から運搬する API を追加する

キャラクター用のスクリプトから荷馬車で運搬できるようにします。

↓ 荷馬車で運搬するときのコード
character:carryByCart(keep, Items.Bread, 12)

↓ 荷馬車で運搬している様子。

運搬先のアイテムが適切に増加するあたりも動作するのを確認できました。
よいです。

まとめと今後の予定

「倉庫」から複数個のアイテムをまとめて運搬する仕組みを実装しました。よいです。
次回は Python 対応か全体的な見直しをやろうと思います。がんばります。

NPC をコーディングして領地経営するゲーム開発（市場と倉庫の仕様検討）

今回は特殊な建物の仕様を検討して実装に着手します。

やりたいこと

少し特殊な建物である「倉庫」「交易所」について仕様を決めていきます。

倉庫

通常は NPC １体が１つのアイテムしか運搬できないのですが、倉庫から他の建物への運搬は「荷馬車」を使って１つのアイテム複数を１回の運搬で行えるようにします。

考えた仕様としては

• 倉庫の上に NPC がいるときに、荷馬車でアイテムを運搬するコマンドが使える。
  • コマンドを実行する際に板材を消費する。
• 運搬を開始すると、運搬が完了するまで中断できない。
• 運搬が完了すると荷馬車は消える。
• 荷馬車と通常ユニットの移動速度は同じ。

この倉庫では、オーダーをなくしてその場所に「倉庫の上の NPC は輸送コマンド～を利用できます」「輸送コマンドの実行には木材が必要です」みたいなメッセージを表示しようと思っています。

↓ 通常の建物をクリックしたときのパネル。オーダーとストレージがある。

よいです。

交易所

これはエンドコンテンツとしての動作を想定していて「たくさんのアイテムを輸出して貨幣を得る」「大量の貨幣で貴重なアイテムを購入する」といった役割をさせたいです。

基本的には他の建物と同じで、輸出のときには「輸出するアイテムをストーレジに入れてワークすると貨幣が得られる」という風にして、輸入のときには「オーダーを選んで貨幣をストレージに入れてワークするとアイテムが得られる」という風にします。

ただ、他の建物と同じ横長のオーダー表示にする必要はなくて、輸出のときは例えば「銅貨１を入手できる交易品」グループの中に「卵x4」というふうな簡略表示にしようと思います。

貨幣については銅貨10枚で銀貨１枚、銀貨10枚で金貨１枚、というレートにします。
この貨幣の両替も「銅貨10枚をクラフトすると銀貨１枚が得られる」というオーダーを用意しておけば後で変更もできそうだしオッケーです。

この交易所での交換レートはステージをつくる人が調整できる必要がありそうなので、ステージ初期化スクリプトの setup.lua からオーダーを新規追加する機能の実装が必要そうです。

やったこと

「倉庫」で運搬したときに表示する荷馬車をどう表現するかを試行錯誤しました。
馬イラストは NPC に使っている 2D Pixel Unit Maker - SPUM アセットに馬も含まれていたのでそれを利用しています。

今のところ１番上の荷車を引くタイプにして、荷物に運んでいるアイテムのアイコン表示をしようと思っています。
実際に動作する荷馬車を作るあたりや、運搬コマンドを追加するあたりは次回以降にやろうと思います。

雑多な修正

雑多なタスクも着手していきます。やらないと終わらないので。

ダンジョンの背景の追加

ダンジョンの背景画像は多重スクロールするのですが、洞窟だけでなく暗い城塞内部と暗い森のスクロール背景を追加しました。
これらの背景は 2D Dungeon Backgrounds for Mobile Games と Simple 2D Background Pack アセットとを使っています。

よいです。

まとめと今後の予定

漠然と考えていた「倉庫（と荷馬車）」と「交易所」についてどうするか検討しました。よいです。

次回は倉庫と荷馬車の実装か、製品版のゲームとして見直したときに未実装な機能に着手しようと思います。がんばります。

NPC をコーディングして領地経営するゲーム開発（必要な Python モジュールの準備）

ゲームプレイを Lua スクリプトだけでなく Python スクリプトでも行えるあたりの実装をしていきます。
今回は、プレイヤーが記述する Python スクリプトに必要なモジュールファイルの準備を行います。

やったこと

Python が１行ずつ実行されるようにする

以前の記事 で Python を１行ずつ実行するあたりは動作したので、それを取り込みました。

そして現状の edict.py が

import pdb; pdb.set_trace()
chart.addItem(Items.Wheat)

これ↑で、これを実行してゲーム内のコンソールに表示されたものがこれ↓です。

ちゃんと python スクリプトとして評価して「chart ってなに？」というエラーメッセージが表示されているのがわかります。

ここまで動作して大変よいです。

Python としてのエラーを修正する

先ほどの chart やこれから必要になる edict, character, world などは Python のモジュールとして提供することにします。Python は詳しくないので、このあたりからは試行錯誤です。

とりあえず、必要そうなファイルを StreamingAssets ディレクトリ経由で提供することにして、そこをパスに加えます。

やったことをまとめると

• chart.py, items.py を Assets/Streaming/Assets/Python に追加した。
• sys.path にパスを追加してから必要なモジュールを import した。

です。
現状の Python スクリプトはこうなりました。

import pdb; pdb.set_trace()
import sys
import os
print(os.getcwd())
sys.path.append('full/path/to/Assets/StreamingAssets/Python')
sys.path.append(os.path.join(os.path.dirname(__file__), '../..'))
import chart
import items

chart.addItem(items.wheat)

よいです。
最終的にはこの Python スクリプトの前半のコードは、ゲームの実行時に追加するようにします。

まとめと今後の予定

Python スクリプトをゲーム中から実際に実行するあたりに着手しました。よいです。
次に行うべきことは、ゲーム側が提供する API が動作するようにすることで、これは TCP/IP 通信でどうにかしようと思います。

次回は、API が動作するようにするあたりか、アイテムや建物のパラメータ記述をしようと思います。がんばります。