Game Design Document

IDrive Game Design

IDrive is an asymmetric cooperative tank-combat prototype where a crew of up to four players occupies one armored vehicle, takes distinct seats, and coordinates observation, driving, turret alignment, and gun handling until the map is clear.

The Game Design Document material covers the high concept, experience goals, design pillars, player fantasy, session loop, role responsibilities, controls, combat rules, environment, UI, audiovisual direction, and product summary.

Design Spine Crew Roles Combat Rules

High Concept And Experience Goals

Design Spine And Player Experience

The core idea is the split of one vehicle across multiple players. Each player sees different things, controls different subsystems, and has to communicate because no single seat owns the whole tank.

Crew Coordination Coordination should feel necessary rather than optional because driving, spotting, and firing are split across different people.

Distinct Seats Every role needs different camera context, inputs, UI, and responsibilities so seat choice changes how the tank reads.

Simple But Tense The combat loop should be immediately understandable, while missed communication should slow the entire crew down.

Strong Feedback Thermal viewing, muzzle flash, engine and track audio, ambience, and heavy explosions make the battlefield legible.

Design Pillars

Crew dependency: no player owns the whole tank, so the crew must coordinate movement, observation, and weapon use.
Readable battlefield awareness: role cameras, canvases, crosshairs, map-marking objects, and commander thermal presentation create a hierarchy of information.
Physical weapon handling: firing is not rapid-click shooting, because the cannon requires manual reload time before the next shot.
Short-session prototype structure: the current scenario is a contained round with one implemented win state, destroying every enemy tank in the scene.

Player Fantasy

The crew fantasy is strongest when players call targets, align the tank under pressure, and confirm the reload before taking the shot. The driver moves the hull, the spotter aligns the turret, fire control handles loading and firing, and the commander serves as oversight, situational awareness, and tactical coordination.

Core Gameplay Loop

From Connection To Battlefield Clear

The current loop is intentionally direct: connect, claim a seat, use the role-specific camera and UI, coordinate the shared tank, destroy patrol armor, and resolve the match for every connected player.

Start Session

Start as client, host, or dedicated server through the connection UI.

Claim Role

Join the session and claim an open Commander, Driver, Spotter, or FireControl seat.

Observe Locally

Observe the battlefield through the role camera and associated UI.

Coordinate Movement

The driver repositions the tank while the spotter aims the turret.

Handle Gun Cycle

Fire control fires, holds reload for the three-second reload cycle, watches reload progress, and confirms when the next shell is ready.

Destroy Targets

Projectile hits destroy enemy tanks with explosive breakup and audio feedback.

Resolve Outcome

Repeat until no enemy tanks remain, then the network outcome manager shows the win state for all players.

Roles And Controls

Four Crew Roles, One Shared Vehicle

The current default controls overlap across roles, but this is acceptable in multiplayer because each client only sends inputs for the assigned role. A future pass should make the seat boundaries more explicit in the user-facing UI.

Commander

The commander is currently an information and coordination role. Scene objects include a Commander Camera, CommanderCanvas, Commander Map Marking object, and Commander Thermal Global Volume, but there is not yet a dedicated commander input script.

Driver

The driver owns hull movement only: forward and reverse throttle, steering, and braking. In the network version, movement authority runs on the server.

W/S throttle A/D steer Space brake Arrow key support

Spotter

The spotter acts as the gun-layer or turret tracker. This seat controls turret yaw and pitch, lines up shots, and does not directly fire the shell.

W/S pitch A/D yaw Arrow key support

Fire Control

Fire control handles the cannon rhythm: fire, reload, confirm loaded, and fire again. This gives the seat the clearest direct performance loop.

Space fire Hold R reload Three-second reload

Combat, Interface, And Mood

Ruined Armor Sandbox

The active battlefield is a ruined urban or industrial combat zone built from terrain, ruins, poles, scaffolding, decals, environmental clutter, airwalls, separated viewpoints, and role canvases that support role-play inside the same space.

Enemy And Attack Rules

The primary hostile is the enemy tank; the main scene currently contains thirteen enemy tank instances.
Enemy tanks patrol with NavMesh movement until struck by a projectile.
Reload completes over three seconds by holding the reload input.
Fire spawns a projectile from the barrel fire point.
The projectile travels forward at high speed and despawns after a limited lifetime.
On collision, the projectile spawns an impact effect and can trigger the enemy tank explosion sequence.
Enemy destruction stops navigation, disables patrol behavior, activates explosion visuals, plays sound, applies breakup force, and removes the networked enemy object after a short delay.
The implemented win rule checks when all non-exploded enemies tagged as Enemy are gone.
The lose rule is scaffolded through UI and outcome support, but no complete automatic gameplay trigger was found in the current project review.

Encounter Feel

Encounter design is attrition-based rather than tightly scripted. Enemy tanks patrol within a range, wait, choose new destinations, and become targets of opportunity, creating a roaming search-and-destroy rhythm.

The audiovisual style is practical prototype realism. Heavy environment art packs, background music, tank-engine and track sounds, explosion sounds, large detonation effects, muzzle flash, and a commander thermal post-process path create tense battlefield observation rather than stylized arcade spectacle.

Connection And Role UI Players can enter IP and port, start as Client, Host, or Server, and claim open crew seats after connection.

Role Presentation Commander, Driver, Spotter, Fire Control, and Normal canvases pair with local role cameras.

Combat Feedback Crosshair, ReloadProgress, muzzle flash, projectile impact, explosion visuals, sound effects, and outcome text reinforce the combat loop.

Product Summary

IDrive is a cooperative asymmetric tank-crew combat prototype in which up to four players share one vehicle, coordinate distinct crew roles, and clear a ruined battlefield of roaming enemy armor.

Next Related Page

The game design page explains the intended player experience. The system design page explains how the Unity 6 multiplayer architecture supports that experience.