この記事の3行まとめ
- QualiArts、『タスクキルを救う!安定動作を支える「中断再開」の仕組み』と題したブログ記事を公開
- タスクキル発生時にゲームを途中再開させる仕組みについて、仕様策定の考え方や実装事例などを解説している
- 複数端末でログインする際の挙動や、セッションが新規開始か途中再開かを判定する手法などを語っている
QualiArtsは2025年10月31日(金)、『タスクキルを救う!安定動作を支える「中断再開」の仕組み』と題した記事を、自社ブログにて公開しました。
タスクキル発生時に中断箇所からゲームを再開する仕組み(記事中では「中断再開」と呼称)を実装するにあたって、注意点や同社の実装事例などを解説しています。
(画像はブログ記事より引用)
同記事では、クライアント・サーバーが連携して処理を行うゲームを前提とした「中断再開」の実装手法を解説しています。
たとえば1日1回のみ挑戦できるミニゲームの場合、ゲームが終了するタイミングで「プレイ済」と判定する仕様にすると、フラグが立つ前にリセットすることで何回でも再挑戦できる不正を許してしまいます。一方で、ゲーム開始と同時に「プレイ済」のフラグを立てると、意図しない強制終了によって再挑戦の権利を失う事故を防げなくなります。
いかなるタイミングでもタスクキル直後からゲームを再開可能とするために、タスクキル時点におけるゲーム状況を保存し、再起動後に復元する実装が必要となります。
(画像はブログ記事より引用)
「中断再開」の仕様を策定する上で、同社はまず状態遷移の様子を簡略図や箇条書きで単純化し、どの情報がどのタイミングで確定するのか(編成やスコア、ユーザーの順位など)を念頭に置きながら、中断箇所に応じた再開地点を決定します。
複数端末から同一アカウントにログインする挙動についても解説。全てのパターンを網羅するのは現実的ではないため、主に「中断状態が存在するか否か」で分岐を実行。別端末から再開する際はサーバーからデータを送付し、再開不可能の場合は上書き処理を行います。
また、複数端末での中断状況の行き違い・矛盾などを防止するために同じセッションを並行して複数端末で進めないことや、キャラクターの性能変更やイベント終了といった外的要因に伴う再開不可能の事態を検知し、中断状況を強制破棄する仕組みを作ることなどが安全策だと述べています。
(画像はブログ記事より引用)
策定した仕様をもとに状態遷移を実装。状態遷移は主にサーバーのAPIをクライアントから実行させることで進行します。
記事中では、ゲームの中断状況をサーバー・クライアントのどちら側に保存するべきか見解を述べているほか、セッションか新規開始されるものか・途中から再開されるものかを判定する方法として、サーバーとクライアントでセッションIDを発行し、IDの一致・不一致と中断データ所持・非所持のパターンで区分する仕組みを紹介しています。
セッション開始時、サーバーおよびクライアントの双方が同じセッションIDを所持。セッションを破棄するタイミングでIDを空文字にする(画像はブログ記事より引用)
サーバー内に中断データが存在するか・しないか、IDの文字列がクライアントとサーバーで一致するか・しないかの2種類のフラグにより、全てのパターンを網羅する(画像はブログ記事よりスクリーンショットで引用)
また、状態遷移や再開に関する処理をゲーム本体の処理とは独立させて実装する考え方やその具体的な実装例のほか、クライアント側・サーバー側でそれぞれ保存しているデータを同時に更新する際、片方だけ失敗したケースを想定した実装手法を解説。
そのほか、リリース前に手動でデバッグを行っていることや、一連の実装・運用に対する所感などが語られています。
詳細はブログ記事をご確認ください。
タスクキルを救う!安定動作を支える「中断再開」の仕組み | QualiArts engineer blog