Skip to content

CONCEPT Cited by 1 source

Game engine architecture

Game engine architecture is the composition discipline in which an application is built as a small foundation of performance-critical systems (graphics/rendering, input/control) plus a larger set of composable systems (multiplayer, physics/collision, animation, AI, audio, …) layered over that foundation, each with a defined boundary other systems can observe, drive, or extend.

The vocabulary — "systems" as the unit of composition — and the two-tier shape (foundation + layered systems) are the transplantable parts. The specific systems a game engine needs depend on the game (Minecraft needs physics + NPC AI + combat; a puzzle game doesn't); the architectural contribution is how systems compose so each new capability lands as a named system rather than accreted code.

The foundation

Nearly all game engines start from the same two systems:

  1. Graphics / rendering — displays objects and effects on screen.
  2. Input / control — lets the user take action in the world.

Additional systems layer over that foundation as the product demands.

(Source: sources/2026-04-21-figma-how-figma-draws-inspiration-from-the-gaming-world)

Figma as a non-game instance

Figma is explicit that its client architecture is shaped more like a game engine than a web stack: "We have opted to use a tech stack that looks more similar to a game engine's stack than a web stack."

Figma's foundation is the same pair — a state-of-the-art 2D graphics/rendering system (C++ compiled to WebAssembly) plus a control system (cursor / keyboard / keyboard shortcuts for accessibility). Systems layered on top (partial list from the post):

  • Multiplayer — real-time collaboration (systems/figma-multiplayer-querygraph). Named after cooperative games.
  • Collision engine — "figures out what your cursor is hovering over and how to connect items together."
  • Animation — spring animations
  • (later) the canvas-animation framework for observer-side multiplayer smoothing (patterns/observer-vs-actor-animation).
  • Chat / audio — cursor chat + audio call.
  • Auto layout — visual organization primitive.
  • Component / variant — asset-library primitives.
  • Widget / plugin — user-extensible systems.
  • Plus many Figma-specific systems (comments, billing, permissions, parameter runtime, materializer, etc.).

"Systems can come in all shapes and sizes. For every core structural system, we can also build a delightful, smaller system on top of it."

Two consequences for architecture

  1. Every feature lands as a named system. New product capability → new named system with a defined boundary, not accreted logic inside an existing system. Makes composition auditable and ownership explicit.
  2. Systems interact, so bugs cross boundaries. "When you are building a series of interdependent systems, any changes in one system will affect another." → concepts/interdependent-systems.

Whole-system-complementing over per-system depth

The discipline's failure mode: over-investing in one system while starving its neighbors. Post's game-industry framing: "Everyone is hyper-focused on the graphics, so developers spend most of their time improving the rendering system. But without also investing in the animation system or texture art, the game might look jagged and wonky." Figma's translation: "we need to take a step back and look at the big picture, ensuring that every system complements the others."

Seen in

Last updated · 200 distilled / 1,178 read