Unit 3: 3D concepts for game play - Subjective Questions

A 3D game controller is a software component that converts player input into meaningful actions performed by a character, vehicle, camera, or other game object.

Its main responsibilities include:

• Input processing: Reads input from a keyboard, mouse, gamepad, touch screen, or motion controller.
• Movement calculation: Converts input into movement vectors, speed, acceleration, and rotation.
• Physics interaction: Applies forces, velocity, gravity, and collision constraints through the physics engine.
• State management: Tracks states such as idle, walking, running, jumping, falling, and attacking.
• Animation coordination: Selects and blends animations according to movement and gameplay state.
• Camera coordination: Ensures that movement directions remain consistent with the camera orientation.

A well-designed controller should be responsive, predictable, frame-rate independent, and compatible with the rules of the game world.

A camera-relative controller interprets movement input according to the camera's horizontal orientation.

For a two-dimensional input vector , the desired world-space direction is:

where:

• is the camera's right vector projected onto the ground plane.
• is the camera's forward vector projected onto the ground plane.
• is horizontal input.
• is vertical input.

The result is normalized when its magnitude exceeds :

The displacement for speed and frame time is:

The character may then rotate gradually toward . Projecting the camera vectors onto the ground prevents the character from moving vertically when the camera looks upward or downward.

A kinematic controller moves a character through explicitly calculated positions or collision-aware movement commands. A rigid-body controller moves the character by applying forces, impulses, or velocity through a physics simulation.

Kinematic controller:

• Provides precise and predictable movement.
• Makes slopes, steps, and platforming easier to control.
• Usually requires custom gravity and collision-response logic.
• Is less naturally affected by explosions, pushes, and other physical objects.

Rigid-body controller:

• Produces physically reactive movement.
• Interacts naturally with forces, momentum, and movable objects.
• Can be harder to tune for responsive gameplay.
• May suffer from sliding, bouncing, tipping, or unstable collision behavior.

Kinematic controllers are common in precision-oriented games, while rigid-body controllers suit gameplay where physical interaction is central. Hybrid designs may combine kinematic movement with selected physical reactions.

Jumping requires a reliable grounded test, an initial upward velocity, and continuous gravity.

• Ground contact can be detected using a ray cast, sphere cast, capsule cast, or collision-contact normals.
• A jump is permitted when the character is grounded and the jump input is accepted.
• The initial vertical velocity required to reach jump height under gravitational magnitude is:

• During every frame, vertical velocity is updated as:

• Vertical displacement is then included in the controller's movement calculation.
• On landing, negative vertical velocity is reset or clamped to a small downward value so the controller remains attached to the surface.

Robust systems also include coyote time, jump buffering, slope checks, and protection against false grounded states on walls or ceilings.

Frame-rate independence ensures that movement behaves consistently on different hardware. A velocity-based displacement should include frame time:

Without , a player running at a higher frame rate would move farther per second.

Acceleration controls how quickly current velocity approaches target velocity. It avoids an unrealistically immediate transition from rest to full speed. A simplified update is:

Damping reduces velocity when input is released and can model friction or drag. Together, these parameters determine whether movement feels sharp, heavy, slippery, or smooth.

For responsive gameplay, ground acceleration is often high, stopping is controlled, and air acceleration is lower. Physics updates should normally occur at a fixed time step, while input may be sampled every rendered frame.

A controller must distinguish navigable surfaces from obstacles.

• Slope handling: The surface normal is compared with the world's up vector. If is the slope angle, then:

A surface is walkable when does not exceed the configured slope limit.

• Movement projection: Desired movement can be projected onto the surface plane so the character follows the slope instead of entering or leaving it unexpectedly.
• Step handling: A step offset allows the collision shape to move over obstacles below a maximum height.
• Collision response: The component of velocity directed into a wall is removed, allowing the character to slide along the wall.
• Ground adhesion: A short downward cast or controlled downward force keeps the character attached to descending terrain.

These mechanisms reduce jitter, prevent wall climbing, and provide stable movement across uneven 3D environments.

A controller commonly represents behavior through states such as idle, walk, run, jump, fall, land, and attack. Transitions are triggered by input and gameplay conditions, including movement speed, grounded status, and vertical velocity.

Animation parameters are derived from controller data:

• Speed controls blending between idle, walking, and running.
• Local horizontal and forward velocity drive directional blend trees.
• Vertical velocity helps select jumping or falling animations.
• A grounded Boolean triggers landing transitions.
• One-time events trigger attacks or interactions.

Animation blending creates smooth transitions instead of abruptly replacing one animation with another. In root-motion systems, animation displacement drives movement. In code-driven systems, controller velocity drives movement and animation visually follows it. Synchronization is essential to prevent foot sliding, delayed turns, and visual motion that disagrees with collision movement.

Procedural terrain generation is the algorithmic creation of terrain geometry, height, materials, vegetation, and environmental features from mathematical functions, rules, and random seeds.

Advantages:

• Produces large or effectively unlimited environments.
• Reduces the amount of manually authored terrain data.
• Supports replayability through seed-based variation.
• Allows terrain to be generated at runtime or in editor tools.
• Makes it possible to reproduce a world by storing only its seed and parameters.

Limitations:

• Generated terrain may appear repetitive or unnatural.
• Important gameplay locations are difficult to guarantee without constraints.
• Runtime generation may consume substantial CPU time and memory.
• Navigation, object placement, and multiplayer synchronization become more complex.
• Poor parameter selection can create inaccessible or unfair areas.

Effective systems combine procedural variation with designer-authored rules, validation, and selected handcrafted landmarks.

A heightmap stores one height value for every point in a two-dimensional grid. For grid coordinates , a vertex can be created as:

where is the sampled height, is the vertical scale, and and are horizontal spacing values.

The mesh-generation process is:

• Sample or calculate a height for every grid point.
• Create one vertex at each calculated position.
• Connect each grid cell using two triangles with consistent winding order.
• Calculate normals from neighboring triangles or height gradients.
• Generate texture coordinates from normalized grid coordinates.
• Add collision data when gameplay requires physical terrain interaction.

A grid containing vertices has cells and therefore:

triangles.

Uncorrelated random noise assigns independent values to nearby points. When used as terrain height, it creates abrupt spikes and pits because neighboring samples have no continuity.

Coherent noise, such as Perlin or Simplex noise, changes smoothly over space. Nearby coordinates therefore produce similar values, creating hills and valleys rather than isolated spikes.

A basic height function can be written as:

where:

• is the noise function.
• is amplitude and controls terrain height.
• is frequency and controls feature size.

Low frequency produces broad landforms, while high frequency produces small details. Coherent noise is deterministic for a fixed seed and coordinate, which supports reproducible worlds. However, a single noise layer often appears uniform, so several scales or additional biome and erosion rules are normally combined.

Fractal Brownian motion, commonly abbreviated as fBm, combines several octaves of coherent noise:

where:

• is the number of octaves.
• is the initial amplitude.
• is the initial frequency.
• is persistence, usually between and .
• is lacunarity, commonly close to .

For each new octave, frequency is multiplied by , creating smaller features, while amplitude is multiplied by , reducing their influence. The first octave forms large hills and valleys; later octaves add rocks, ridges, and surface detail.

The result may be normalized by dividing by the amplitude sum:

Increasing octaves improves detail but raises computational cost. Excessive high-frequency detail can also interfere with traversal and collision stability.

Terrain chunking divides a world into independently generated rectangular regions. A world position can be mapped to chunk coordinates using:

where is the chunk's world-space size.

Chunking supports large worlds by allowing the engine to:

• Generate only chunks near the player.
• Unload distant chunks to control memory usage.
• Reuse chunk objects through pooling.
• Apply different levels of detail according to distance.
• Generate terrain asynchronously to reduce frame stalls.

Noise must be sampled using global coordinates so adjacent chunks produce matching border heights. Neighboring chunks must also agree on vertex placement or use seam-handling methods when their levels of detail differ. Persistent modifications, such as mined terrain, must be stored separately so regenerated chunks preserve player changes.

A seed initializes procedural random processes. Using the same algorithm, seed, parameters, and coordinates should produce the same world. This is known as deterministic generation.

Determinism provides several benefits:

• Worlds can be reproduced without storing every terrain value.
• Multiplayer peers can generate matching base terrain.
• Bugs can be reproduced using a reported seed.
• Designers can preserve particularly useful generated worlds.

A biome system commonly creates low-frequency maps for properties such as temperature and moisture . These values select or blend biomes such as desert, forest, tundra, and swamp. Each biome can modify terrain height, textures, vegetation, weather, and object-spawn rules.

Smooth blending between biome weights is preferable to abrupt boundaries. Seeds alone do not store player edits or algorithm-version changes, so persistent worlds also require modification data and generator versioning.

Noise can create plausible variation but does not fully model natural land formation. Erosion algorithms reshape terrain to produce more believable drainage paths, valleys, and slopes.

• Hydraulic erosion simulates water flow, sediment collection, transport, and deposition.
• Thermal erosion moves material from slopes that exceed a stability threshold.
• River carving lowers terrain along generated flow networks.

Gameplay constraints are equally important. A terrain generator may validate or enforce:

• Traversable routes between objectives.
• Maximum slope and step values for controllers.
• Flat areas for buildings and spawn points.
• Safe distances between hazards and player starts.
• Reachability of resources and mission locations.

Erosion increases realism but can be computationally expensive. It may therefore be baked in editor tools, approximated at runtime, or applied only to selected chunks. Constrained generation ensures that visual realism does not make the game unplayable.

AI-driven game elements are entities or systems whose behavior is selected by algorithms according to game state, perception, goals, rules, or learned models.

Examples include:

• Enemies that patrol, investigate sounds, chase players, and attack.
• Companions that follow the player and provide support.
• Non-player characters that follow schedules or react to events.
• Vehicles that select routes and avoid obstacles.
• Directors that adjust enemy spawning or encounter intensity.
• Procedural systems that place resources according to player progress.

A typical AI system contains perception, memory or world state, decision making, navigation, and action execution. Good gameplay AI is not necessarily the most intelligent AI. It should be understandable, responsive, computationally practical, and consistent with the game's design. Players should receive visible or audible cues that explain important AI reactions.

A finite-state machine, or FSM, represents behavior as states and transitions. It is simple and efficient for agents with a small set of behaviors, but many states can produce a difficult network of transitions.

A behavior tree organizes decisions hierarchically using control nodes such as selectors and sequences. It supports reusable branches and readable priority-based behavior, but large trees still require careful debugging and state management.

Utility-based AI assigns scores to possible actions and chooses the most useful one. A basic selection rule is:

where is the utility of action in state . Utility AI creates flexible decisions but depends heavily on well-designed scoring functions.

FSMs suit straightforward behavior, behavior trees suit hierarchical action logic, and utility systems suit context-sensitive choices. Complex games often combine them, such as a behavior tree that uses utility scores to select combat actions.

A sight system usually checks distance, field of view, and line of sight.

For normalized forward direction and direction to the target , the target is inside a view cone with half-angle when:

The target must also be within the view distance. A ray cast from the observer to the target then checks whether terrain or another object blocks visibility.

A hearing system receives sound events containing a position, loudness, type, and lifetime. Detection may occur when attenuated sound intensity exceeds the listener's threshold. The AI can store the last detected position and investigate it even after direct perception is lost.

For efficiency, broad spatial queries should find nearby candidates before expensive ray casts are performed. Perception updates may also be distributed across frames instead of running every test for every agent in every frame.

A navigation mesh, or NavMesh, represents walkable space as connected convex polygons. It is generated from level geometry while considering agent radius, height, maximum step, and slope limit.

To move toward a destination, the system identifies the start and goal polygons and searches their connectivity graph. A* evaluates nodes using:

where:

• is the known path cost from the start to node .
• is the estimated remaining cost to the goal.
• is the estimated total cost through .

A* produces an optimal route when the heuristic does not overestimate the remaining cost. The polygon route is then converted into waypoints, often using a funnel algorithm. Local steering handles moving agents and temporary obstacles, while off-mesh links represent jumps, ladders, or doors. Dynamic worlds may require obstacle carving or partial NavMesh rebuilding.

Global pathfinding finds a route through the overall environment. It uses a graph, grid, waypoint network, or NavMesh to avoid permanent barriers and reach a distant objective.

Local steering chooses short-term velocity and direction while following that route. It handles:

• Avoidance of nearby moving agents.
• Response to temporary obstacles.
• Separation from group members.
• Smooth arrival and turning.
• Alignment and cohesion in group movement.

Global planning alone can cause collisions because the environment may change after a path is calculated. Local steering alone can become trapped at walls or local minima because it lacks knowledge of the complete route.

A combined system calculates a global path, selects an upcoming waypoint, and uses steering to produce collision-aware motion toward it. When progress fails or the destination changes significantly, the agent requests a new global path.

The enemy can be designed using an FSM or behavior tree with five major behaviors:

• Patrol: Follow assigned waypoints while periodically scanning for threats.
• Investigate: Move toward the last heard or partially observed disturbance.
• Chase: Pursue a confirmed target using pathfinding and update the route when necessary.
• Attack: Face and attack the target when range, line of sight, cooldown, and other combat conditions are satisfied.
• Return: Travel back to the patrol region after losing the target for a configured time.

The perception component should provide visible targets, sound events, and last-known positions. Memory should decay so the agent does not chase forever. Navigation should combine a NavMesh path with local avoidance. Animation events can synchronize damage with an attack frame.

The design should also include fairness measures: recognizable alert cues, reaction delay, limited perception, attack telegraphing, and difficulty parameters. Expensive perception and path requests should be scheduled across frames to support many enemies.