Game Developer interview questions

Keep authoritative rules in C++ and expose only safe tuning in Blueprints.

• Put validation, cooldown math, and replication in a reviewed C++ path.
• Expose damage, range, and VFX hooks as editable defaults for designers.
• Move repeated graph logic into a parent class or function library.

I keep the execution path small and push the rules into tags and effects.

• Use ability tags to gate activation and block conflicting skills.
• Apply cost and cooldown through GameplayEffects so prediction and replication stay aligned.
• Keep animation and target selection separate so the ability can change without rewiring logic.

I replicate only the values other clients must see and derive the rest locally.

• Use OnRep handlers for health, shield, and other visible stats.
• Batch frequent changes into one effect instead of many tiny updates.
• Keep hidden math like crit rolls and server caps off the wire.

I use tags when the state must grow across content teams and enums when the set is closed.

• Tags let designers add new combinations without a code rebuild.
• Enums are better for small switch-heavy logic with few states.
• I usually reserve tags for abilities, inventory traits, and status effects.

I would make the inventory data-driven and keep the hotbar as a view over it.

• Store item definition, stack count, and durability separately.
• Validate merge and split rules on the server before the UI updates.
• Replicate slot deltas so a 30-slot bag does not resend the full state.

I keep saves backward-compatible with explicit version stamps and small migration steps.

• Write a version number into every save and branch loaders by range.
• Migrate old fields forward in small steps instead of one big rewrite.
• Keep one fixture save from each shipped release for regression tests.

I keep the weapon contract in C++ and let Blueprint handle presentation.

• C++ owns ammo math, fire rate, recoil, and authority checks.
• Blueprint owns muzzle flash, audio, and designer-tuned defaults.
• Data assets define variants so balance changes stay centralized.

I would keep entities as IDs and move real state into typed components.

• Store transform, health, and inventory in separate contiguous arrays.
• Let systems read only the components they need for that update.
• Use stable IDs and generation counters so stale references fail fast.

I would split behavior into data, systems, and presentation instead of translating scripts one by one.

• Convert per-object state into component data that Burst can process in batches.
• Move hot loops into IJobEntity or Entities systems with explicit dependencies.
• Keep UI, VFX, and scene setup on the classic side until DOTS brings clear value.

They push me toward flat data, fewer branches, and explicit ownership.

• I avoid object graphs in hot code because Burst wants contiguous data.
• I batch work so one job update covers hundreds of entities.
• I measure data access first, because a clean algorithm can still be cache-poor.

I use Entities when a system has many similar objects and the frame cost is data-heavy.

• Use GameObjects for authoring-heavy or highly unique hero content.
• Use Entities for crowds, projectiles, particles, or large simulations.
• Switch only when profiling shows the classic model is the real bottleneck.

I make dependencies explicit and keep reads and writes narrow.

• Chain jobs through the returned handles so write-after-read conflicts stay visible.
• Split systems by access pattern instead of hiding synchronization in one big update.
• Check the profiler when a job waits more than it runs.

I would drive it from fixed inputs and a fixed simulation step.

• Quantize acceleration, friction, and jump impulses the same way on every machine.
• Avoid frame-time-scaled branches inside the authority path.
• Record inputs and state hashes so desyncs show up on the first bad tick.

I use root motion when the animation owns the pose and code-driven movement when gameplay must stay authoritative.

• Let code own collision and networked position.
• Let root motion add polish for attacks, vaults, and heavy turns.
• Clamp corrections so animation never drifts far from gameplay truth.

I bind gameplay windows to named markers instead of hardcoded frame indices.

• Read a marker from the asset, not from a clip name.
• Keep cancellation and timeout logic outside the event itself.
• Reuse the same marker names across alternate attack clips.

I keep one authoritative state machine and make every transition explicit.

• Let stun interrupt attack and roll through a clear priority rule.
• Clear buffered actions when the state changes.
• Keep exit logic in the leaving state so cleanup stays predictable.

I would combine simple perception with a navmesh-backed search routine.

• Use sight and hearing checks to set a last-known position.
• Patrol through waypoints when nothing is seen.
• Switch to a short investigation route before falling back to patrol.

I use a finite-state machine for tight combat logic and a behavior tree when the AI needs many reusable branches.

• FSMs are easier for attack, retreat, and stun loops.
• Behavior trees help when perception, patrol, and chase share nodes.
• I avoid trees when the design only needs four or five states.

I would try the straight move first and then fall back to a bounded search.

• Query a path to the target and cache the failure reason.
• If the path is blocked, sample nearby reachable points around the obstacle.
• Replan only when the agent actually makes progress, not every frame.

I would make interaction a shared contract with type-specific outcomes.

• Let the player detect nearby interactables through one ray or overlap query.
• Expose one entry point like Interact and let targets decide the result.
• Show one prompt pipeline so UI, audio, and gameplay stay aligned.