Sample questions
Gp Camera Follow TargetingDifficulty 1
A follow camera updates its position every frame with pos = lerp(pos, target, 0.1), using a fixed constant 0.1 regardless of frame time. What problem does this cause?
- aThe camera position becomes a random value once per second
- bThe camera stops updating entirely below 30 frames per second
- cThe catch-up speed changes with frame rate✓
- dThe target position gets overwritten by the camera position each frame
Explanation:Applying a fixed fraction once per frame means the number of times that fraction is applied per real second depends on frame rate, so the same constant produces a slower catch-up on a low frame-rate machine and a faster one on a high frame-rate machine. (a) and (b) describe failures that don't follow from this code, (d) reverses the assignment direction.
Gp Camera Follow TargetingDifficulty 2
QA reports that the follow camera feels noticeably "snappier" on a high-refresh-rate test monitor than on the reference 60Hz monitor, using the same build with pos = lerp(pos, target, 0.15) called once per rendered frame. What is the most likely cause?
- aThe fixed 0.15 fraction compounds more times per real second at the higher frame rate✓
- bThe high-refresh monitor is scaling render resolution, shrinking the camera's view distance
- cInput polling rate increased, making the target change position more often
- dThe renderer drops every other frame on the high-refresh monitor, delaying camera updates
Explanation:This is the same frame-rate-dependent lerp problem from a different angle: at a higher frame rate the same per-frame fraction compounds more times per second, so the camera closes the gap to the target faster in real time, which reads as snappier. (b), (c), and (d) invent mechanisms unrelated to the described code path.
Gp Camera Follow TargetingDifficulty 1
A follow camera defines a small rectangular region around the screen center where the target can move without the camera repositioning at all. What is this region commonly called?
- aThe clip region
- bA dead zone✓
- cThe cull box
- dAn anchor frame
Explanation:A dead zone is the tolerance area in which target movement produces no camera movement; the camera only starts moving once the target reaches the dead zone's edge. (a) and (c) name rendering/physics concepts unrelated to camera follow, (d) is not a standard term for this.
Gp Camera Follow TargetingDifficulty 2
A camera adds a forward offset in the target's current movement direction ("look-ahead") so the player sees more of what's coming up. What common artifact appears if the target frequently reverses direction, e.g. walking back and forth?
- aThe look-ahead offset accumulates without bound the longer the target keeps moving
- bThe dead zone around the target permanently disappears once look-ahead is enabled
- cThe camera's field of view narrows a fixed amount every time direction changes
- dThe camera repeatedly snaps back and forth as the offset flips sides✓
Explanation:Because look-ahead offset direction is tied directly to current movement direction, every reversal flips the offset to the opposite side; if this isn't smoothed or given hysteresis, rapid direction changes make the camera visibly snap or oscillate. (a) is not how a direction-following offset behaves, (b) and (c) are unrelated systems.
Gp Camera Follow TargetingDifficulty 1
A platformer's follow camera copies the target's Y position every frame, including every small hop. Players complain the camera feels shaky during normal jumping. What is the common fix?
- aTrack a smoothed ground-reference height instead of the raw jump Y✓
- bDisable vertical camera movement completely, moving only horizontally
- cIncrease the target's jump height so vertical motion reads more clearly
- dReduce the game's frame rate so vertical changes update less often
Explanation:Following a smoothed reference tied to standing/ground height (rather than the raw, frequently-changing jump position) removes the frame-to-frame vertical noise from small hops while still letting the camera adjust for larger, sustained height changes. (b) removes vertical tracking entirely, which breaks framing on tall drops or climbs; (c) and (d) don't address the root cause.
Gp Camera Follow TargetingDifficulty 2
float lookAheadOffset = movementDirection.x * lookAheadDistance;
cameraTargetX = target.x + lookAheadOffset;
lookAheadDistance is a large fixed value and
movementDirection.x is a unit-length direction component. What edge case is missing compared to a typical framing-safe implementation?
- aA frame-rate correction factor multiplied into
lookAheadDistance each call - bClamping or smoothing so the offset doesn't jump instantly on direction change✓
- cA cast to integer before adding
lookAheadOffset to target.x - dA separate
lookAheadDistance value tuned per Z-axis movement
Explanation:As written, any change in movementDirection.x (including small reversals) immediately produces the full offset with no easing, which is exactly the kind of instant jump that causes visible snapping. (a) is irrelevant since this isn't a per-frame integration step, (c) is a type concern with no bearing on the edge case, (d) is an unrelated axis.