Unit 3: 3D concepts for game play

I. Orientation: Gameplay Systems in a 3D Runtime

3D gameplay rests on a single loop: sample input, update simulation state, resolve collisions, render. Every system in this unit — the player controller, the terrain the player stands on, the agents that oppose them — plugs into that loop and must complete its work inside one frame budget (16.67 ms at 60 fps, 8.33 ms at 120 fps). Unity's MonoBehaviour callbacks and Unreal's Tick are the concrete hooks; the design constraints below apply to both.

Defining properties and conventions used throughout:

• Coordinate handedness: Unity is left-handed, Y-up; Unreal is left-handed, Z-up; Maya/OpenGL are right-handed, Y-up. Axis mismatch on import is the usual cause of a character walking sideways.
• Frame-rate independence: all continuous motion is scaled by deltaTime (seconds since last frame). A speed of 5f means 5 units/second, not 5 units/frame.
• Fixed vs variable timestep: physics runs on a fixed step (Unity default Time.fixedDeltaTime = 0.02 s, i.e. 50 Hz) so integration stays stable; input polling and camera run on the variable frame step.
• Unit convention: 1 world unit = 1 metre. A humanoid capsule is ~2 m tall, radius 0.3 m; gravity is −9.81 m/s².
• Determinism: procedural systems must be reproducible from a seed, so the same integer seed regenerates the identical world without storing it.
• Level of detail (LOD) and culling: anything generated or simulated must degrade with distance — mesh LODs, AI tick rates, terrain resolution.

II. Controller

A. Definition and Principle

A controller is the code layer that translates abstract input into constrained motion of an entity in the 3D world, mediating between raw device signals and the physics/animation systems.

• Input abstraction: a device axis is mapped to a named action, so "MoveForward" binds keyboard W, gamepad left-stick Y and touch joystick alike. Unity's Input System uses action maps; Unreal uses Input Actions with Enhanced Input.
• State ownership: the controller owns velocity, grounded flag, and orientation; the animator only reads these (or drives them in root-motion setups).
• Separation of concerns: possession model — a player controller holds input intent, the pawn/character holds the body. The same pawn can be driven by an AI controller instead, which is what makes AI-driven elements (Section IV) reuse movement code.

B. Types of Controller

Controllers differ mainly in how they resolve collision and who integrates the motion.

1. Kinematic (character-controller) movement: position is set directly each frame; collision is resolved by capsule sweeps and depenetration. Predictable, snappy, ignores external forces unless coded. Unity CharacterController.Move(), Unreal CharacterMovementComponent.
2. Dynamic (rigidbody) movement: forces or velocities are applied and the solver integrates. Physically consistent (pushed by explosions, slides on slopes) but prone to jitter and sluggish response.

• Camera-relative control schemes:
  • First-person: camera is the head; mouse X yaws the body, mouse Y pitches the camera only, clamped to ±85° to avoid gimbal flip.
  • Third-person free-look: input is transformed into camera space, then the mesh rotates toward the movement vector via Quaternion.Slerp.
  • Fixed/isometric: input maps to world axes regardless of view.
• Vehicle/flight controllers: add non-holonomic constraints — a car cannot strafe, so steering integrates heading before position, and lift/drag replace ground friction.

C. Implementation: Movement, Gravity, Jump

Ground movement composes a horizontal desired velocity with an independently integrated vertical velocity.

// Unity, kinematic third-person controller
Vector3 input = new Vector3(Input.GetAxis("Horizontal"), 0,
                            Input.GetAxis("Vertical")).normalized;
Vector3 dir   = cam.TransformDirection(input); dir.y = 0; dir.Normalize();

if (controller.isGrounded) {
    vSpeed = -0.5f;                                   // stick to slopes
    if (Input.GetButtonDown("Jump"))
        vSpeed = Mathf.Sqrt(2f * jumpHeight * 9.81f); // v = sqrt(2gh)
}
vSpeed -= 9.81f * Time.deltaTime;                     // Euler integration

Vector3 velocity = dir * speed + Vector3.up * vSpeed;
controller.Move(velocity * Time.deltaTime);

• Symbols: vSpeed = vertical velocity (m/s); jumpHeight = apex height (m); speed = planar speed (m/s); Time.deltaTime = frame duration (s).
• Why sqrt(2gh): from v² = 2gh, so a designer tunes an intuitive height (e.g. 1.5 m) instead of an arbitrary impulse.
• normalized on input: without it, diagonal input has magnitude √2 ≈ 1.414, making diagonal movement 41% faster.
• Slope handling: compare Vector3.Angle(hit.normal, Vector3.up) against a slope limit (typically 45°); beyond it, project velocity along the slope so the player slides.

D. Feel: Responsiveness and Game Feel

Feel comes from deliberately breaking strict physics.

• Acceleration curves: velocity = Vector3.MoveTowards(velocity, target, accel * dt). Low accel (~10 m/s²) reads as heavy; high (~60 m/s²) as arcade.
• Coyote time: allow jumping for ~0.1 s after leaving a ledge — forgives late input.
• Jump buffering: cache a jump press for ~0.15 s so a press just before landing still fires.
• Variable jump height: on button release while ascending, cut vSpeed *= 0.5f.
• Input smoothing vs input lag: smoothing removes stick noise but adds latency; total latency budget from press to photon should stay under ~100 ms.

III. Procedural Terrain Generation

A. Definition and Principle

Procedural terrain generation (PTG) synthesises landscape geometry algorithmically from a seed and parameters rather than authoring it by hand, trading artistic control for scale, variety and tiny storage cost.

• Core representation — the heightmap: a 2D scalar field h(x, z) sampled on a grid, rendered as a displaced plane. Cheap and easy to collide against, but cannot express caves or overhangs (each (x,z) has one height).
• Volumetric alternative: a 3D density field meshed with Marching Cubes, allowing caves and arches, at far higher memory and CPU cost.
• Chunking: the world is split into tiles (e.g. 256×256 vertices) generated on demand around the player and freed behind them, so the number of live vertices stays bounded.

B. Noise Functions as the Generator

Coherent noise gives smooth, repeatable pseudo-randomness — the raw material of terrain.

• Why not Random(): white noise is uncorrelated between neighbours, producing spikes. Perlin and Simplex noise interpolate gradients on a lattice, so nearby samples are similar.
• Fractal Brownian motion (fBm) / octaves: sum several noise layers at rising frequency and falling amplitude.

h = 0; amp = 1; freq = 1; norm = 0;
for (o = 0; o < octaves; o++) {
    h    += amp * Perlin((x + seed) * freq / scale,
                         (z + seed) * freq / scale);
    norm += amp;
    amp  *= persistence;   // ~0.5, controls roughness
    freq *= lacunarity;    // ~2.0, gap between octaves
}
height = (h / norm) * maxHeight;

• Parameter meanings: scale = feature size in world units (large scale ⇒ broad mountains); octaves (4–8) = detail levels; persistence < 1 = amplitude decay; lacunarity ≈ 2 = frequency multiplier; norm keeps output in [−1, 1].
• Shaping the result: apply a redistribution curve h' = pow(h, e) — e > 1 flattens valleys and sharpens peaks; ridged noise uses 1 − |noise| for mountain ridges; multiply by a radial falloff mask to make an island.
• Biomes: sample independent low-frequency moisture and temperature fields and index a biome lookup table, so texture, foliage and colour follow climate rather than height alone.

C. Other Generation Techniques

• Diamond–Square (midpoint displacement): on a 2ⁿ + 1 grid, repeatedly set midpoints to the average of neighbours plus decaying random offset. Fast, self-similar, but produces visible axis-aligned creasing.
• Hydraulic erosion: post-process that simulates droplets picking up and depositing sediment along the gradient; adds dendritic valleys that noise alone never produces.
• Wave Function Collapse / tile-based: for modular or dungeon-like spaces, propagates adjacency constraints — used where authored pieces must fit legally.
• Grammars and L-systems: rewrite rules generate roads, rivers and vegetation branching on top of the finished terrain.

D. Mesh Construction and Practical Concerns

The heightmap must become collidable, textured, seamless geometry.

• Vertex and triangle count: a w × h grid has w·h vertices and 2(w−1)(h−1) triangles — 256×256 gives 65,536 vertices and 130,050 triangles, which is why chunks are LOD-reduced.
• Normals: compute by central differences, n = normalize(cross(dx, dz)), where dx, dz are tangent vectors from neighbouring heights; wrong normals show as flat, unlit terrain.
• Seams between chunks: sample noise in world space, not chunk-local space, and overlap one row of vertices so edges match exactly; differing LOD across a boundary needs skirts or stitched edges.
• Performance: run generation on worker threads (mesh data only — Unity API calls must return to the main thread), and cache generated chunks to avoid regenerating on backtrack.
• Limitations: procedural output is uniform and lacks intent, so most shipped games use a hybrid — procedural base terrain with hand-placed landmarks and gameplay beats.

IV. AI-driven Game Elements

A. Definition and Principle

Game AI is not about intelligence but about the illusion of intent under a strict CPU budget: agents must appear to perceive, decide and act while being readable and beatable.

• Sense–think–act cycle: perception fills a world model, a decision layer selects a behaviour, an action layer drives the same movement component the player controller uses.
• Readability over optimality: telegraphed wind-ups, audible barks and deliberate inaccuracy exist so the player can learn the pattern.
• Budget: AI typically gets 10–20% of frame time, so distant agents tick at reduced rates (LOD for logic).

B. Decision-Making Architectures

• Finite State Machine (FSM): states (Patrol, Chase, Attack, Flee) with transition conditions. Transparent and cheap, but transitions grow as n² — unmanageable past ~8 states.
• Hierarchical FSM: nests sub-states (Combat → {Strafe, Reload}) to contain that growth.
• Behaviour Tree (BT): a tick-evaluated tree of Selector (first child that succeeds), Sequence (all children in order), Decorator (condition/inverter) and leaf Task nodes returning Success/Failure/Running. Modular and designer-friendly; the industry default.

Selector
├── Sequence [Decorator: CanSeePlayer?]
│     ├── MoveTo(player)
│     └── Attack
└── Patrol(waypoints)

• Goal-Oriented Action Planning (GOAP): actions carry preconditions and effects; an A search over world state builds a plan to reach a goal. Produces emergent tactics (F.E.A.R.*'s flanking) but is costly and hard to debug.
• Utility AI: each action scores itself with a curve over game state (score = healthDeficit × 0.7 + distanceFactor × 0.3); the highest scorer runs. Good for many soft, competing considerations, as in The Sims.

C. Pathfinding and Movement

Decisions produce a destination; navigation turns it into a walkable route.

• Navigation mesh: walkable surfaces are voxelised and simplified into convex polygons, far cheaper than a grid for open 3D space and it encodes slope, step height and agent radius.
• A*: expands nodes by f = g + h, where g = cost from start, h = admissible heuristic (Euclidean distance in 3D). Guaranteed shortest path when h never overestimates.
• Path smoothing and steering: raw corner-to-corner paths look robotic, so agents use string-pulling plus steering behaviours — seek, arrive, obstacle avoidance, and separation for crowds.
• Local avoidance: RVO (Reciprocal Velocity Obstacles) lets agents choose velocities that avoid mutual collision, preventing the classic doorway deadlock.
• Off-mesh links: jumps, ladders and doors are explicit edges the agent triggers with a bespoke animation.

D. Perception and Believability

Perception must be faked in a way the player can reason about.

• Vision cone test: dot product against forward vector for angle, distance check, then a raycast for line of sight — three cheap tests in that order to reject early.
• Awareness ramp: accumulate a suspicion value over time rather than switching instantly, and expose it via a UI meter or animation so stealth is learnable.
• Sound and memory: noise events register a last-known position; the agent searches there, which reads as intelligence but is a single stored Vector3.
• Group coordination: a lightweight blackboard or squad manager assigns roles (one flanks, one suppresses), avoiding the look of identical agents converging in a line.

E. Adaptive and Generative Elements

Beyond individual agents, AI shapes the session itself.

• Dynamic difficulty adjustment: tune spawn rate, enemy accuracy or resource drops from a running performance metric; Left 4 Dead's AI Director paces tension peaks and lulls.
• Machine learning agents: reinforcement learning (Unity ML-Agents, PPO) trains policies from reward signals — valuable for playtesting and for opponents in complex state spaces, but non-deterministic, expensive to train and hard to constrain.
• Procedural narrative and content: AI selects quests, encounter compositions or dialogue variants, tying Section III's generation directly to the difficulty and pacing model.