Skip to main content

Final Mockup and Feature Plan

The final mockup should present the full vision of the game as a cooperative multiplayer horror-management experience. Players run a strange late-night restaurant in the middle of space, manage customer orders, survive supernatural events, communicate as a team, and upgrade their equipment between shifts.

The most important goal is to make the core gameplay loop playable:

  1. Create or join a lobby.
  2. Start a shift together.
  3. Accept and complete food orders.
  4. Survive horror events and dangerous situations.
  5. Earn money from completed orders.
  6. Return after the shift to buy upgrades.
  7. Begin the next, harder shift.

The game needs a complete main menu created with Unity UI Toolkit. The menu should match the dark, stylized visual theme of the game and immediately communicate the strange horror-restaurant atmosphere.

The main menu should feel simple, readable, and atmospheric. It should use Barlow Condensed as the main font, except for the game title if a different title style is used.

Required Menu Options​

  • Create Lobby
  • Join Lobby
  • Lobby Code Input Field
  • Settings
  • Quit Game

Visual Style​

When the player hovers over a menu button, the selected option should become highlighted. A small dash, marker, or symbol should appear next to the hovered option to make the menu feel more interactive and polished.

Example hover behavior:

  Create Lobby
- Join Lobby
  Settings
  Quit Game

The menu should support both mouse input now and controller navigation later.

Lobby System​

The lobby system should allow players to create and join multiplayer sessions using the existing PurrNet and Steam lobby setup.

The LobbyManager should handle the lobby logic, while the Steam connector should handle Steam hosting, joining, and invite behavior.

Required Lobby Features​

  • Create Steam lobby
  • Generate and display lobby code
  • Join lobby by code
  • Join through Steam invite
  • Display current players in the lobby
  • Allow only the host to start the game
  • Keep the NetworkManager persistent between scenes
  • Load from the lobby scene into the game scene correctly

Lobby UI Requirements​

The lobby screen should show:

  • Lobby code
  • Player list
  • Host indicator
  • Start game button for the host
  • Ready/status display if needed later
  • Back or leave lobby button

The player list should be generated dynamically from the current lobby data instead of being hardcoded in UXML.

Tablet UI​

The tablet is the main in-game interface. It should open when the player presses a key, for example Tab, and appear in the middle of the screen.

When the tablet is open:

  • Mouse cursor should unlock.
  • Camera movement should be disabled.
  • Player menu navigation should be active.
  • The player should be able to close the tablet and return to gameplay.

Tablet Tabs​

The tablet should include different tabs or folders:

  • Orders
  • Shop
  • Upgrades
  • Settings / Info

Orders Tab​

The order system should show all current orders in a grid or list. Orders should stay visible after being accepted and should only change their status instead of disappearing.

Example Order States​

  • New
  • Accepted
  • In Preparation
  • Ready
  • Delivered
  • Failed

The tablet should also be structured in a way that supports controller navigation later.

Order System​

The order system is one of the most important gameplay systems. It defines the main work players must complete during each shift.

Required Order Features​

  • Generate random orders
  • Show orders on the tablet
  • Allow players to accept orders
  • Keep accepted orders visible
  • Change order status instead of deleting the order
  • Reward players for completed orders
  • Penalize players for failed or late orders
  • Sync order states for all players in multiplayer

Orders should only start after the Game Scene is loaded. They should not start in the Bootstrap Scene or Lobby Scene.

Order Flow​

New → Accepted → In Preparation → Ready → Delivered

If the order timer runs out or the task fails, the order should change to:

Failed

Multiplayer Order Sync​

All players should see the same order list and the same order states. When one player accepts or completes an order, the tablet UI should update for every player.

Multiplayer Interaction​

Players should be able to interact with objects in the world. These interactions need to work reliably in multiplayer and should be synchronized correctly between host and clients.

Required Interactions​

  • Pick up items
  • Drop items
  • Push physics objects
  • Open and close doors
  • Interact with equipment
  • Use the tablet
  • Complete order-related tasks

Important Multiplayer Rules​

  • Door states must sync between host and clients.
  • Rigidbody objects must be synced correctly.
  • Clients should be able to push objects, not only the host.
  • Interactions should be server-authoritative where needed.
  • Objects should not teleport or receive duplicated force on clients.

The goal is that every player feels like they can interact with the world naturally, while the host/server keeps the final object states consistent.

Player Controller​

The player controller should support smooth first-person movement and reliable interaction with the world.

Required Player Features​

  • Walking
  • Looking around
  • Jumping if needed
  • Interaction raycast
  • Pushing Rigidbody objects
  • New Input System support
  • Mouse locking and unlocking when opening UI
  • Camera movement disabled while tablet or menu is open

The controller should work reliably in multiplayer and should not cause the player to fall through the map.

Interaction Behavior​

The player should use a raycast from the camera to detect interactable objects. Depending on the object type, the player can pick it up, open it, push it, use it, or trigger an order-related action.

Voice Chat​

Voice chat should allow players to communicate during gameplay. Since communication is important for cooperative horror gameplay, the system should be clear, adjustable, and reliable.

Required Voice Chat Features​

  • PurrVoice integration
  • Voice chat between players
  • Adjustable microphone volume
  • Noise gate or sensitivity settings
  • Option to reduce keyboard and background noise
  • Settings saved between sessions

Voice chat should be tested with cloned clients. If the cloned client voice is too quiet, the microphone gain, output volume, and voice settings should be adjusted later.

Settings System​

The game needs a settings menu that saves player preferences between sessions.

Settings can be saved using PlayerPrefs or a custom save system. For the mockup, PlayerPrefs is enough. A custom save system can be added later if settings become more complex.

Settings to Implement​

  • Master volume
  • Voice chat volume
  • Microphone sensitivity
  • Mouse sensitivity
  • Graphics quality
  • Fullscreen mode
  • Resolution
  • Controls

Settings should remain the same after closing and reopening the game.

Scene Flow​

The project should use a clean scene structure so networking, menus, lobbies, and gameplay do not conflict with each other.

Bootstrap Scene → Main Menu Scene → Lobby Scene → Game Scene

Bootstrap Scene​

The Bootstrap Scene should contain persistent systems such as:

  • NetworkManager
  • Steam / PurrNet connection setup
  • Global managers if needed

The Bootstrap Scene should not start gameplay systems like orders, enemies, or level events.

The Main Menu Scene should contain the main menu UI and allow players to create or join a lobby.

Lobby Scene​

The Lobby Scene should show the current lobby, lobby code, connected players, and the start game option for the host.

Game Scene​

The Game Scene should contain the actual playable level, including:

  • Order system
  • Restaurant equipment
  • Interactable objects
  • Horror events
  • Player spawning
  • Shift timer
  • Level-specific managers

Gameplay systems should start only once the Game Scene is fully loaded.

Upgrade and Shop System​

After each shift, players should be able to spend earned money on upgrades. These upgrades should help them survive longer and complete orders more efficiently in later shifts.

Possible Upgrades​

  • Faster cooking equipment
  • More order slots
  • Better tools
  • Stronger flashlight
  • Larger inventory
  • Improved doors or defenses
  • Voice or radio upgrades
  • Restaurant decorations

The shop should be accessible through the tablet or through a separate upgrade menu between shifts.

Horror and Event System​

To make each shift more intense, random events should happen during gameplay. These events should become stronger and more frequent as the shift progresses.

Possible Events​

  • Lights flicker or turn off
  • Doors lock randomly
  • Objects move by themselves
  • Strange customers appear
  • Equipment breaks
  • Enemy enters the restaurant
  • Loud noises distract players
  • Fake orders appear
  • Time pressure increases

Event Progression​

At the beginning of a shift, events should be small and mostly atmospheric. Later in the shift, events should become more dangerous and directly affect the players' ability to complete orders.

Example progression:

Early Shift: Flickering lights, strange sounds, small object movement
Mid Shift: Equipment problems, fake orders, doors locking
Late Shift: Enemy attacks, heavy time pressure, major power failure

Final Mockup Scope​

The final mockup should demonstrate the complete direction of the game without needing every system to be fully finished.

The Mockup Should Demonstrate​

  • Main menu design
  • Lobby creation and joining
  • In-game tablet UI
  • Order management
  • Multiplayer interaction
  • Basic horror atmosphere
  • Upgrade and shop concept
  • Working scene flow from menu to gameplay

Core Gameplay Loop​

The playable mockup should focus on the core loop first. This is the most important part of the project.

Create Lobby
↓
Start Shift
↓
Accept Orders
↓
Prepare and Deliver Food
↓
Survive Horror Events
↓
Earn Money
↓
Buy Upgrades
↓
Start Next Shift

The game should feel like a mix of restaurant management, cooperative chaos, and horror survival. Players are not only fighting against time and customer demands, but also against the strange world around them.

Development Priority​

To keep development focused, the systems should be built in this order:

Priority 1: Core Flow​

  • Bootstrap to main menu
  • Main menu to lobby
  • Lobby creation and joining
  • Lobby to game scene
  • Persistent NetworkManager

Priority 2: Gameplay Core​

  • Player controller
  • Interaction system
  • Tablet opening and closing
  • Basic order generation
  • Accepting and completing orders

Priority 3: Multiplayer Sync​

  • Synced player list
  • Synced order states
  • Synced doors
  • Synced physics objects
  • Client interaction support

Priority 4: Game Feel​

  • Main menu polish
  • Tablet visual polish
  • Horror events
  • Audio and voice chat tuning
  • Settings saving

Priority 5: Progression​

  • Money rewards
  • Failed order penalties
  • Shop system
  • Upgrade system
  • Shift difficulty scaling

Final Vision​

The final vision is a cooperative horror restaurant game where players are trapped in a never-ending shift at the edge of existence. They must take orders, prepare food, deliver meals, clean up chaos, survive supernatural events, and use their earnings to improve their chances in the next shift.

The game should be funny, stressful, scary, and chaotic. The restaurant may be floating through the remains of Earth, but the customers are still hungry, the equipment is still broken, and the shift is not over.

The end of the world did not cancel work.

It only made the job worse.