Unit 2: Player Controls and Positioning - Subjective Questions

A Game Manager is a central component that controls the overall state and flow of a game. It commonly persists across scenes and coordinates systems that should not be managed by individual gameplay objects.

Its major responsibilities include:

• Game-state management: Controls states such as playing, paused, game over, victory, and restarting.
• Level management: Loads, restarts, and changes scenes or levels.
• Player management: Stores player score, health, lives, inventory, and checkpoint information.
• Physics coordination: Applies global physics settings or manages physics-related gameplay rules.
• Event coordination: Listens for important events and informs other systems when the game state changes.
• UI and audio control: Updates menus, score displays, sound effects, and background music.
• Object lifecycle management: Spawns or removes enemies, collectibles, and other gameplay objects.

A Game Manager is often implemented using the Singleton pattern, allowing other scripts to access one shared manager instance. However, it should not become overloaded with responsibilities that belong to specialized systems.

A Game Manager can coordinate physics-based gameplay by controlling global settings and responding to physics-related events.

Important functions include:

• Global gravity control: It may change the gravity vector for special levels, low-gravity zones, or gameplay effects.
• Simulation control: Pausing the game can be achieved by changing the time scale or disabling physics simulation when appropriate.
• Respawning: If the player falls below a minimum height, the Game Manager can return the player to the latest checkpoint.
• Collision-event processing: It can respond to player deaths, enemy defeats, or objective completion reported by colliders and triggers.
• Physics-layer management: Collision rules between layers such as player, enemy, projectile, and environment can be configured.
• Dynamic difficulty: The manager may alter enemy speed, applied forces, or obstacle behavior according to game progress.

For example, the Game Manager may test whether the player's vertical position satisfies . If it does, the manager resets the player's velocity and places the player at a saved checkpoint. This centralizes level-wide physics rules while individual objects continue to handle their own movement and collisions.

According to Newton's second law, the acceleration produced by a constant force is

where is the applied force and is the player's mass.

For a time interval , velocity is updated as

Substituting the force equation gives

The approximate position update is

Gravity may be included as an additional acceleration:

Therefore,

In a game engine, these calculations are normally performed by a physics system through a Rigidbody. Forces should be applied during the fixed physics update so that movement remains stable and largely independent of the rendering frame rate. Drag, friction, collision impulses, and constraints can further modify the final velocity.

Transform-based movement directly modifies an object's position or rotation.

• It is simple and suitable for non-physical objects.
• It may bypass realistic collision responses.
• Incorrect use can cause tunnelling or overlap with colliders.

Rigidbody-based movement uses the physics engine.

• Movement is created with forces, velocity, or physics-aware movement methods.
• It supports mass, gravity, drag, momentum, and collision response.
• It is appropriate for vehicles, rolling objects, and physically reactive characters.

Character Controller movement uses a dedicated controller rather than full Rigidbody dynamics.

• It provides controlled collision-aware movement.
• It is commonly used for first-person or third-person characters.
• Gravity and jumping usually need to be implemented manually.
• It offers predictable movement without unwanted tipping or physical rotation.

Thus, Transform movement provides direct control, Rigidbody movement provides realistic physics, and Character Controller movement provides stable and responsive character navigation.

A controllable 3D player generally requires the following components:

• Transform: Stores the player's position, rotation, and scale.
• Collider: Defines the physical shape used for collision and trigger detection.
• Rigidbody or Character Controller: Performs physics-based or collision-aware movement.
• Input component: Reads movement, jump, attack, interaction, and camera commands.
• Movement script: Converts input values into player translation and rotation.
• Ground-detection component: Determines whether jumping is permitted.
• Animator: Controls idle, walking, running, jumping, falling, and combat animations.
• Camera system: Follows the player and provides a suitable view of the scene.
• Health or damage component: Processes hazards and enemy attacks.
• Audio source: Plays footsteps, jumps, attacks, and damage sounds.
• Interaction component: Detects and activates doors, switches, collectibles, or NPCs.

These components should be separated according to responsibility. For example, the input component should report commands, while the movement component should decide how those commands affect the character.

These components define how objects detect and respond to physical contact:

• A Collider defines an object's collision boundary. Common types include box, sphere, capsule, and mesh colliders.
• A Trigger is a collider configured to detect overlap without producing a solid collision response. It is useful for checkpoints, pickups, damage zones, and interaction regions.
• A Rigidbody gives an object physical properties such as mass, velocity, gravity, drag, and collision response.
• A Physics Material controls surface characteristics, particularly friction and bounciness.

When two solid colliders meet, the physics engine calculates contact points and prevents interpenetration. If one collider is a trigger, the objects may pass through each other while trigger events are generated. At least one of the interacting objects generally needs a Rigidbody for reliable physics callbacks.

For example, a player with a capsule collider and Rigidbody can stand on a floor collider. A low-friction material makes the floor slippery, while a high-bounciness material causes dynamic objects to rebound.

A 3D Game Kit usually provides reusable prefabs and components for building gameplay without creating every system from the beginning. Common objects include:

• Player prefab: Contains movement, health, animation, and interaction components.
• Enemies: Detect, chase, and attack the player while responding to damage.
• Doors: Open after an interaction, event, key collection, or switch activation.
• Pressure pads and switches: Generate events that control doors, platforms, lights, or hazards.
• Moving platforms: Transport the player between fixed points.
• Checkpoints: Save a respawn position after player activation.
• Damage zones: Reduce health or instantly defeat the player.
• Collectibles: Add score, health, keys, or objective progress.
• Teleporters: Reposition the player at a linked destination.
• Destructible or damageable objects: React to attacks and may generate events when destroyed.

These objects are normally configured through inspector properties and event connections. Designers can combine them to create puzzles and level progression, such as making a pressure pad open a door while a moving platform provides access to the next area.

A moving platform typically travels between two or more waypoints. Its implementation should include:

• Waypoint storage: A list of target positions defines the path.
• Controlled interpolation: The platform moves toward the current waypoint at a specified speed.
• Physics timing: A physics-based platform should normally be updated during the fixed physics step.
• Kinematic Rigidbody: A kinematic body allows controlled movement while still participating in collision detection.
• Player transfer: The platform's displacement or velocity should be transferred to the player so the player does not slide off.
• Arrival tolerance: When the platform is sufficiently close to a waypoint, it selects the next waypoint.

If the distance to the target is and platform speed is , the ideal travel time is

Temporarily parenting the player to the platform is a simple solution, but it can cause scale and rotation problems. A more robust approach is to apply the platform's positional change to the player or let the physics system transfer motion through contact. Sudden Transform changes should be avoided because they may produce jitter or unreliable collision detection.

An Advanced Input System is an action-oriented input framework that separates gameplay commands from specific hardware controls.

Its principal concepts include:

• Input Actions: Logical commands such as Move, Jump, Attack, Pause, and Interact.
• Bindings: Connections between actions and controls such as keyboard keys, mouse buttons, or gamepad controls.
• Action Maps: Groups of actions for a particular context, such as Gameplay, UI, Vehicle, or Menu.
• Control Schemes: Collections of compatible devices and bindings, such as keyboard-and-mouse or gamepad.
• Processors: Modify input values through dead zones, inversion, normalization, or scaling.
• Interactions: Define input behavior such as press, hold, tap, or multi-tap.
• Callbacks: Notify scripts when an action starts, is performed, or is cancelled.

Advantages include multi-device support, control rebinding, local multiplayer support, cleaner code, accessibility options, and easy switching between gameplay and menu controls.

Polling-based input checks the current input value repeatedly, usually once per frame.

• It is useful for continuous commands such as movement, aiming, and camera rotation.
• The script remains in control of when input is read.
• Repeated checks may create tightly coupled input and gameplay code.

Event-driven input calls a registered function when an input action changes state.

• It is useful for discrete commands such as jumping, attacking, pausing, and interacting.
• It clearly distinguishes phases such as started, performed, and cancelled.
• It reduces unnecessary checks and supports decoupled architecture.
• Callbacks must be registered and unregistered carefully to avoid duplicated responses.

A practical controller often uses both methods. An event can store the current movement vector when the Move action changes, and the movement system can use that stored value during each update. Jump can be handled directly when its action is performed.

A third-person controller can use a Gameplay action map containing actions such as Move, Look, Jump, Sprint, Attack, and Interact.

A suitable configuration is:

• Move: A two-dimensional value bound to a keyboard composite and a gamepad left stick.
• Look: A two-dimensional value bound to mouse movement and the gamepad right stick.
• Jump: A button action with a press interaction.
• Sprint: A button action using a hold interaction.
• Attack: A button action with press or multi-tap interactions.
• Interact: A button action triggered near interactive objects.

Control schemes may include:

• Keyboard and mouse
• Gamepad

Useful processors include:

• A dead-zone processor for analog sticks.
• A scale processor to adjust look sensitivity.
• An invert processor for optional vertical look inversion.
• A normalize processor to prevent diagonal movement from becoming faster.

A separate UI action map can be enabled when a menu opens, while Gameplay is disabled. This prevents the player from moving while navigating the menu.

Camera-relative movement makes the character move according to the direction in which the camera is facing rather than according to fixed world axes.

Let the two-dimensional input be

The camera's forward and right vectors are projected onto the horizontal plane by removing their vertical components. They are then normalized:

The desired movement direction is

To prevent faster diagonal movement, the magnitude is clamped so that

The player is moved using , and the character can rotate gradually toward this direction. Removing the camera's vertical component prevents the character from moving into the ground or into the air when the camera looks up or down.

Event handling is a communication technique in which one component announces that something has happened and other components respond without requiring direct control from the sender.

The main roles are:

• Event publisher: Detects a condition and raises or invokes an event. For example, a pressure pad publishes an activation event.
• Event subscriber or listener: Registers a response to that event. For example, a door listens and opens when the pad is activated.
• Event data: Optional information sent with the event, such as damage amount, player identity, or collected item type.

Typical game events include:

• Player health changed.
• Enemy defeated.
• Item collected.
• Checkpoint activated.
• Door unlocked.
• Level completed.

Event handling reduces tight coupling because the publisher does not need detailed knowledge of every listener. Listeners should unsubscribe when disabled or destroyed; otherwise, callbacks may target invalid objects or execute multiple times.

Collision events occur when solid colliders make physical contact.

• The physics engine normally prevents objects from passing through each other.
• Collision information may contain contact points, normals, and relative velocity.
• Examples include a player landing on the ground, a projectile striking a wall, or a crate colliding with another crate.

Trigger events occur when an object overlaps a collider marked as a trigger.

• The trigger does not create a solid physical barrier.
• Trigger callbacks indicate entry, continued overlap, and exit.
• Examples include collecting an item, entering a checkpoint, activating a dialogue zone, or stepping into a damage area.

A collision should be used when a physical response is required. A trigger should be used when overlap must be detected without blocking movement. Correct physics layers and Rigidbody configuration are also necessary to ensure that the expected callbacks occur.

The sequence can be designed using a pressure-pad event and multiple independent listeners.

Step 1: Detect activation

• Give the pressure pad a trigger collider.
• When a valid object enters, increase the number of objects currently pressing the pad.
• When the count changes from zero to one, invoke an activation event.

Step 2: Connect listeners

• The door component listens to the event and begins its opening animation.
• The light component listens and changes its color or intensity.
• The audio component listens and plays an activation sound.

Step 3: Handle deactivation

• When an object exits, decrease the count.
• When the count reaches zero, invoke a deactivation event if the puzzle is not intended to remain permanently active.
• The door may close, the light may turn off, and a release sound may play.

Step 4: Prevent errors

• Filter entering objects by tag or layer.
• Use an overlap count so that the pad does not deactivate while another object remains on it.
• Prevent repeated audio playback if the state has not changed.

This architecture is extensible because new listeners can be added without changing the pressure-pad detection code.

Animation rigging is the process of using constraints and control objects to modify or procedurally control a character's skeleton in addition to its existing animation clips.

It is useful because it can:

• Make the character look toward a target.
• Place hands accurately on a weapon or steering wheel.
• Adjust feet to uneven ground.
• Aim the upper body independently of lower-body movement.
• Add procedural corrections without creating a separate animation for every situation.
• Blend authored animation with real-time gameplay requirements.

A typical rig contains a rig builder, one or more rig layers, target objects, hint objects, and constraints. The Animator first evaluates the base animation, after which rig constraints modify selected bones. Constraint weights can be blended from to , where means no rig influence and means full influence.

Forward Kinematics (FK) calculates the final position of a bone chain from the rotations of its parent bones.

• The animator rotates the shoulder, elbow, and wrist in sequence.
• It provides precise control over arcs and poses.
• It is commonly used in authored animation clips.
• Reaching an exact world-space target may require several manual adjustments.

Inverse Kinematics (IK) starts with a desired end-effector position and calculates the joint rotations required to reach it.

• The hand or foot is assigned a target.
• A hint may control the direction in which an elbow or knee bends.
• It is useful for aiming, grabbing, foot placement, and interacting with dynamic objects.
• Poor target placement or unsuitable joint limits can create unnatural poses.

Thus, FK works from the root toward the end of a chain, while IK works backward from the desired end position. Modern gameplay animation frequently combines base FK animation with IK corrections.

A two-bone IK constraint operates on a three-joint chain:

• Root bone: Shoulder or upper leg.
• Middle bone: Elbow or knee.
• Tip bone: Hand or foot.

Its operation involves the following elements:

• A target specifies the desired position and, optionally, rotation of the tip bone.
• A hint influences the bending direction of the middle joint.
• A weight controls how strongly IK modifies the original animation.

The solver rotates the root and middle bones so that the tip approaches the target while preserving the lengths of the two bones. If their lengths are and , a reachable target at distance should approximately satisfy

If the target is outside this range, the chain cannot reach it without stretching. For hand placement, the target can be attached to a weapon grip. For foot placement, a raycast can position the target on the ground, while the hint keeps the knee facing naturally forward.

Foot placement adjusts the character's feet to match the height and orientation of uneven terrain.

A common procedure is:

1. Cast a ray downward from a point above each foot.
2. Find the ground hit point and surface normal.
3. Set the IK foot target position slightly above the hit point to account for the sole thickness.
4. Align the foot rotation with the ground normal while preserving a natural forward direction.
5. Adjust the body or pelvis height so that both legs remain within a comfortable reach.
6. Blend the IK weight according to the foot's contact phase in the walk animation.
7. Smooth target movement to prevent visible jitter when moving across complex colliders.

IK should have greater influence when a foot is planted and lower influence while that foot is swinging. Layer masks should ensure that raycasts detect the ground but ignore the player. Maximum slope angles and reach limits should also be applied to prevent extreme or unnatural leg poses.

A complete third-person control flow can be organized as follows:

1. Input layer

• The Advanced Input System reads Move, Look, Jump, Sprint, Attack, and Interact actions.
• Input callbacks store command values rather than directly moving the character.
• Gameplay and UI action maps are enabled according to the current game state.

2. Movement and physics layer

• The movement vector is converted into a camera-relative world-space direction.
• A Rigidbody or Character Controller performs collision-aware movement.
• Ground detection determines whether jumping is allowed.
• Gravity, slope limits, drag, and speed constraints are applied.

3. Event layer

• Trigger events detect collectibles, checkpoints, interaction zones, and hazards.
• Collision events detect landing and physical impacts.
• Player events report health changes, death, attacks, and objective completion.
• The Game Manager listens for major events and updates the game state, UI, or respawn position.

4. Animation layer

• Movement speed and grounded state update Animator parameters.
• Animator states control idle, locomotion, jump, fall, attack, and damage clips.
• Rig constraints aim the head or weapon toward a target.
• Foot IK aligns the feet with uneven surfaces.

5. Update order and stability

• Input is collected during frame updates or callbacks.
• Physics movement is performed during fixed updates.
• Camera and rig targets are adjusted after movement to reduce visual lag.
• Event subscriptions are removed when components are disabled.

This layered design keeps input, movement, events, and animation independent while allowing them to communicate through well-defined values and events.