Basic Game Development Patterns Questions

Understand and explain common game development patterns and when to use them. Core topics include object pooling for memory and allocation control, event systems such as publisher subscriber or observer patterns for decoupled communication, input handling strategies, game state management, coroutine and asynchronous patterns in modern engines, and spatial data structures such as quadtrees or spatial hashing for performance. Candidates should be able to implement, reason about complexity and memory trade offs, and describe optimizations or debugging approaches under time pressure.

EasyTechnical

27 practiced

Explain the Entity Component System (ECS) pattern and contrast it with inheritance-based game object design. Discuss benefits in memory layout, cache locality, iteration speed, and trade-offs such as tooling, debugging complexity, and developer ergonomics.

HardTechnical

30 practiced

Implement a loose quadtree in C++ that supports insertions of axis-aligned bounding boxes (AABB), removal, and range queries that return candidate entity IDs overlapping a query AABB. Handle objects larger than node size by storing them at an ancestor node, include configurable max depth and max objects per node for splitting, and provide complexity analysis for insertion and query.

Sample Answer

**Approach (brief)** Use a loose quadtree where each node stores objects whose AABB intersects the node's loose bounds. On insert, attempt to push object into child whose loose bounds fully contain the object's AABB; otherwise keep at current node. Split when object count > maxObjects and depth < maxDepth. Removal tracks node + ID; range query collects candidates by testing node loose bounds vs query and testing stored objects.

**C++ implementation (simplified, production would need pool allocators / handle reuse):**

cpp

#include <vector>
#include <memory>
#include <algorithm>
struct AABB { float x,y,w,h; bool intersects(const AABB& o) const {
  return x < o.x+o.w && o.x < x+w && y < o.y+o.h && o.y < y+h; }
  bool contains(const AABB& o) const {
  return x <= o.x && y <= o.y && x+w >= o.x+o.w && y+h >= o.y+o.h; } };

struct Item { int id; AABB box; };

struct Quad {
  AABB bounds; // tight bounds
  AABB loose;  // expanded by factor
  int depth;
  std::vector<Item> items;
  std::unique_ptr<Quad> children[4];
  int maxObjects, maxDepth;
  Quad(const AABB& b,int d,int mo,int md,float looseFactor)
    : bounds(b), depth(d), maxObjects(mo), maxDepth(md) {
    float padW = b.w*(looseFactor-1.0f)/2.0f;
    float padH = b.h*(looseFactor-1.0f)/2.0f;
    loose = {b.x - padW, b.y - padH, b.w + 2*padW, b.h + 2*padH};
  }
  int childIndexFor(const AABB& a) {
    float cx = bounds.x + bounds.w*0.5f, cy = bounds.y + bounds.h*0.5f;
    bool left = a.x + a.w <= cx;
    bool right = a.x >= cx;
    bool top = a.y + a.h <= cy;
    bool bottom = a.y >= cy;
    if ( (left || right) && (top || bottom) ) {
      if (left && top) return 0;
      if (right && top) return 1;
      if (left && bottom) return 2;
      return 3;
    }
    return -1;
  }
  void split(float looseFactor){
    if(children[0]) return;
    float hw = bounds.w*0.5f, hh = bounds.h*0.5f;
    for(int i=0;i<4;i++){
      AABB b;
      if(i==0) b = {bounds.x, bounds.y, hw, hh};
      if(i==1) b = {bounds.x+hw, bounds.y, hw, hh};
      if(i==2) b = {bounds.x, bounds.y+hh, hw, hh};
      if(i==3) b = {bounds.x+hw, bounds.y+hh, hw, hh};
      children[i] = std::make_unique<Quad>(b, depth+1, maxObjects, maxDepth, looseFactor);
    }
    // try to redistribute
    auto old = std::move(items);
    items.clear();
    for(auto &it : old) insert(it);
  }
  void insert(const Item& it, float looseFactor=1.5f){
    int idx = childIndexFor(it.box);
    if(idx != -1 && children[0]){
      // child exists
      if(children[idx]->loose.contains(it.box)){
        children[idx]->insert(it, looseFactor); return;
      }
    }
    // if we can go deeper but children don't exist, try splitting
    items.push_back(it);
    if((int)items.size() > maxObjects && depth < maxDepth){
      split(looseFactor);
    }
  }
  bool remove(int id, const AABB& box){
    auto it = std::find_if(items.begin(), items.end(), [&](const Item& i){ return i.id==id; });
    if(it!=items.end()){ items.erase(it); return true; }
    int idx = childIndexFor(box);
    if(idx!=-1 && children[0]) return children[idx]->remove(id, box);
    return false;
  }
  void query(const AABB& q, std::vector<int>& out){
    if(!loose.intersects(q)) return;
    for(auto &it: items) if(it.box.intersects(q)) out.push_back(it.id);
    if(children[0]) for(int i=0;i<4;i++) children[i]->query(q,out);
  }
};

**Key concepts & reasoning**- Loose bounds prevent deep propagation for slightly overlapping objects and reduce churn.- Objects larger than a child are kept at ancestor because child.loose.contains(...) check fails.- Splitting redistributes items when beneficial.

**Complexity**- Insertion average: O(log n) when well-distributed; worst-case O(n) if many overlap root or large objects.- Query: O(k + log n) average where k = candidates returned; worst-case O(n) if many nodes overlap query.

**Edge cases**- Extremely large objects stored at root.- Degenerate AABBs (zero area) — validate input.- Frequent insert/remove: consider spatial hashing or object handles and lazy refit to optimize.

HardSystem Design

28 practiced

Design a multi-layered spatial partitioning system separating static world geometry (used for collision and occlusion) and dynamic entities (players, NPCs, projectiles). Describe data structures for each layer (for example BVH or static quadtree for world geometry and dynamic AABB tree or spatial hash for moving entities), APIs for insertion, removal, update, and range queries, and algorithms to keep update costs low when dynamic entities move frequently.

Sample Answer

**Overview & goals**Design a two-layer spatial system: a static layer optimized for collision/occlusion that rarely changes, and a dynamic layer optimized for frequent inserts/updates/removals. Goals: fast broad-phase queries, low update cost for movers, predictable worst-case.

**Static layer (world geometry)**- Data structure: BVH (axis-aligned bounding boxes) or a static quadtree/loose octree for 3D.- Why: BVH gives tight bounds for occlusion and raycasts; static quadtree simpler for tile/terrain.- API: - Build(geometry_list) — bulk build (O(n log n) with SAH for BVH) - RayCast(ray, filter) → hit - QueryAABB(aabb) → list of static primitives- Notes: Rebuild offline or on big edits; use leaf-level triangle indices for narrow-phase.

**Dynamic layer (moving entities)**- Data structure: Dynamic AABB tree (broad-phase) + spatial hash grid for high-velocity small objects (projectiles).- Why: Dynamic AABB tree (like Box2D) supports efficient insert/remove/update; spatial hash has O(1) insert and cheap neighbor queries for dense, small objects.- API: - Insert(entity_id, aabb, payload) - Remove(entity_id) - Update(entity_id, new_aabb) — returns changed nodes for narrow-phase - QueryAABB(aabb) → list of entity_ids - QueryRadius(center, r) → list- Implementation details: store fat AABBs (margin) to reduce tree churn.

**Keeping update costs low**- Fat AABBs: give margin so small motion doesn't trigger tree rotations.- Lazy updates: only Update when entity leaves its fat AABB; otherwise update transform only.- Temporal coherence: sort entities by motion magnitude; skip static-like ones.- Hybrid approach: put slow entities in the dynamic tree but with larger fats; very fast small projectiles go to spatial hash updated per tick.- Batched re-inserts: accumulate moves and rebalance tree periodically rather than per object every frame.- Multithreading: queries read-only on static BVH; dynamic tree uses lock-free read-copy-update or per-core local buffers merged.

**Collision/occlusion flow**- Broad-phase: Query dynamic tree and spatial hash against static BVH via AABB overlap or hierarchical traversal.- Narrow-phase: fetch primitives from static leaves or per-entity colliders.- Occlusion: use BVH for occlusion queries and conservative rasterization for many small occluders.

**Trade-offs**- BVH best for complex static geometry; quadtree simpler for grid-based worlds.- Spatial hash lowest update cost but less accurate for large objects.- Fat AABB increases overlap tests but dramatically reduces tree churn.

This design balances low per-frame update cost for movers with precise static geometry queries required by collision and occlusion.

MediumSystem Design

31 practiced

Design an event bus for a mid-sized game engine used by UI, audio, gameplay, and analytics. Requirements: low allocation overhead, support for event filters or subjects, ability to unsubscribe safely during dispatch, and optional history/replay for late subscribers. Describe API, underlying data structures, memory and performance trade-offs, and how to implement safe unsubscribe while dispatching.

Sample Answer

**Design summary**EventBus: topic/subject-based, zero/allocation paths for hot dispatch, optional per-topic history buffer for replay. Use C++-style API for game engine suitability.

**API (example)**

cpp

using Event = variant<InputEvent, AudioEvent, GameplayEvent, AnalyticsEvent>;
using Token = uint32_t;
Token Subscribe(const string& topic, function<void(const Event&)> cb, int priority=0);
void Unsubscribe(Token t);
void Publish(const string& topic, const Event& e);
void EnableHistory(const string& topic, size_t capacity);
void ReplayHistory(const string& topic, Token subscriber);

**Data structures**- Topic map: unordered_map<string, Topic>- Topic: vector<Subscriber> subscribers (sorted by priority), optional circular buffer<Event> history- Subscriber: { Token id, callback*, filter predicate*, alive flag, generation }

Use single contiguous vectors and an object pool for Subscriber to avoid per-subscribe allocs.

**Safe unsubscribe during dispatch**- During Publish, snapshot a lightweight dispatch token: topic.generation++ then iterate subscribers by index.- Subscriber removal marks alive=false and pushes index to a tombstone list; does not immediately erase.- While dispatching, skip alive==false entries. After dispatch (or when tombstones exceed threshold) compact vector (stable erase) and bump generation.- Alternatively use generation numbers on subscriber; if subscriber.generation != dispatch.generation skip.

**Filters / subjects**- Support topic strings and predicate filters on Event contents. Predicate stored with Subscriber; evaluated inline before calling callback.

**History / replay**- Per-topic ring buffer storing events (move semantics). On Subscribe with replay, iterate buffer and dispatch to new subscriber (respecting filters) before adding to subscriber list.

**Memory & perf trade-offs**- Contiguous arrays: low per-event overhead, cache-friendly; compaction costs amortized.- Tombstones avoid allocation and allow safe concurrent unsubscribe; increases memory slightly.- History buffers add memory proportional to capacity; make optional and configurable per-topic.- For extreme low-latency, provide lock-free single-producer single-consumer variant for audio/input paths.

**Why this fits games**- Minimal runtime allocations, predictable memory, supports late-joining UI/analytics via replay, safe fast dispatch for gameplay and audio.

EasyTechnical

25 practiced

Compare quadtrees and spatial hashing for 2D games. For each structure explain typical memory usage, average and worst-case query complexity, update cost for moving objects, and specific scenarios where one outperforms the other (e.g., sparse large worlds vs dense uniform distributions).

Unlock Full Question Bank

Get access to hundreds of Basic Game Development Patterns interview questions and detailed answers.

Join thousands of developers preparing for their dream job.