Game development interview bank

A normal method runs until it returns, while a coroutine can suspend at yield return and continue during a later player-loop step. The C# compiler represents that method as an IEnumerator state machine, so its position and live locals survive between resumptions. This does not create a worker thread. Each synchronous segment still runs on Unity’s main thread and must finish before control returns. A blocking read, Thread.Sleep, or expensive loop inside a coroutine therefore stalls the frame just as it would inside Update.

Choose from the clock named by the requirement. WaitForSeconds follows scaled game time, so changing Time.timeScale changes its progress and a zero time scale suspends it. That suits gameplay delays that should pause with the simulation. WaitForSecondsRealtime follows unscaled time, so it suits pause-menu notices and real-world timeouts. Neither is an exact wall-clock alarm: resumption happens on an eligible frame after the duration. For deadlines or countdown displays, retain a target time and recompute the remainder instead of decrementing once per wait.

Update follows rendered frames and is the usual place to sample input, advance non-physics state, and use Time.deltaTime. FixedUpdate follows the physics timestep; a rendered frame can have zero or several fixed steps, so Rigidbody forces and physics-state writes belong there. Carry continuous input as the latest value and buffer one-shot actions until a fixed step consumes them. LateUpdate runs after the normal Update phase and suits consumers such as a camera that reads a target pose changed earlier in the frame. It supplies an ordering boundary, not automatic smoothing or a guaranteed order among every LateUpdate instance.

Let the component that owns the affected state also own the running Coroutine handle. Decide whether a repeated request is ignored, queued, run in parallel, or replaces the current run. For replacement, stop the saved handle before starting another and clear the field on completion and lifecycle shutdown. Do not create a fresh IEnumerator and expect it to identify the running instance. Also encode lifecycle policy explicitly: disabling a MonoBehaviour does not stop its coroutines, while deactivating its GameObject does, and reactivation does not resume a stopped iterator.

First decide whether the listener should receive events only while active or for the whole component lifetime. Active-period ownership maps cleanly to subscribe in OnEnable and unsubscribe in OnDisable; both callbacks can repeat, so the pair remains symmetric after re-enable. Subscribing in Start and removing in OnDisable is broken because Start runs only once. If a disabled component must keep listening, use a longer explicit ownership boundary and make destruction and never-activated objects part of the policy. I prefer a named handler over matching lambda expressions because removing a newly created lambda does not remove the delegate that was originally registered.

Use a coroutine for a short main-thread flow organized around frames, Unity yield instructions, and scene-object changes. Awaitable is often clearer when callers need return values, normal async composition, exception propagation, or cancellation across I/O and Unity asynchronous APIs. Use the Job System, often with Burst, when the goal is parallel CPU work over data. None of these choices makes arbitrary synchronous code non-blocking. Before selecting one, state which thread performs the work, who owns cancellation, and how completion or failure reaches the caller.

An archetype is the exact set of component types on an entity. Entities with one archetype are stored in 16 KiB chunks containing one packed array per component type. Systems query matching archetypes and traverse those arrays. Component boundaries therefore affect chunk capacity and memory traffic: a large rarely read field inside a hot component is carried through the hot path. Adding or removing a component moves the entity to another archetype, and too many tag combinations can multiply archetypes. I design around measured access patterns, then inspect chunk occupancy and structural changes rather than assuming smaller components are always better.

state.Dependency carries the JobHandles that this system must respect because earlier work has overlapping component access. A scheduled job should normally receive that handle, and its returned handle must be assigned back so later systems can observe the new dependency. Passing only one side is incomplete: omitting the input can race earlier work, while discarding the output hides this job from later work. Complete is reserved for a boundary where synchronous code immediately consumes the result. Calling it after every schedule is correct only by accident and serializes work that the scheduler could otherwise overlap.

Use an EntityCommandBuffer when the operation genuinely changes storage shape, such as creating an entity or adding and removing a component, and the decision occurs inside a job or query iteration. The buffer records now and mutates storage at its playback point. Use an enableable component when the component type and storage should remain present but a frequently changing state should affect query matching. Toggling its enabled bit avoids moving the entity between archetypes. The choices are not equivalent: ECB playback has visibility timing, while enableable data still occupies chunk space and can create dependency-related sync points.

Start with a Profiler capture that names the original bottleneck. Compare equivalent behavior under fixed scene input, target device, Player build settings, frame-rate policy, and sampling interval. Record main-thread time, worker time, waits, allocations, structural changes, and entity count. Confirm in the Burst Inspector and build logs that the intended jobs were Burst compiled; Play mode can execute managed fallback code while Burst compiles. Warm up one-time compilation and loading costs before measuring steady state. If the original limit is GPU, rendering, network, or disk work, an ECS rewrite may not improve frame time.

A GameObject provides identity, activation state, hierarchy membership, tags, layers, and ownership of components. Its components provide capabilities: Transform supplies spatial state, renderers draw, colliders participate in physics queries, and MonoBehaviour scripts add project behavior. I prefer several focused components over a deep inheritance tree because each dependency remains visible in the Inspector and can be tested separately. A required same-object dependency belongs in RequireComponent plus startup validation; a reference to another object should be wired or registered explicitly rather than rediscovered by name every frame.

The initializer supplies a starting value when a component is created, but a scene or Prefab then stores its own serialized value. On loading, that authoring data takes precedence, so an existing speed of 3 can remain 3 after the initializer becomes 5. I inspect the component and Prefab overrides before blaming compilation. If all existing assets need the new value, that is a data migration, not a default change. I also use private serialized fields for Inspector input and reserve public members for intentional runtime APIs.

For one initially active, enabled instance, Awake runs before OnEnable and Start runs before its first frame update. OnEnable may repeat after disable-enable cycles, while Start runs once in that instance lifetime. An inactive scene object delays Awake until activation. I do not assume an order between Awake calls on different GameObjects unless the project configures one. Same-object references can be established in Awake; cross-object readiness needs an explicit bootstrap phase, event, or documented execution-order rule. OnEnable subscriptions should always have matching OnDisable unsubscriptions.

For one initially active and enabled instance, Awake precedes OnEnable, and Start runs once before that instance receives its first frame update. OnEnable can repeat after every disable-enable cycle, while Awake and Start do not. For scene objects already active at startup, their Awake calls finish before any Start call, but Unity does not define the relative Awake order of different GameObjects by default. Runtime instantiation also introduces new Awake calls later. I keep self-setup in Awake and represent cross-object readiness with a bootstrap, registration event, or narrowly documented Script Execution Order rule.

The Prefab asset is the reusable source hierarchy stored in the project. A scene or runtime instance is an object created from that source. A scene instance can record overrides relative to the asset, so later asset changes flow only into properties the instance has not overridden. Apply moves selected instance overrides back to the asset; Revert discards them from the instance. Runtime edits normally change only the clone and disappear when Play mode ends. I diagnose setup bugs by inspecting all three layers, because the script alone does not reveal serialized references or hidden overrides.

I first compare the exact method name, return type, and parameters with the current Unity message signature. Awake and Update are engine messages, not virtual MonoBehaviour methods, so an invented override, OnEnabled spelling, or extra parameter is wrong even when the method looks plausible. Next I inspect the GameObject active state, the Behaviour enabled state, and whether an initially inactive object has ever activated. Then I reproduce one transition with a minimal probe or Play Mode test. Script Execution Order cannot make an unrecognized method run; it only orders recognized callbacks for configured script classes.

I start with ownership and persistence. A ScriptableObject fits shared authoring data that needs Unity asset identity, Inspector editing, and references to other Unity assets. A MonoBehaviour fits state or behavior owned by one GameObject and driven by scene lifecycle. An ordinary C# object fits runtime state that needs neither asset identity nor component callbacks. I do not choose ScriptableObject merely to make fields visible in the Inspector. I also state who creates the object, whether changes must survive a launch, and who releases transient Unity objects.

I classify every field as authoring definition, per-owner state, or cache. The asset keeps values such as maximum health, base damage, and visual references behind read-only runtime APIs. Each consumer owns current health, cooldowns, and progress in its component or a plain state object. If an existing API requires a mutable ScriptableObject, I clone the template once, initialize it explicitly, and give one owner responsibility for destruction. My test uses two consumers with the same asset, mutates one, and verifies that the other consumer and source asset remain unchanged.

I store a project-defined stable content ID, not the ScriptableObject itself, GetInstanceID, or an editor asset path. The save DTO also carries mutable values such as quantity or durability. During load, a catalog resolves the ID to the current asset and reports unknown IDs with enough context to diagnose the save. IDs need uniqueness validation and a migration policy because they outlive asset renames and may appear in telemetry or backend data. A round-trip test must serialize to text or bytes, reconstruct the DTO, and resolve it in a fresh object graph.

I check serialization and Play mode lifecycle claims against 6.6 rather than old tutorials. Compatible Dictionary fields marked SerializeField are now serialized natively, although multidimensional arrays, jagged arrays, and directly nested collections still have limits. New 6.6 projects also enter Play mode without reloading the script domain by default, so caches and event handlers cannot assume an automatic reset. I verify any OnEnable reset against the actual session boundary, run save-reload tests for authored assets, and build a Player to catch UnityEditor APIs that accidentally escaped editor-only assemblies.