as down--- title: “Found Footage FPS: Survival & Extraction Architecture” description: “Game design logic for handling non-diegetic pause states, multiplayer-aware UI, and asymmetric co-op ‘Handler’ systems.” date: “2024-08-31” project: “Found Footage FPS” shelf: games layout: ”../../layouts/Layout.astro” tags: [“Game Design”, “Unity”, “Systems Architecture”, “UI/UX”, “Level Design”, “Mechanics”, “Extraction”, “Multiplayer”, “State Machines”, “Asymmetric Co-op”]

Found Footage FPS

Category: Systems Architecture & UI
Context: Designed as a more focused, lower-scope iteration of ideas originating in Project Longbow, Found Footage FPS strands players in a highly adversarial, dark fantasy world. Inspired by Stargate, the primary objective is to endure hostile environments until an extraction window opens.

In sharp contrast to the diegetic, tablet-based UI of Project Longbow (which never paused the game), Found Footage FPS employs a stylized, non-diegetic “camera feed” UI paired with robust multiplayer-aware network states.

Prototype & Loop Tests

To see the adversarial extraction loop and the specific Found Footage UI rendering in action, watch the initial prototype tests:

(Extraction Shooter Loop Test)

(Specific Found Footage UI & Non-Diegetic GUI Test)

Raid State Machine & AWOL Flow

The entire session lifecycle is governed by a strict finite state machine. The diagram below shows the full flow from lobby through extraction, including the AWOL penalty branch and the asymmetric co-op architecture.

Asymmetric Cooperative Architecture: The “Handler” View

The core of the multiplayer experience is an asymmetric split between the Host (FPS Player) and the Client (Handler).

1. The Host (Boots on the Ground)

The host is physically present in the game world, viewing the simulation through a bodycam-style filter. They are responsible for the physical navigation and combat within the dark, hostile environment.

2. The Handler (CompanionView)

The client acts as a “Handler” or “Companion,” viewing the raid through a dedicated CompanionView terminal. This view is not a standard camera; it is a high-level operations deck that provides situational awareness the host lacks.

• Additive Scene Loading: Because Unity clients cannot traditionally load scenes in a Netcode for GameObjects setup, the host loads the CompanionView scene as an additive layer upon the client’s arrival.
• Information Relay: Crucial data—including the live “Bodycam” feed, the ObserverMap, and sensor readouts—is relayed from the host to the client terminal.

Initial mockup of the Handler’s operations terminal.

3. The Command Terminal

To interact with the host, the Handler uses a Command Terminal. This system was designed to allow the client to influence the host’s world through text-based “Command Plugins.”

• Logic: The system uses a Dictionary-based command lookup where string inputs (PING HOST, THROTTLE FEED) map to specific methods.
• Example Loop: A PING HOST command triggers an update on the host’s HUD, highlighting critical targets or items identified by the Handler’s superior sensor suite.
• Dynamic Interference: The reliability of the connection (the “Bodycam” feed) is designed to be throttled or degrade over time, forcing the Handler to manage connection stability as an additional resource.

4. Technical Component Stack

The Handler architecture relies on several interlocking scripts:

• CompanionManager: Orchestrates the data flow between the network manager and the Handler UI.
• CompanionPlugins: Modular logic containers for different terminal commands.
• ObserverMap: A specialized map component attached to the Player Prefab that translates world-space entity positions into terminal-space coordinates.

Solo Play vs. Co-op UI States

The UIMainController intelligently handles time manipulation based on the connection state:

1. Solo Play: If ConnectedClientsIds.Count <= 1, pulling up the menu physically pauses the world (Time.timeScale = 0). The lone player is safe to review extraction information.
2. Co-op Play: If multiple players are connected, time continues to run (Time.timeScale = 1). The Handler must actively guide and cover the Host while the Host checks objectives. This creates a trust dynamic: the Host is vulnerable every time they open the menu, and the Handler’s competence directly determines whether that vulnerability is punished.

Raid States and AWOL Penalties

The global GameManager operates the state machine transitioning through Setup, InRaid, RaidEnd, and Results. Extraction is not guaranteed — it must be survived.

If a player attempts to quit via the UI during an active raid, the controller intercepts the action through OnQuitButtonPressed():

• InRaid quit: The player is flagged as AWOL (HandleAWOL()). The network connection is severed, and the GameManager forces a punitive data reset before kicking the player back to the main menu.
• Setup or RaidEnd quit: Clean exit via HandleNormalExit(). No penalty.

Extraction Trigger Flow

Extraction follows a high-stakes holdout pattern:

1. Extraction window opens — LevelManager enables the zone after objectives are met.
2. Player enters trigger radius — The extraction timer begins.
3. Hold position — The player must survive in the zone for the full duration. Leaving resets the timer.
4. Extraction succeeds — State transitions to RaidEnd, data and loot are preserved.

Extraction Resources