Microsoft Game Developer (Junior Level) - Comprehensive Interview Preparation Guide

Direct answer

I once estimated a two-week ramp on an unfamiliar reporting platform for a client deliverable, and it actually took closer to five, which pushed the delivery date and strained the client relationship. The actual gap wasn't laziness, it was that I estimated based on how long the tool's documentation said it would take to learn, not on how long it would take to reach the specific proficiency the deliverable actually needed. Now I size unfamiliar work by separating "functional" from "proficient enough for this specific deliverable," and I checkpoint accordingly.

What happened

I committed to a two-week timeline for building a client reporting dashboard on a platform I hadn't used before, based on how quickly I expected to become functional in it. I became functional in about a week, but the deliverable actually needed a more advanced capability, custom calculated fields with specific formatting the client had asked for, that took much longer to get right than basic proficiency did. I kept delivering partial progress throughout rather than going quiet, and I told the client and my manager as soon as I recognized the gap, in week three rather than waiting until the original deadline had already passed, with a revised estimate and the specific reason for it. The relationship took a real hit regardless; the client had scheduled other work around our delivery date, and being honest early reduced the damage but didn't remove it.

What actually caused the gap

The root cause was that I estimated against "learn the tool" rather than "reach the specific proficiency this deliverable requires," which are very different amounts of time, and I hadn't separated them. I also chose to learn by working directly on the client deliverable instead of first practicing the specific advanced feature on a low-stakes example, which meant my learning curve and the client's deadline were running on the same clock instead of the learning happening ahead of it.

How I size unfamiliar work now

I now estimate in two explicit stages: time to become functional, and time to become proficient enough for the specific hardest requirement in the actual deliverable, and I ask what the hardest requirement is before I estimate at all, rather than assuming average difficulty. I also build a checkpoint at roughly a third of the way through any timeline that depends on a skill I'm still building, specifically to catch a gap like this while there's still time to adjust the plan. And where possible, I now practice the hardest unfamiliar piece on something low-stakes before it's load-bearing on a client commitment, rather than learning it live on the deliverable itself.

Trade-offs and pitfalls

The pitfall in estimating unfamiliar work is treating "I've used something like this before" as equivalent to "I know how long the hardest part will take," when those are different claims. Padding every unfamiliar estimate protects against this but costs credibility if overused, which is why I now separate functional from proficient explicitly rather than padding everything uniformly.

Goal & constraints
Blend mocap → ragdoll smoothly, conserve momentum, avoid pops, keep sync with root motion, and handle immediate collisions.

Algorithm (high-level)

1. On “death” sample current animated world-space transforms T_i and velocities V_i for each bone (estimate bone linear/angular velocity from last N frames).
2. Switch bones to physics in two phases:
   • Phase A (kinematic blending): make physics bodies kinematic and drive them toward animated targets with a critically-damped PD controller; apply target velocities derived from V_i.
   • Phase B (full dynamic): after blendTime or when positional error < epsilon, set bodies to dynamic and initialize linear/angular velocities to match sampled V_i.
3. Momentum transfer: compute root COM velocity from animation and add any incoming impulse; set ragdoll root rigidbody velocity = COM velocity to conserve momentum; distribute angular momentum via mapped inertia or by setting angular velocities on key bones.

Blending details

• Blend weight w(t) = smoothstep(0,1,t/blendTime). For each body apply force/torque:
  targetForce = k_p*(T_target - T_current) + k_d*(V_target - V_current)
  apply as kinematic drive while w < 1.
• Use local-space target mapping to avoid drift from retargeting.

Synchronization

• Run animation sampling and physics substeps at same fixed timestep. Sample animation after last physics substep, then apply kinematic targets before next physics step. Use substepping and CCD to avoid tunneling.

Collision/recovery

• If immediate penetration detected on dynamic enable:
  • First attempt: back off along collision normal by minimal translation to resolve penetration and re-run a micro physics step.
  • If penetration persists: keep the body kinematic for an extra short recoverTime while applying a soft repulsion force (collision-aware PD).
  • Use contact impulses to adjust velocities (subtract penetrating impulse from initialized velocity) to avoid explosive responses.
• Always clamp applied corrective impulses to avoid numeric instability.

Practical notes

• Use per-bone mass distribution matching skeleton inertia.
• Tune PD gains, blendTime (~0.1–0.3s), use CCD and continuous contact to minimize pops.
• Example pseudo:

// OnDeath
for bone in bones {
  T_target = sampleAnimatedTransform(bone);
  V_target = estimateVelocity(bone);
  body.setKinematic(true);
  body.setKinematicTarget(T_target);
  body.userTargetVel = V_target;
}
startBlendTimer();

Direct answer

Deep-cloning a graph with cycles requires a map from each original node to its clone, created the first time that node is encountered, so that any later edge pointing back to an already-cloned node reuses the existing clone instead of recursing or looping into it again. Both breadth-first search (BFS) and depth-first search (DFS) work; the map is what actually prevents infinite loops on a cycle, not the choice of traversal order.

Structured elaboration

The core invariant both approaches maintain is: a node is added to the clone map exactly once, the first time it is seen, before its neighbors are processed. In the BFS version, a node is cloned when it is first discovered (dequeued or about to be enqueued) and its edges are wired up as its neighbors are visited. In the recursive DFS version, the clone must be created and stored in the map BEFORE recursing into that node's neighbors, otherwise a cycle back to the current node would trigger another recursive call before the map has a place to short-circuit into, causing infinite recursion.

Worked example

from collections import deque

class Node:
    def __init__(self, val, neighbors=None):
        self.val = val
        self.neighbors = neighbors if neighbors is not None else []

def clone_graph_bfs(node):
    if not node:
        return None
    clones = {node: Node(node.val)}
    q = deque([node])
    while q:
        cur = q.popleft()
        for nbr in cur.neighbors:
            if nbr not in clones:
                clones[nbr] = Node(nbr.val)
                q.append(nbr)
            clones[cur].neighbors.append(clones[nbr])
    return clones[node]

def clone_graph_dfs(node, clones=None):
    if not node:
        return None
    if clones is None:
        clones = {}
    if node in clones:
        return clones[node]
    clones[node] = Node(node.val)
    for nbr in node.neighbors:
        clones[node].neighbors.append(clone_graph_dfs(nbr, clones))
    return clones[node]

def build_cyclic_triangle():
    # 1 -- 2 -- 3 -- 1, an undirected triangle, a genuine 3-cycle
    n1, n2, n3 = Node(1), Node(2), Node(3)
    n1.neighbors = [n2, n3]
    n2.neighbors = [n1, n3]
    n3.neighbors = [n1, n2]
    return n1

def graph_signature(start):
    '''BFS the graph and return {val: sorted(neighbor vals)} by value, independent of object identity.'''
    seen = {}
    q = deque([start])
    visited_ids = {id(start)}
    while q:
        cur = q.popleft()
        seen[cur.val] = sorted(n.val for n in cur.neighbors)
        for nb in cur.neighbors:
            if id(nb) not in visited_ids:
                visited_ids.add(id(nb))
                q.append(nb)
    return seen

if __name__ == "__main__":
    original = build_cyclic_triangle()
    clone_b = clone_graph_bfs(original)
    clone_d = clone_graph_dfs(original)

    print("Original signature:", graph_signature(original))
    print("BFS clone signature:", graph_signature(clone_b))
    print("DFS clone signature:", graph_signature(clone_d))
    print("BFS clone structurally identical to original:", graph_signature(clone_b) == graph_signature(original))
    print("DFS clone structurally identical to original:", graph_signature(clone_d) == graph_signature(original))

    # Prove it's a deep copy, not a reference: mutating the clone must not affect the original
    clone_b.val = 999
    print("Original node's val unaffected by mutating the BFS clone (proves deep copy, not alias):", original.val == 1)

Output (actually executed with python3):

Original signature: {1: [2, 3], 2: [1, 3], 3: [1, 2]}
BFS clone signature: {1: [2, 3], 2: [1, 3], 3: [1, 2]}
DFS clone signature: {1: [2, 3], 2: [1, 3], 3: [1, 2]}
BFS clone structurally identical to original: True
DFS clone structurally identical to original: True
Original node's val unaffected by mutating the BFS clone (proves deep copy, not alias): True

Complexity

• Both BFS and DFS: time $O(V + E)$, each node cloned once, each edge wired once.
• Space: $O(V)$ for the clone map, plus $O(V)$ for the BFS queue or the DFS recursion stack in the worst case (a long chain).

Edge cases

• node is None: both functions return None immediately, no traversal attempted.
• Disconnected components: only the component reachable from the given starting node is cloned, since neither traversal has any way to discover a component it cannot reach, this matches the problem's own framing (clone starting from a single reference node).
• Self-loops: a node listing itself as a neighbor is handled correctly, the map check (if nbr not in clones) treats "myself" the same as any other neighbor once it has been added to the map.

Trade-offs and pitfalls

• BFS versus DFS here is a memory-shape choice, not a correctness choice. DFS's recursion depth equals the longest simple path in the graph, which risks a stack overflow on deep or adversarially long graphs; BFS's queue depth is bounded by the width of the widest frontier instead. For graphs that might be very deep (a long chain-like dependency structure), prefer BFS or an iterative DFS with an explicit stack.
• Common mistake: checking if nbr not in clones in the DFS version but creating the clone AFTER recursing into the neighbor instead of before; this defeats the entire cycle guard and reintroduces infinite recursion on any cycle.
• Common mistake: cloning neighbors by reference (new_node.neighbors = old_node.neighbors) instead of building a fresh list of cloned neighbor references; this produces a shallow copy that still points at the ORIGINAL nodes, silently failing the "deep copy" requirement while still returning without error.

Situation / Summary
As a game developer targeting iOS/macOS, Metal shader authoring differs from GLSL/HLSL in syntax, binding, and GPU architecture. Below are concise, practical differences and optimizations I apply.

Language & syntax

• Metal Shading Language (MSL) is C++-like, strongly typed, with explicit address spaces (device, threadgroup, constant).
• No built-in globals like gl_FragCoord; use stage IO structs.
• Use function constants (specialization constants) for compile-time variants.

Example binding syntax:

struct VertexOut { float4 pos [[position]]; };
vertex VertexOut vs_main(constant float4* verts [[buffer(0)]], uint vid [[vertex_id]]) { ... }

Resource binding model & argument buffers

• Bind resources with [[buffer(n)]], [[texture(n)]], [[sampler(n)]]. Indices are per-stage slots.
• Argument buffers (GPU-side descriptor arrays) pack many resources into one buffer — great for many materials/instances. Use MTLArgumentEncoder to fill them on CPU and bind single buffer to slot.

Threadgroup memory & threading

• threadgroup (shared) memory declared with threadgroup address space. Minimize size per-threadgroup; prefer per-tile aggregates.
• Choose threadgroup size that matches GPU wavefront/warp (vary by family). On Apple tile-based GPUs, smaller groups that match SIMT width help.

Platform-specific optimization tips

• Favor float16/packed formats where precision allows; reduces bandwidth.
• Minimize memory bandwidth: use interpolators instead of extra texture fetches when possible.
• Avoid branching divergence in fragment shaders; prefer blend or linear steps.
• Use function constants to specialize shaders instead of branching at runtime.
• For tile-based GPUs (iPhone), leverage tile-local work: combine opaques in single render pass, use MSAA carefully, use memoryless render targets where supported.
• Align buffers to 256 bytes for best performance; keep resource transitions and encode calls batched.
• Test on multiple families (A-series vs M-series): M-series has more compute throughput; tune threadgroup sizes accordingly.

Why this matters
These differences affect correctness (bindings/syntax) and performance (bandwidth, divergence, tiling). Using argument buffers, careful threadgroup sizing, and platform-aware precision choices yields measurable FPS and battery improvements on iOS/macOS devices.

Approach & Goals
Explain required engine changes to shift culling/submit work from CPU to GPU using compute shaders + indirect draws (Vulkan-style). Focus: data layout, GPU-visible buffers, argument generation, synchronization, and trade-offs.

Steps / Engine Changes

• Replace CPU culling pass with a GPU compute pass that consumes compact scene lists (per-view frusta, LOD thresholds).
• Introduce a "GPU scene" — tightly packed arrays: transform (mat4 or vec3+quat+scale), bounding sphere (vec4), material indices, draw IDs. Use SoA (separate arrays) for cache/coalesced loads in compute.
• Create GPU-visible buffers (device-local + mapped staging where needed): transforms, bounds, instance metadata, per-draw vertex/index info, and an IndirectArgs buffer sized for VkDrawIndirectCommand/VkDrawIndexedIndirectCommand or dispatch args.

Generating Indirect Arguments

• Compute shader:
  • Read instance metadata and bounds, perform frustum/occlusion/LOD tests.
  • For each visible instance, append its draw record into a GPU-side Append/Consume buffer or write into a pre-sized slot using atomic counters.
  • Atomically increment a counter and write corresponding VkDrawIndexedIndirectCommand struct into IndirectArgs buffer.
• Example Vulkan indirect struct written by compute:

// in shader memory layout
struct DrawIndexedIndirect {
  uint indexCount;
  uint instanceCount;
  uint firstIndex;
  int  vertexOffset;
  uint firstInstance;
};

Buffer Layout & Memory

• Use SSBOs/storage buffers with std430 layout or device-host pooled allocations.
• Keep IndirectArgs and counters in device-local memory with transfer via transient mapped staging only for initial scene uploads.
• Keep per-frame ring buffers to avoid overwrite hazards.

Synchronization (avoid CPU readbacks)

• Use pipeline barriers between compute -> graphics:
  • memoryBarrier or VkBufferMemoryBarrier to ensure writes to IndirectArgs are visible to draw.
  • Submit compute command buffer, then in same VkQueue do vkCmdBindDescriptorSets + vkCmdDrawIndirect without host sync.
• Use GPU-side counters (atomics) to pack argument count; use DrawIndirectCount (vkCmdDrawIndirectCountKHR / vkCmdDrawIndexedIndirectCountKHR) to read a GPU-written counter so CPU doesn't read back.
• For multi-queue: use semaphores to signal completion of compute before graphics queue consumes args.

Expected Benefits

• Reduced CPU cost for culling/submit, better parallelism and higher draw counts.
• Lower CPU-GPU sync, better CPU frame time stability.
• Potential to cull many objects earlier (occlusion/LOD) and issue fewer draw calls via batching/instancing.

Pitfalls & Mitigations

• Increased GPU work; ensure compute is cheaper than saved CPU cost.
• Memory bandwidth: tightly pack data, use LOD/cluster culling to reduce work.
• Debugging complexity (visibility bugs, race conditions).
• GPU-driven pipelines can suffer on tile-based mobile GPUs — tune workgroup sizes and avoid heavy random memory access.
• Use fallback to CPU-driven path for older/limited GPUs.

Summary
Migrate by creating GPU-visible compact scene buffers, a compute cull that writes Vk-style indirect args via atomics, and use DrawIndirectCount with proper barriers/semaphores to avoid readbacks. Expect CPU savings and higher throughput, but watch memory layout, bandwidth, and platform-specific trade-offs.

Overview of Tick System
Unreal's Tick drives per-frame updates. Actors and Components implement Tick(float DeltaTime). Engine schedules ticks via TickGroups (PrePhysics, DuringPhysics, PostPhysics, etc.) so game, physics, and rendering steps run in correct order.

Actor vs Component Tick

• Actor::Tick is called on the Actor itself.
• UActorComponent::TickComponent is called for enabled components. Components inherit their owner Actor’s tick group unless overridden.
• Components can be registered/unregistered independently; disabling component tick avoids Actor-wide disabling.

TickGroups

• PrePhysics: update game logic that influences physics (apply forces, set transforms before physics step).
• DuringPhysics: used for integrators or procedural physics that must run while physics is updated.
• PostPhysics: read results after physics (e.g., apply animation driven by physics results).

When to set TickInterval / EnableOnlyWhenRendered

• TickInterval: use for lower-frequency updates (AI path replanning every 0.5s). Set PrimaryActorTick.TickInterval = 0.5f.
• bOnlyRelevantToOwner / SetTickableWhenPaused / bTickEvenWhenPaused provide context-specific control.
• bTickInEditor and bStartWithTickEnabled adjust other cases.
• bHidden or bOnlyOwnerSee and SetComponentTickEnabled(false) when not visible.
• Use PrimaryComponentTick.bStartWithTickEnabled = false and enable on visibility callbacks.

Avoiding unnecessary per-frame ticks

• Use bCanEverTick = false on classes that rarely need updates.
• Use culling: enable ticking only when visible (SetComponentTickEnabled in OnBeginPlay/OnEndPlay or using OnBecomeVisible events).
• Implement pooled, batched updates: maintain a manager that updates N actors per frame (round-robin) or schedule via timers.
• Use timers (GetWorldTimerManager().SetTimer) for infrequent work instead of Tick.
• Use level streaming and ticking groups per-level; disable ticks for offscreen levels.

Example: AI agents use timers for decision-making, only enable Tick during combat; visual effects components tick only when visible; physics-driven grappling runs in PrePhysics. These reduce CPU usage and scale to thousands of actors.

Direct answer

Catch it through the same kind of signal you would trust for any other regression, measured outcomes, not gut feeling, act quickly to reverse or adapt once the cause is confirmed, and communicate the reversal as new information rather than an admission of failure to hide.

Structured elaboration

Detection. The earlier a way exists to notice a change is not working, a metric, a specific complaint pattern, a scheduled checkpoint to review, the faster it gets caught. Relying on someone eventually complaining loudly enough is the slow, expensive version of detection.

Confirm before reversing. Rule out that something else caused the apparent harm, a coincidental change elsewhere, a measurement artifact, so the reversal actually targets the right cause.

Reverse or adapt, whichever is proportionate. A full reversal makes sense when the change is clearly net-negative and easy to undo. An adaptation, keeping the original intent but changing the mechanism, makes sense when the underlying feedback was sound but the specific implementation was wrong.

Communicate proactively, before being asked. Tell stakeholders what changed, why, and what was learned, framed around the decision and the new evidence, not around defending yourself or the person whose feedback it originally was.

Close the loop with the original feedback-giver specifically, separate from the broader stakeholder communication, since that relationship is the one most likely to feel awkward if left unaddressed.

Worked example

As a Frontend Developer, a design reviewer suggested collapsing a multi-step signup form into a single page to reduce friction, and the team implemented it. A few weeks after launch, session-replay reviews (recordings of real user sessions that let you watch exactly where someone got stuck) and support tickets both pointed to the same problem: users were abandoning partway through the long single page more than they had the previous multi-step version, the opposite of the intended effect. Detected this through a scheduled two-week checkpoint review set up specifically to catch exactly this kind of regression. Confirmed it was not a coincidental issue, traffic sources and device mix had not shifted, before acting, then adapted rather than fully reverting: kept the reduced field count the original feedback was really aiming for, but reintroduced a lightweight multi-step structure instead of one long page. Communicated the reversal proactively in the next team update, explaining what the checkpoint data showed and framing it as what was learned rather than just what was being changed back, and separately messaged the original reviewer directly to close the loop.

Trade-offs and pitfalls

Waiting for undeniable proof before reversing can let real harm continue longer than necessary; a reasonable, time-boxed checkpoint is usually better than requiring certainty. Framing the reversal defensively, or quietly reverting without explanation, damages trust more than the original mistake did. And reverting all the way back to the original state when only part of the change was the problem throws away the part of the feedback that was actually right.

Clarify requirements & constraints

• Real-time quest progress, multiple consumers (leaderboards, UI, analytics), replays for bug fixes, low-latency reads for gameplay, support per-player time-travel debugging.

Event schema

• Use immutable, versioned events (protobuf/Avro) for compactness and schema evolution:

{
  "event_id": "uuid",
  "player_id": "string",
  "quest_id": "string",
  "type": "QuestStarted|ObjectiveCompleted|QuestFailed|QuestCompleted|CheckpointSnapshot",
  "payload": { /* typed by event type */ },
  "sequence": 12345,
  "timestamp": "ISO8601",
  "schema_version": 2
}

• Payload typed (objective_id, progress_delta, position, metadata). Versioning field allows safe evolution.

Partitioning strategy

• Partition by player_id (hash) to keep per-player event order and enable efficient fan-out. Use composite key (player_id, quest_id) for very hot players/quests; route by consistent hashing so consumers can process contiguous ranges.

Retention & snapshotting

• Keep full event log for configurable retention (e.g., 90d hot, cold storage longer). Create periodic snapshots per (player_id, quest_id) after N events or time interval — store snapshot with last_sequence and state blob (quest state, completed objectives, timers). Snapshots accelerate replays: replay events after snapshot.sequence only.

Replay & time-travel debugging

• To replay a player's quest: load latest snapshot ≤ target time, stream events up to desired timestamp or sequence. Expose a debug API/UI to choose time or sequence and reconstruct projection in-memory to show UI; include "live diff" between states.
• For nondestructive debugging, run replay in isolated consumer or sandboxed VM; attach logging and deterministic RNG seeds to reproduce behavior.
• Provide checkpoints (CheckpointSnapshot events) at UX-visible milestones to support coarse-grained jumps.

Trade-offs

• Per-player partitioning increases partitions but gives ordering guarantees. Snapshot frequency balances storage vs. replay latency. Schema versioning avoids breaking consumers.

This model lets game systems and tools reconstruct any player's quest timeline fast, support deterministic replays for bugs, and scale to millions of players.

Direct answer

Busier shows up in hours worked and volume of output; better shows up in what I can now do that I couldn't a year ago, or the same thing done with meaningfully less support, time, or error. So the evidence I look for is about capability, not throughput, and I check it against a target I set at the start of the period, not just once at year-end.

Structured elaboration

• Separate volume from capability directly. Shipping more of the same kind of thing at the same difficulty is throughput, not growth. The real signal is a new kind of problem you can now handle, or an old one you can now handle faster, more independently, or with fewer mistakes.
• Mix countable signals with qualitative ones. Countable: time to complete a class of task, error or rework rate, how far up an escalation chain you can now handle without help. Qualitative: what kind of problem people now bring you first, what you no longer need to ask about that you used to.
• Set the target ahead of time and reassess on a cadence. I pick one to three specific capability targets at the start of the period and check progress partway through, rather than only asking the question for the first time at the annual review, so the year-end check is a confirmation, not a surprise.
• Make the evidence legible outside your own team. I translate it into plain terms someone without your team's internal jargon could understand, since the whole point of evidence is that it should be checkable by someone who wasn't there for the year.

Worked example

Looking back over a year, I could point to a genuinely higher volume of deals worked, but that alone wouldn't have told me much. What I actually used as evidence was that at the start of the year, I could not scope and answer a technical objection from a prospect without pulling in a senior colleague, and by year end I could handle the majority of those unaided, with the colleague only looped in for a small, specific category I'd deliberately flagged as still outside my depth. I'd set that as an explicit target back in the first quarter, checked in on it at the midpoint by tracking how often I still needed to escalate a technical question, saw the rate dropping, and by year-end had a concrete number to show: escalations for that category had gone from roughly half of relevant conversations to under a fifth. That was legible to someone outside my team too, since it didn't depend on knowing our internal process, just on understanding what "needed help" versus "didn't" meant.

Trade-offs and pitfalls

The most common mistake is citing volume metrics like tickets closed or hours logged as if they were proof of growth, when they mostly measure how busy you were, not what you're now capable of. The opposite mistake is a vague self-assessment with nothing checkable behind it, which doesn't hold up when someone outside the situation asks for evidence. Judging growth only once, at year-end, is also risky, since it means you find out too late if the year didn't actually build the capability you assumed it would.

Overview / States

• Patrol → Chase → Attack → ReturnToPatrol

Per-state data

• Patrol: waypoints[], currentIndex, patrolSpeed, waypointTimeout
• Chase: target (player), lastKnownPos, chaseSpeed, maxChaseTime, chaseTimer
• Attack: attackRange, attackCooldown, attackTimer
• ReturnToPatrol: returnPath[], returnSpeed, stuckTimer

Triggers & Transition Conditions

• Patrol -> Chase: Trigger = onPlayerSpotted(); Condition = distanceTo(player) < sightRange && lineOfSight
• Chase -> Attack: Condition = distanceTo(player) <= attackRange && attackTimer <= 0
• Attack -> Chase: Trigger = playerMovesOutOfRange OR attackCooldown; Condition = distanceTo(player) > attackRange
• Chase -> ReturnToPatrol: Condition = chaseTimer > maxChaseTime OR lostSightTooLong
• ReturnToPatrol -> Patrol: Condition = reachedNearestWaypoint

Entry / Exit actions

• Entry: reset relevant timers, set animation state, set speed/path
• Exit: stop attack animation, clear temporary targets, log transition

Timeouts

• Use per-state timers (chaseTimer, waypointTimeout). On timeout, force transitions (e.g., give up chase).

Debugging

• Runtime state name, timestamps, cause-of-transition logs
• Visualize: draw current target, sight cone, next waypoint; color-coded state gizmos
• Metrics: counters for transitions, average time in state

Pseudocode

enum State { Patrol, Chase, Attack, Return }
State state = Patrol;

void Update(float dt) {
  switch(state) {
    case Patrol:
      PatrolUpdate(dt);
      if (PlayerSpotted()) TransitionTo(State.Chase, "spotted");
      break;
    case Chase:
      ChaseUpdate(dt);
      if (DistanceToPlayer() <= attackRange && attackTimer<=0) TransitionTo(State.Attack, "in_range");
      else if (chaseTimer > maxChaseTime) TransitionTo(State.Return, "timeout");
      break;
    case Attack:
      AttackUpdate(dt);
      if (DistanceToPlayer() > attackRange) TransitionTo(State.Chase, "out_of_range");
      break;
    case Return:
      ReturnUpdate(dt);
      if (ReachedWaypoint()) TransitionTo(State.Patrol, "returned");
      break;
  }
}

void TransitionTo(State next, string reason) {
  ExitActions(state);
  LogStateChange(state, next, reason, Time.time);
  state = next;
  EnterActions(state);
}

Notes

• Keep transitions deterministic; guard with explicit conditions.
• For debugging add frame-only verbose flag to avoid perf impact.