Unit 6: Working with Navmesh - Subjective Questions

A NavMesh, or navigation mesh, is a data structure that represents the walkable areas of a game environment for artificial intelligence agents.

• It is generated from the level geometry.
• It identifies surfaces on which an agent can move.
• It stores information about connected walkable regions.
• It helps AI agents calculate paths around obstacles.
• It reduces the need for developers to manually define movement routes.

In Unity, a NavMesh is commonly used with a NavMeshAgent component to control characters such as enemies, non-player characters, and moving creatures.

The main steps for creating a NavMesh in Unity are:

• Prepare the scene: Add terrain, floors, walls, obstacles, and other relevant level geometry.
• Mark navigation geometry: Identify which objects should contribute to navigation and which should be ignored.
• Configure agent properties: Set values such as agent radius, height, step height, and maximum slope.
• Create a NavMesh Surface: Add a NavMeshSurface component to an appropriate GameObject.
• Select collection settings: Choose whether geometry is collected from the current object, children, or the entire scene.
• Bake the NavMesh: Build the navigation data using the configured geometry and agent settings.
• Test the result: Confirm that the generated blue NavMesh covers all intended walkable surfaces and excludes unsafe regions.

These settings determine which parts of the environment an agent can safely use.

• Agent radius: Defines the clearance required around an agent. A larger radius prevents the agent from navigating through narrow passages.
• Agent height: Defines the minimum vertical space needed by the agent. Low ceilings may become non-walkable if they do not provide sufficient clearance.
• Step height: Determines the maximum height of a step that the agent can climb.
• Maximum slope: Determines the steepest surface the agent can walk on.

Incorrect values can produce unusable paths. For example, a radius that is too small may allow an agent to pass through walls, while a maximum slope that is too high may allow it to walk on unrealistic surfaces.

Static obstacles are objects whose position does not normally change during gameplay.

• They are usually included while baking the NavMesh.
• Examples include walls, buildings, and permanent rocks.
• They provide efficient navigation because their effect is calculated in advance.

Dynamic obstacles can move or change during gameplay.

• They are handled at runtime using components such as NavMeshObstacle.
• They may use carving to remove their occupied region from the NavMesh.
• Examples include moving crates, doors, and vehicles.

Static obstacles are generally more efficient, while dynamic obstacles provide flexibility but may increase runtime processing costs.

A NavMeshAgent is a Unity component that controls navigation and movement for an AI character.

A typical process is:

• Attach a NavMeshAgent to the character.
• Ensure that the character starts on a baked NavMesh.
• Obtain the target position from a player, waypoint, or game object.
• Assign the target position to the agent's destination property.
• Allow the agent to calculate a path and move along it.
• Check properties such as hasPath, pathPending, and remainingDistance to determine movement status.

Example:

agent.SetDestination(target.position);

The agent automatically handles steering, acceleration, stopping distance, and obstacle avoidance according to its configuration.

Path finding using a NavMesh generally follows these stages:

• The agent identifies its current position and the requested destination.
• The navigation system finds the nearest valid points on the NavMesh.
• It searches the connected navigation polygons between those points.
• A suitable route is selected according to distance, area costs, and movement restrictions.
• The route is converted into corners or waypoints.
• The agent follows the path while continuously adjusting its direction.
• If the environment changes, the path may be recalculated.

The process allows agents to navigate around obstacles without requiring a manually authored path for every possible destination.

A NavMesh path is an ordered route made up of connected positions or corners that an agent can follow across the walkable navigation surface.

A developer can evaluate path status using:

• pathPending to determine whether path calculation is still in progress.
• hasPath to check whether the agent currently has a path.
• pathStatus to identify whether the path is complete, partial, or invalid.
• remainingDistance to estimate the distance left before reaching the destination.
• isStopped to determine whether movement has been paused.

A complete path reaches the destination. A partial path means that the agent can move toward the target but cannot reach it fully, often because the destination is isolated or blocked.

NavMesh paths can have different statuses:

• Complete path: A valid route exists from the agent's current location to the requested destination.
• Partial path: The navigation system found a route toward the destination, but the final destination cannot be reached. This may occur when the destination is on a disconnected island or behind an impassable barrier.
• Invalid path: No usable route was calculated. The agent may be outside the NavMesh, the destination may be invalid, or navigation data may not be available.

A robust game should handle all three cases. For example, it can choose a fallback location for partial paths and prevent movement when a path is invalid.

NavMesh area types classify regions according to their movement characteristics. Examples include walkable ground, mud, water, danger zones, and roads.

• Each area can be assigned a traversal cost.
• A lower cost makes an area more attractive to the pathfinding system.
• A higher cost discourages agents from using that area.
• Agents can be configured to avoid selected areas completely.
• Different agents can use different cost settings for the same environment.

For example, an enemy may prefer a short route through mud, while a civilian may avoid mud and choose a longer paved route. Area costs help produce more realistic and context-sensitive navigation behavior.

A waypoint patrol system can be designed as follows:

• Store an ordered list of waypoint transforms.
• Maintain an integer representing the current waypoint.
• Set the agent's destination to the current waypoint.
• Continuously check whether the agent has reached the waypoint using remainingDistance and stoppingDistance.
• When the waypoint is reached, increase the index.
• Use modulo arithmetic to return to the first waypoint after the final one.
• Optionally pause at each waypoint before continuing.

The transition can be expressed as:

where is the current waypoint index and is the total number of waypoints. This creates a repeating patrol loop without allowing the index to exceed the waypoint list.

Common causes and solutions include:

• The agent is not on the NavMesh: Place it on a baked walkable surface or warp it to a valid position.
• The destination is not on the NavMesh: Sample the nearest valid position before assigning the destination.
• Disconnected NavMesh regions: Add links or modify the level so that the regions connect.
• Incorrect agent settings: Match the baked agent type and dimensions with the runtime agent.
• Obstacles block the route: Inspect obstacle carving, colliders, and area settings.
• Path calculation is still pending: Wait until pathPending becomes false before evaluating the path.
• The agent is stopped: Check isStopped, speed, acceleration, and destination assignment.

Debugging should include visualizing the NavMesh, logging path status, and testing both the agent's starting point and destination.

A NavMeshLink connects two NavMesh regions that are not naturally connected by walkable geometry.

It is useful for:

• Jumping across gaps.
• Moving between different floors.
• Using ladders or elevators.
• Crossing doors or narrow transitions.
• Allowing an agent to use special traversal actions.

A link has a start point, an end point, and settings that define whether it is one-way or bidirectional. In advanced implementations, the link can trigger an animation or custom movement routine, such as climbing a ladder or jumping over an obstacle.

Multiplayer game development allows multiple players to share and interact within the same game session over a network. A networking solution manages communication between game instances.

Its main responsibilities include:

• Creating and managing game sessions or rooms.
• Connecting clients to a host, server, or relay.
• Synchronizing player positions, rotations, and actions.
• Spawning and removing networked objects.
• Handling ownership and authority.
• Sending remote procedure calls or replicated state updates.
• Managing latency, disconnections, and player joining or leaving.

Photon provides a cloud-oriented networking ecosystem, while Unity Netcode for GameObjects integrates networking features directly with Unity objects and workflows.

Photon and Unity Netcode for GameObjects both support multiplayer games, but they differ in architecture and workflow.

• Photon: Provides managed cloud services, matchmaking, rooms, and networking infrastructure. It is useful when developers want a hosted service with broad platform support.
• Unity Netcode for GameObjects: Is designed for Unity projects and uses concepts such as NetworkObject, NetworkBehaviour, ownership, and server-authoritative logic. It commonly works with Unity Transport and related Unity services.
• Deployment: Photon can reduce the need to operate dedicated networking infrastructure, while Unity Netcode may require a host, dedicated server, or Unity-supported service depending on the architecture.
• Integration: Unity Netcode fits naturally into Unity's component workflow, while Photon uses its own networking APIs and service model.

The appropriate choice depends on project requirements, hosting strategy, scalability, supported platforms, and team familiarity.

Server authority means that the server has the final decision about important game state, including movement validation, damage, scoring, and object ownership.

Client authority means that a client controls certain state changes and sends them to other participants.

Server authority is commonly preferred because:

• It reduces cheating opportunities.
• It keeps the official game state in one place.
• It prevents clients from independently creating contradictory results.
• It allows the server to validate movement, collisions, and actions.
• It improves consistency between players.

Clients should generally send input or requests, while the authoritative server processes them and replicates the resulting state.

A typical networked object lifecycle includes:

• Registration: The prefab is configured as a networked prefab and contains the required network object component.
• Spawning: The server or authorized host creates the object and assigns ownership when a player joins.
• Synchronization: Network variables, replicated transforms, commands, or remote procedure calls communicate relevant state to other clients.
• Ownership: The owning client may submit input, while the server validates and applies the result.
• Late joining: The networking system sends the current state of existing objects to a newly connected client.
• Removal: When a player leaves or an object is destroyed, the authoritative instance despawns it and informs connected clients.

Only appropriate state should be synchronized. Sending unnecessary data increases bandwidth usage and can reduce performance.

Using NavMesh agents in multiplayer introduces several challenges:

• Authority: The server must usually control AI movement so that every client receives the same result.
• Synchronization: Agent position, rotation, animation state, and actions must be replicated.
• Latency: Network delay can make remote agents appear to move irregularly.
• Bandwidth: Frequently transmitting transform data for many agents can be expensive.
• Determinism: Different clients may calculate slightly different paths because of timing or navigation data differences.
• Dynamic environments: Runtime changes must be represented consistently across the relevant machines.

A common solution is to run AI simulation on the server and send snapshots or movement updates to clients. Clients can interpolate received positions to make movement appear smooth.

Interpolation displays an object's position between two known network updates. The client renders a delayed but smoother movement path by blending between received snapshots.

Extrapolation predicts a future position using the object's latest position, velocity, and direction. It can reduce the visible effect of latency but may become inaccurate when the object changes direction or stops.

For networked NavMesh agents:

• The server remains responsible for the authoritative path and position.
• The client receives periodic movement snapshots.
• Interpolation can smooth ordinary movement.
• Extrapolation can help during temporary gaps in updates.
• Corrections should be applied gradually when prediction differs from the authoritative state.

The choice depends on the required responsiveness and the cost of temporary prediction errors.

Important NavMesh optimization techniques include:

• Use appropriate bake settings: Avoid excessive voxel or tile resolution when the gameplay does not require fine detail.
• Limit the navigation area: Collect only relevant geometry instead of baking the entire scene unnecessarily.
• Use multiple surfaces: Separate large environments into manageable navigation regions.
• Reduce path recalculation: Do not call SetDestination every frame unless the target has meaningfully changed.
• Control agent updates: Use suitable update rates and avoid running expensive logic for distant agents.
• Use area costs and filters: Prevent agents from searching regions they cannot use.
• Manage dynamic obstacles carefully: Enable carving only when it provides a clear gameplay benefit.
• Pool agents: Reuse AI objects instead of repeatedly instantiating and destroying them.
• Optimize network synchronization: Replicate only necessary movement and state data.

Optimization should be guided by profiling rather than assumptions.

A scalable multiplayer AI architecture separates authoritative simulation from visual presentation.

• Run important AI decisions and NavMesh calculations on the server.
• Update distant agents less frequently than nearby or combat-critical agents.
• Use a relevance or interest-management system so clients receive updates only for visible or important agents.
• Send compact state snapshots instead of unnecessary full object data.
• Interpolate movement on clients to hide network update intervals.
• Recalculate paths only when targets, obstacles, or goals change significantly.
• Use object pooling for agents and effects.
• Divide large navigation environments into loaded regions when appropriate.
• Avoid synchronizing internal path data when clients only need position, rotation, animation, and gameplay state.

This approach reduces CPU usage, bandwidth consumption, and client rendering overhead while preserving authoritative gameplay.