集まって、遊んで、もう一戦。参加の流れを設計する

ルーム参加までの操作を少なくする

友だちと遊ぶ約束をしていても、全員が同じ操作に慣れているとは限りません。最初のMVPでは、ホストがルームを作り、参加者がコードと表示名を入力する流れを予定しています。登録やメール確認を先に求めず、同じ部屋に到着するまでの手順を少なくする方針です。

表示名はあくまでその場の呼び名です。本名や連絡先を求める必要はありません。一方、登録を省略しても、不正な操作への対策を省略できるわけではありません。ルームへの参加可否や人数はサーバー側で判断する必要があります。

ルーム画面では、誰が参加しているか、あと何人必要か、開始できる状態かを明確にする予定です。開始直後に説明を読めていない人が取り残されることを避けるため、準備完了の扱いも検討します。

コードを何度も入力したときに二重参加にならないこと、同名の参加者を区別できること、開始後に入ってきた人をどう扱うか。こうした境界は、実装前に整理しておく必要があります。

予定している流れは、役割の通知、ミニゲーム3回、投票、結果発表、再戦です。投票中に別の画面へ移ったり、誰かが再接続したりしても、全員の現在地が食い違わないようにします。

役割、残り時間、集計済みの投票結果は、各ブラウザが独自に決めるものではありません。サーバーが進行を管理し、参加者には必要な情報だけを渡す方針です。妨害役の情報を全員へ送って画面で隠すだけでは、秘密にはなりません。

モバイルでは画面の切り替えや通信環境によって接続が不安定になることがあります。切断をただちに敗北や妨害と見なすと、ルールと通信の事情が混ざってしまいます。

再接続の待ち時間、復帰できなかった場合の試合終了、途中参加の可否は未確定です。今後の試作では、通常の流れと同じくらい、切断や戻る操作を含む流れを検証します。

再戦時には同じメンバーを引き継いでも、役割や投票状態、試合IDをリセットする必要があります。前の試合の操作が次の試合に混ざらないことも確認します。

広告を導入する場合の候補は、結果を確認した後です。広告が表示できなかった場合も再戦へ進める構成を考えています。現在、ゲームと本番広告は未実装です。