投稿記事

コーディングの記事 (83)

竹林ソフト 2024/06/18 20:00

NPC をコーディングして領地経営するゲーム開発(ゲームビルド申請の準備)

来月末までの早期アクセスでの販売開始を目指し、作業を進めていきます。

やること

Steam さまに対して「このゲームを販売してもよいですか?」という申請に必要な作業を確認して着手していきます。

多言語対応

Steam さまへのゲーム審査を申請する際は「ストアページに対応言語として登録した言語で遊べるか」と「あからさまな不具合がないか」を特に意識しています。

とはいえ、このゲームについては体験版が審査済みなので、システムまわりの実装の修正はする必要がなくて、体験版から追加したステージの英語データを準備すればいいと思っています。

↓ 言語まわりだけ日本語と英語を併記している様子

そして、追加したステージでのセリフを英訳して終わりにしたいのですが、まだ日本語でのセリフを考えてないので、そこから着手する必要があります。

まとめると

  • 全ステージの会話イベントのセリフを日本語で作り終える。
  • 上記の台詞の英訳データを登録する。

になります。

Steam Workshop でのステージデータ共有

「私だったらこういうパラメータにするのになぁ」とか「こういうステージで遊びたい」をプレイヤーも実現できるように、ステージやパラメータのデータを Steam Workshop 経由で共有できるようにします。

現状でも必要なファイルが入ったフォルダをステージとしてプレイする仕組みは実装されているので、ステージデータを共有するために Steam SDK の API を介してファイルのアップロードとダウンロードを実装すればオッケーです。

今回、Steam Workshop の機能を Steam Workshop - Easy Steamworks Integration アセットで実現するか、Toolkit for Steamworks SDK アセットで実現するかを少し悩んでいます。

前者は過去に使ったこともあって慣れているのですがカスタマイズが小難しくて、後者はよさそうだけど使い方がわかってない状態です。悩ましいですね。

どちらを使うか悩んでいると書きましたが、この作品ではとりあえず前者の Denis Lapiner を使って機能の実装をしていこうと思います。

今は付属のデモシーンを実行したり、Steam のストアページで Workshop 用のタグを登録したりして、最初のデータをアップロードするまでを試行錯誤しているところです。

後でやること

ここまでに書いた機能以外では、Steam さまへの販売申請までに

  • ダンジョン探索の敵追加と装備品のパラメータ調整
  • チュートリアルをクリアした後のコンテンツ追加

もする必要があります。
こういう作業は「いつでもできる」と思っているせいか、最後まで残ってしまって心の重荷になりがちなので、なんとかしたいです。

まとめと今後の予定

Steam さまに6月末に販売申請して7月末の販売開始を目指しています。そして、そのための残タスクの書き出しと実装に着手しました。残タスクの確認は今後も定期的にやっていきます。

次回は、Steam Workshop まわりの動作確認を進めたり、不足しているデータの作成をしたりしたいです。がんばります。

竹林ソフト 2024/06/14 20:00

NPC をコーディングして領地経営するゲーム開発(基本チュートリアル追加)

現状では Lua を知っている前提でゲームが始まって、さすがにプレイヤーを置いてきぼりすぎかなと思うので、もう少しこう「これがエディタね」「エディタで lord.lua を開いて3行目にこのコマンドを入力してみようね」的なチュートリアルを追加します。

やったこと

まず、追加するチュートリアルのワールド(複数ステージの集まり)を定義しました。

↓ 定義したワールドとステージ構成

次に、コメントとして各ステージで何を説明するのかを記述しました。

よいです。
この各ステージがちゃんと動作するための作業は後でやることにして、これらのステージを実際にゲームで選択できるようにします。

↓ とりあえず、ワールドとして認識されるようにしました。よいです。

↓ アイコンを追加しました。アイコンは Modern Item Set Pack から選びました。

よいです。
そして、この追加したワールドはプレイしてもしなくてもよい、ようにしたいので「クリア済み」になるようにハードコーディングして、(クリア済みなので)最初からどのステージでもプレイできるようにしました。

↓ 対処前(左)、対処後(右)

よいです。

ワールドについては「チュートリアル」「カスタム」「Workshop 共有」のタブを追加して選んだタブごとのステージ表示も考えていますが、それはまた後で調整します。

まとめと今後の予定

ゲームの遊び方相当のチュートリアルのステージを作成して、実際にゲームで認識されるようにしました。よいです。

次回は、この続きか他の雑多な作業か Python 対応の続きに着手しようと思います。がんばります。

竹林ソフト 2024/06/11 20:00

NPC をコーディングして領地経営するゲーム開発(Python 対応版をビルドしてテスト)

Python 対応が進んで1ステージをクリアできるようになったので、Build して動作確認していきます。あと、Steam での審査を見据えた対応もやっていきます。

やったこと

ビルドしての動作確認

Python 対応が動くかをビルドして確認してみたところ、Python で動作しないどころか、Lua でも動作しませんでした。

なので検証のために SRDebugger を使います。私は SRDebugger は実行時にエラー状況を確認するのに使っています。

↓ SRDebugger で確認したエラー内容(途中まで)

エラーが確認できたので修正してしまえばいいのですが、Build 版でのみ問題になって Unity Editor 実行で問題にならないのは理解しておきたいです。とりあえず

  • Lua モードでゲーム開始してもエラーになるのはおかしい。
  • Python モードでも本来はエラーなく動作してほしい。

というあたりが気になっています。

確認したところ、1つ目の問題については、NPC 用のスクリプトを配置するフォルダに .py と .lua の両方があったときに、スクリプト言語の指定と関係なく .py が利用されるのが原因でした。

これは、使うように指定したスクリプト言語を優先するよう変更します。

また、2つ目の問題については Process クラスを IL2CPP ビルドで Win32API の System.Diagnostics.Process を使っているのが原因でした。IL2CPP ビルドでも動作するよう作られた KS.Diagnostics.Process を使うように namespace を修正して対処しました。

ここまで修正したところ、Build 版でも Python スクリプトでの動作が確認できました。大変よいです。

そして、この作業で Build 版と Unity Editor 版との動作の違いはなくなったので、改めて Unity Editor でもって 未実装の機能の実装をしていこうと思います。

リリースまでのタスク確認

リリースまで2ヶ月を切ったので、改めて何をするかを書き出して確認します。
この流れは前回の記事でもやった気がしますが、今後も繰り返しやっていきます。

やること
- 全ステージにそれっぽい会話を考えて適用する。(必須)
- ダンジョンの敵がテスト用のままなのを変更する。(必須)
- Python 対応を終わらせる。(必須にしたいが間に合う気がしない)
- 3D 表示モードを実装する(必須、でなくてもいい)
- カスタムステージの仕組みを実装する。(必須にしたいが間に合う気がしない)
- カスタムステージを Steam Workshop で共有できるようにする。(必須)
- 初心者向けのチュートリアルのステージを用意する。(必須)
- 雑多なパラメータを定義する。(必須)
- 称号の取得条件を表示できるようにする。(必須)

くらいでしょうか。
必須なものだけ書き出そうとして「いやまぁ、無理だよな」と思った気持ちも併記しました。

全体的に眺めると「Python 対応をできるところまでやりつつ、Lua で遊べるように作り込んでいく」という感じでしょうか?

やることの詳細はツールで管理しているのですが、残タスクが 160 個くらいあって悩ましいです。

↓ そうタスク数と完了タスク数のチャート

まとめと今後の予定

今回は Python 対応で追加したコードが Build しても動作するかを確認して対処しました。大変よいです。

次回からは Python 対応以外の実装を終わらせるべく作業したり、Python 対応もしたり、プレイし直して修正すべき違和感を洗い出したりしようと思います。がんばります。

竹林ソフト 2024/06/04 20:00

NPC をコーディングして領地経営するゲーム開発(Python 対応: NPC 移動の続き)

Python 対応の続きをやっていきます。

やりたいこと

Python 対応をするにあたり、Python 側での NPC を制御する API 実行を TCP/IP 経由で実行するという RPC (Remote Procedure Call) な仕組みを実装しています。

以前の記事にて、

  • Python 側から指示する。
  • Python 側で情報を受取る。

という仕組みは実装できました。
今回は character.move() という移動コマンドのために

  • Python 側から指示してコマンドの動作が完了するまで実行をブロックする。
    • character.move() であれば目的座標に移動し終わるまで待つ。

という仕組みを実装しています。
この仕組みが動作すれば、以降はここまでの実装と同じ仕組みで対応できると思っています。

やったこと

Python 側とゲーム側との通信まわりを以下の仕組みで実現しました。

  • Python 側からコマンドとパラメータを渡して指示する。
  • ゲーム側で1ラウンドごとに繰り返す処理として登録して実行する。
  • Python 側から繰り返し「終わった?」と問い合わせる。
    • ゲーム側は処理中は「終わってない」と返事し続ける。

そして、その仕組みを実装してキャラクターが移動するようになりました。

↓ Python スクリプト経由でキャラクターが移動している様子。

よいです。

ここまでで(想定している)機能の最低限は実装できたので、残っている作業としては

  • これらの仕組みを他の全ての API にも適用する。
    • 想定してない機能が必要になったら実装する。
  • Python スクリプトのエラー表示をどうするか決めて実装する。
  • 動作を確認するためのテストを作る。
  • Python をゲームに含めるか、プレイヤーがインストールしたものを使うか決める。
    • Python パスを登録する UI を作るかとか。
  • TCP/IP 用の通信ポートが使えなかったときに次のポートを使うようにする。
  • Python 実行のプロセスの終了を保証する。

などの作業になります。
とはいえ、小難しい実装が終わって大変よいです。

まとめと今後の予定

必要だと思っている Python 対応の RPC まわりの仕組みを実装しました。大変よいです。

次回は、Python 対応の雑多なタスクか、それ以外の雑多なタスクに着手します。がんばります。

竹林ソフト 2024/05/31 20:00

NPC をコーディングして領地経営するゲーム開発(Python 対応の必要機能を実装する)

Python 対応の一番小難しい実装は終わりましたが、ぷち難しい実装が残っているのでやっていきます。

やったこと

ここまでで Python 側からゲーム側にコマンドを送るあたりが動作しました。今回はゲーム側から Python 側にデータを送るあたりを実装します。

そして実装しました。
やったことは

  • Python 側から要求されたデータを JSON フォーマットにしてゲーム側から送信する。
  • Python 側でデータを受信して処理する。

です。
実際に実装したのは、渡した建物のオブジェクトを返すメソッドです。

# 農場のリストを受け取り、リストの最初の農場を変数に代入している。
farm = world.buildings(buildings.farm)[0]

ここまでは時間を費やして動作しました。よいです。
そして実装前は、この実装が終わったら最低限の機能は実装し終わると思っていました。ただ、着手してみて課題がまだ残っているのに気付きました。

↓ これは移動まわりの実装なのですが、移動コマンドは NPC が移動完了するまで呼び出しが終わらない仕組みなのもあって、こんな風に仕組みが小難しくなっています。

この Lua で書かれたコードと同様の処理を Python で実装すればいい気はするのですが、本当にそうかとか、もっと楽でシンプルな実装がないかとかを考えてから着手したいので、続きは次回にやります。

まとめと今後の予定

ゲーム側から Python 側にデータを送る処理を実装して動作しました。よいです。
次回は、NPC を移動させるブロッキングなコマンド処理を検討して実現したいと思います。がんばります。

« 1 2 3 4 5 6 7

月別アーカイブ

限定特典から探す

記事を検索