Game Developer interview questionsCoding — the dash that changes with frame rate round

Purpose

Sets the round as work on existing gameplay code rather than an algorithm from scratch, and makes running the code the expected way to find things out.

Purpose

Puts the ticket ahead of the code, so the question of what the designer asked for is in the candidate's head before the code's style is.

Purpose

Separates candidates who read gameplay code against the behaviour a designer asked for from those who review it for style. The ticket is the specification, and half the defects in the file are ones the designer has not found.

Signals to score

• Reads the ticket before the file and restates the requirement in numbers — 6 m, a cooldown in seconds, per character
• Finds that the dash's duration is timed in seconds while its movement is a fixed step per update, and works out the distance at 30 and at 144 fps
• Finds the cooldown counted in updates and says what 90 of them is at each frame rate
• Notices damage applied on every update a target is in range, with no record of who was hit
• Notices the wall check tests only the destination point, and asks how thick the walls are
• Predicts what the designer will report next once the reported bug is fixed
• Names what is correct — the input buffer timed with `frameDelta`, the facing fallback — and leaves it alone
• Spends no time on the square root in the distance check
• Asks whether 6 m is meant to be exact at every frame rate or is the result of a speed, before choosing a fix

Follow-up questions

• The designer tuned 6 m on a 60 fps PC. How far does it go on the handheld, and on a 144 Hz monitor?
• How long is the cooldown at 30 fps?
• A target stands in the middle of the dash path. How much damage does it take?
• Is anything in this file correct?
• What will the designer's next ticket say?

Purpose

Fixes the specification so the section is about the code, and hands over the three frame-time cases that expose the second-order bugs without naming them.

Purpose

Tests whether the candidate writes simulation code whose result does not depend on how time was sliced into frames, and checks it with a test rather than by watching numbers scroll.

Signals to score

• Moves the dash by elapsed time — speed times the frame's delta, or position computed from progress through the 0.2 s — and says which and why
• Clamps the final update so the dash ends at exactly six metres instead of overshooting on a long frame
• Decides what the 250 ms frame does — clamp the delta the ability sees, split it into sub-steps, or treat the move as a path — and says what the player sees in each case
• Replaces the destination point test with a sweep along each step, so a long step stops at the first wall
• Records the targets this dash has hit and damages each once, or finds them along the swept segment
• Converts the cooldown to seconds and checks the input buffer still lines up with it
• Makes the harness assert distance, duration, hits and cooldown at 30 fps, 144 fps and through the hitch
• Runs the harness before changing the code and after, and reads a failure back
• Notes that the same frame times in give the same result out, and why that matters for replays and networked play

Follow-up questions

• At 30 fps, where does the last update of the dash leave the character?
• One frame takes 250 ms. How far does the character move in that update, and through what?
• A target is in range for ten updates at 144 fps. How much damage does it take after your fix?
• How does the harness tell you it's fixed without you reading the output?
• Would you step the dash at a fixed rate instead? What does that cost?

Purpose

Gives a total cost without the breakdown, so asking for the breakdown before editing is the candidate's move.

Purpose

Reads frame-budget judgment at the size of one component: measuring before optimizing, recognising the expensive call rather than the expensive-looking one, and keeping the behaviour the tests prove.

Signals to score

• Asks for the per-function breakdown, or says how they would get it, before changing code
• Identifies the scene-wide tag lookup, made by each dashing character on every update, as the cost and the source of the arrays
• Replaces it with a query of the spatial structure the game already keeps — the physics broadphase or a gameplay grid — near the swept segment, written into a buffer the component reuses
• Weighs querying once along the whole path when the dash starts against querying every update, and says what the single query misses
• Removes the log formatting from shipping builds, or makes it cost nothing while logging is off
• Leaves the square root alone and says why it is not the cost
• Keeps hit-once and the wall sweep passing in the harness, and adds an allocation check where the language allows one
• States a budget for the component at forty dashers and confirms it with a second capture on the same machine

Follow-up questions

• Where would you look first — the code or the capture?
• Is the square root worth removing?
• You query once when the dash starts. A target steps into the path halfway through. What happens?
• How will you know next month's change hasn't put the allocation back?

Purpose

Tests whether tuning becomes data the designer owns, validated where it is authored, visible in the level and changeable while the game runs — and whether the candidate can say which values are feel and which are correctness.

Signals to score

• Moves distance, duration and cooldown into a per-character data asset or table, with units in the field names
• Validates values where they are edited — no zero or negative duration, a warning past the level's gap metrics — rather than failing at runtime
• Makes values reload while the game runs, and says what happens to a dash already in flight when they change
• Draws the swept path and end point in the editor or a debug view, stopping at walls with the same sweep the real dash uses
• Derives speed from distance and duration instead of storing it, so no two fields can disagree
• Keeps correctness out of the data — the sweep radius tied to collision, the hit-once rule — and says what the designer gets instead
• Gives a character with no data a visible default rather than a silent zero
• Asks the designer how they tune in practice before building an interface

Follow-up questions

• A designer sets duration to zero. What happens, and where do they find out?
• They change the distance halfway through a dash. What should that dash do?
• Why not expose speed as well as distance and duration?
• What is the one thing you would not let them tune?

Purpose

Candidates who have shipped gameplay ask how tuning reaches a build and who owns the tests; candidates who have not ask about the engine. Naming the topics makes the choice the signal.

Purpose

A real, specific weakness is the most convincing thing this round can offer the candidate it is looking for, and a fair warning to one who is not. Confirm it is still true before saying it.