設計の狙いと、ローカル通信からオンラインへ
なぜこの企画なのか、どんな狙いで設計したか、どんな難所をどう越えたか——コンセプトの起点からオンライン化、プレイテストまでの記録。
出発点はひとつの問いでした——協力ゲームの面白さは、作業の上手さではなく「混乱を一緒にさばくこと」から生まれるのではないか。
だから企画の核を、飲み物を作る操作そのものではなく、分担・声かけ・優先順位付けに置きました。舞台に酒場を選んだのは、注文・製作・配膳・清掃・在庫といった作業が自然に増えていき、一人では抱えきれなくなるから。その「重さ」こそが、自然な手分けと会話を引き出す装置になると考えました。
設計の早い段階で、ゲーム全体の流れを図に起こしました。ゲーム起動からロビー、ソロかマルチかの選択、ルームへの入室、そしてゲーム本編へ——という大きな導線(フルラン構造)と、本編の中で一日ごとに回る営業ループ(デイリー・サービスループ)を、それぞれ分けて整理しています。
フルラン構造では、開店準備 → 営業 → 閉店処理 → 結果の振り返り、という一日の起伏が何日も積み重なって、ひとつの通しプレイになります。デイリー・サービスループでは、客が注文を出し、必要な飲み物を判断し、操作やミニゲームで仕上げ、正しい客へ届ける——この循環が時間とともに密度を増していきます。
ソロとマルチプレイは同じ基本の遊びを共有しますが、生まれるプレッシャーの種類は意図的に変えています。ソロは一人で全部を抱える——優先順位付け、店内の動線、時間管理が中心になります。
マルチプレイでは、プレッシャーの源を「作業量」から「息を合わせられるか」へ移しました。誰が準備し、誰が配膳し、誰が接客や閉店処理を担うか——協力が明確か、声かけが機能するかが、面白さの中心になります。
ロビーやカスタム飾り、絵文字は、複雑な機能ではなく「個性を出せること」と「ふざけて笑えること」を狙ったシンプルな仕組みです。本編が始まる前から空気を温め、混雑する営業中の会話量や雰囲気にもつなげることが目的でした。
最初は Unity の Netcode でローカル通信だけを確認し、遊びの骨格を固めました。次の段階で、Rust などで知られる Facepunch の Steamworks プラグインを導入し、Steam のフレンド・ロビー・リレーを前提にした接続へ広げました。
実際の流れはこうです。まず Steam に接続し、ホストになるかルームに参加するかを選ぶ。参加側は Steam のフレンドリストから入れる部屋を探せます。ロビーでは参加者一覧と準備状況を確認でき、退出も可能。全員が準備完了になるとホストがゲームを開始し、終了後はホーム画面へ戻ります。
ローカル通信だけの段階では、複数人が別々の環境で遊んだときの待ち時間・準備・切断・会話量・混乱の質を観察できませんでした。
Facepunch Steamworks を導入し、フレンド招待・ロビー・リレー接続を前提にしたオンラインの流れを実装。自宅 Wi-Fi と別回線の端末をつなぎ、ローカルではない実接続を試しました。
初めて Steam 経由のオンライン接続に成功。これ以降、QAテストやプレイヤー間のやり取りの観察が現実的になり、開発速度が大きく上がりました。
酒場の混乱をそのまま遊びにすると、テンポを壊して理不尽になる危険がありました。混乱を楽しさへ変える具体的な仕掛けが必要でした。
酔い倒れた客を追い出し、ついでに「合理的に」清掃費を回収する、といった追加メカニクを試作。混乱とコメディを、罰ではなく小さな見せ場に変えることを狙いました。
チームメンバーや友人とのプレイテストで、こうした要素が営業のリズムを壊すのか、それとも記憶に残る瞬間になるのかを継続的に検証しています。
マルチプレイが成立してからは、チームメンバーや友人と積極的にプレイテストを重ねています。複数人で遊んで初めて、やり取り・会話・分担・支え合い・混乱の伝わり方が見えてくるからです。