Sample questions
Game Ai PathfindingDifficulty 3
A pathfinding search estimates the remaining distance to the goal using straight-line distance as a heuristic, and expands the node with the lowest (cost-so-far + estimated-remaining) first. Why does this tend to explore fewer nodes than a search with no heuristic at all?
- aBecause it guarantees an NPC never gets stuck, even when no valid path exists
- bBecause it removes the need for a graph or grid representation entirely
- cBecause it eliminates the need for any collision detection in the level
- dThe heuristic biases exploration toward the goal, so fewer irrelevant nodes expand✓
Explanation:Combining actual cost-so-far with an estimate of remaining distance lets the search prioritize promising directions instead of expanding blindly outward in every direction, which is why it typically visits fewer nodes. It says nothing about guaranteeing a path exists (a), doesn't remove the need for a graph (b), and is unrelated to collision detection (c).
Game Ai PathfindingDifficulty 3
A single NPC's path is recalculated every frame even though the goal and obstacles haven't changed. What is the simplest fix a junior developer should try first?
- aRecompute only on real change, else reuse the path✓
- bIncrease the number of NPCs to distribute the load
- cSwitch the entire level's rendering pipeline
- dRemove pathfinding entirely and let the NPC stand still
Explanation:If nothing relevant has changed, recomputing the same path every frame is pure waste — caching the last valid path and only recomputing on a real change (new goal, obstacle moved) is the direct fix. Adding more NPCs (b) makes the problem worse, changing the renderer (c) is unrelated, and disabling pathfinding (d) breaks the feature instead of fixing it.
Game Ai PathfindingDifficulty 3
A door that NPCs normally path through suddenly gets locked mid-game, blocking the only route. What should happen to NPCs already following a path through that door?
- aThey should keep walking into the closed door indefinitely
- bPath becomes invalid, recalculate or report unreachable✓
- cThey should permanently forget how to path anywhere afterward
- dThe game should delete those NPCs immediately
Explanation:A newly locked door is a change to the walkable world, so any path relying on it becomes stale and must be invalidated and recomputed (or reported as unreachable if no alternate exists). Walking into the door forever (a), permanently losing pathfinding ability (c), and deleting the NPCs (d) are not reasonable responses to a dynamic obstacle appearing.
Game Ai PathfindingDifficulty 3
Two NPCs following paths that were computed without knowledge of each other now visibly collide and bump into one another. What best explains this?
- aThe navmesh was generated with too many polygons
- bThe NPCs are using two different graph representations of the exact same corridor
- cPaths were planned only against the static layout, not against each other as obstacles✓
- dThe game's fixed timestep is set too small
Explanation:If path planning only considered the static world and ignored other moving agents, two independently-valid paths can still cross at the same place and time, causing a bump — the fix is to treat other NPCs as dynamic obstacles (or add local avoidance). Too many navmesh polygons (a) is a performance concern, not a collision cause; differing graph representations (b) is not implied by the scenario; and timestep size (d) doesn't explain agents ignoring each other.
Game Ai PathfindingDifficulty 3
An NPC is standing still, facing away from a loud noise the player just made nearby. Should a well-designed perception system let the NPC react?
- aYes — hearing usually ignores facing, unlike sight which needs a facing cone✓
- bNo — perception should only ever use the sight sense, never hearing
- cNo — NPCs should never react to anything the player does
- dYes, but only if the NPC is standing inside a locked room
Explanation:Hearing is generally modeled as omnidirectional (or with a much wider range than sight), so a loud nearby noise can be detected regardless of which way the NPC is facing, unlike sight which typically requires a facing cone. Claiming perception can't use hearing (b) or never reacts to the player (c) contradicts the whole point of a perception system, and locked rooms (d) are irrelevant to how hearing works.
Game Input AudioDifficulty 3
For continuously reading how far a joystick is tilted every single frame to drive smooth analog movement, which input model fits naturally?
- aEvent-driven input, since movement should only update once per key press
- bPolling, since the current analog value is needed on every frame✓
- cInput buffering, since analog values must be delayed by several frames
- dAudio pooling, since joystick data is transmitted as sound signals
Explanation:Continuous analog state (stick tilt, trigger pressure) is naturally read via polling: the game asks for the current value every frame to drive proportional movement, rather than waiting for discrete change events.