[進捗]２月の活動報告

こんばんは！

２月はついぞ１度も進捗ツイートができませんでした😇
実際、ゲーム本編の進捗もゼロです！

作業はしてるのにおかしいですねぇ…。

２月の活動報告

先月から引き続いてAWSの通信周りをずっと実装していました。

AWSの通信のベースシステムは去年の時点ですでに完成していたつもりでしたが、考えがあまあまでした……。

上旬：同期処理の修正続き

• ユーザーサイドの操作（例：ガチャの実行）
• サーバーサイドの処理（コストの消費＆結果の実行＆送信）
• ユーザーサイドの結果表示（ガチャ画面）

この１連の流れを確実に実行しなければなりません。

問題はサーバーサイドの処理までは実行され、通信エラーなどで結果を受信できなかった場合。

ガチャであれば最悪サーバー側できちんとアイテムの取得処理を行えたら問題ないでしょう。

しかし、スタミナを消費してコンテンツを開始するといった操作であれば、結果を受けてユーザー側でダンジョン突入処理を行わなければコストの払い損になります。

また、ガチャであっても通信エラーで結果が表示されずにもう１度ガチャを回してしまうと、意図せず複数回ガチャが実行されてしまいます。

ソシャゲなんて簡単に作れるだろ、と高をくくってましたが全くセオリーがわからない初心者にはなかなか厳しい…。

結局、眠れる勇者のRPGではこういった同期が必要な操作を汎用化し、

• ユーザーから同期処理のリクエスト送信
• サーバーでリクエストの処理
• サーバーで結果の保存＆送信
• ユーザーが結果を受けて必要な処理を実行
• ユーザーの処理が完了したことをサーバーに送信
• サーバーで保存していたリクエスト結果を削除

といった処理の流れにしました。

同期処理リクエストの通信と、結果完了通知リクエストの２回通信を行うことで完全に同期させることができる……はずです。

サーバーに処理結果が残っている状態で他のリクエストが飛んできても新規の処理は行わず、未処理の結果を返答してユーザー側で確実に実行されるまで新規操作をロックします。

さて、データ通信処理自体は実装して終わりなのですが、例えばダンジョンに突入しようとして「ガチャ結果が残っている」と通知されれば現在表示中のUIがどんな状態であれ、ガチャ結果表示を開始する必要があります。

「どんなUI状態であれ、どんな結果も実行させなければならない」と考えると割と大変です。

大変でした🤸‍♂️

同期処理のリクエストを汎用化し、

• 成功した場合に即時実行されるデータ処理
• 正しい流れで実行された場合のUI処理
• キャンセルされた場合のUI処理
• シーンを問わず実行される結果の開始処理

これらが確実に定義される状態にして実装漏れを防ぐことにしました。

キャンセルされた場合にはUI側に「残っていた他の処理の開始処理の実行ハンドラー」も渡されて必要に応じて実行させます。

例えばコンテンツが終わって報酬を処理する同期処理であれば、他の処理結果が残っていたとしてもキャンセルするわけにはいきません。

そういった場合には受け取ったハンドラーは実行せずに結果の表示命令だけスタックして保存し、結果は処理したものとしてサーバー側に通知し、報酬受取処理のリトライを行います。

かなり複雑な流れになりますが、ここ１年でPromiseを使った非同期処理や即時関数の扱いに慣れたおかげでなんとかまとめられました。

中旬：時間・期間限定のフラグ

時間・期間限定のコンテンツ、ショップセール、ガチャフェスなどはソシャゲではごく当たり前ですよね。

UI遷移のたびに通信してサーバー側でその時間にあったコンテンツをレスポンスするというのが簡単そうですが、なるべく通信は減らしたいところ。

眠れる勇者のRPGでは、サーバーとユーザーで共通して利用するスケジュール変数を導入しました。

変数ごとに期間と値がセットで、一意に値が決まるようになっています。

ただし、スケジュールデータは随時更新されるためユーザー側が保持しているデータが古い可能性が出てきます。

下旬：サーバー管理変数のキャッシュ

スケジュールデータのようにサーバー側が本体データを管理し、ユーザー側にキャッシュさせて自主的に判断させる場合には、ユーザー側のデータがリアルタイムに更新されずにずれる場合があります。

これも想定されるエラーケースが多岐に渡るため、汎用化して処理しないと実装漏れが生じそうなので大工事を施しました。

同期処理時に関連するキャッシュ変数をリクエストに付記しておき、間違った値であった場合には処理失敗のレスポンスと一緒に正しい値を返します。

ユーザー側は「端末上のデータが古かったため処理がキャンセルされました」など表示し、UI表示のリフレッシュなどを行います。

動画で見るとなんてことなさそうな処理なんですけどね……

当初はここまで厳密にエラー対処するつもりは無かったのですが、結局ここらを雑にするとリリース後のユーザーサポートに苦労するだろうと丁寧に作りなおしました。

通信に失敗してガチャ結果をバックグラウンドで処理させても良いけど、「石だけ減ってガチャできなかった」という問い合わせ対応がどうしても増えてしまいますからね。

リリース後に本編制作に時間を割けなくなるのも問題ですし、完結させたあともサ終させずに残したいのです。できるだけ手間をかけずにサービスを残せる基盤を整えておこうという判断で、２月もじっくりAWSまわりの処理と向き合ってました。

来月はクラファン作業の続きを集中してやる予定ですが、４月にはゲーム本編の制作に戻ってゴリゴリと進めていく予定です！

ツクラーでインディー界隈にも興味があると、Unityと違いツクールのスキルを磨いても潰しが効かないというモヤモヤを抱いたりしてしまいますが、自分は結果としてAWSでサーバーレス構成まわりのスキルを磨けたのはこれはこれで有りかなと思ってます。（LambdaをJavascriptで書けるのも大きいです）

今回作った基盤システムを使い回さないのは勿体ないので、次作以降でまたソシャゲライクにしたり、ユーザー間協力要素やPvPを入れたり、ゲーム以外でもSNSっぽいアプリも作れそうだったりと自分の創作における武器になりそうです。

……それはそれとして、「HD-2D」なRPGも興味あるのでやっぱりUnityもいつか触ることになりそうですけどね。