Game Programming Patterns

What it is

Game Programming Patterns is Robert Nystrom’s book on the recurring software-design patterns that show up specifically in game / real-time / event-driven runtimes. It’s structured as ~20 named patterns, each with a chapter explaining the problem, the pattern, the trade-offs, when to use it, and when not to. The book is freely readable online; the patterns are language-agnostic; the companion repo holds the C++ example code under MIT.

For KN-86 this is the single most directly applicable pattern reference for the runtime architecture decisions still ahead. Several patterns map 1:1 onto KN-86 concerns already, and the book’s framing of “when to reach for the pattern” is unusually disciplined — Nystrom is honest about not over-applying any pattern.

Patterns directly applicable to KN-86

In rough priority order of v0.1 relevance:

• Game Loop. Nystrom’s chapter on the canonical loop (decoupled-update-and-render, fixed timestep, frame budget) is the textbook reference for what the KN-86 nOSh runtime’s main loop should look like. Directly applicable. Cross-link tuibox.md’s event-driven render loop — same pattern, smaller scale.
• Update Method. Each entity in the runtime gets an Update() call every tick. KN-86 cart content + chrome + CIPHER-LINE animation + boot animation + reveal effects all fit this model. Trivially applies.
• Command. Operations represented as objects (queued, undone, replayed). For KN-86: every TERM-line verb is a Command. The universal verb set (exwm.md lineage) + the navigation history (history-el.md lineage) both compose naturally on top of a Command-pattern foundation.
• Observer. State changes notify listeners. KN-86: when cart state changes, the chrome updates; when battery state changes, Row 0 updates; when a new CIPHER fragment arrives, the OLED ticker updates. Observer is the right structural shape.
• State. Finite-state-machine modeling. KN-86: every cart has a phase chain (already specified per software/runtime/orchestration.md); modeling that explicitly as a State pattern is the canonical answer.
• Dirty Flag. Track which regions of the scene changed since the last render; only repaint those. Directly applicable to KN-86’s nOSh render loop and aligns with the tuibox.md per-box dirty bit. Cross-link both.
• Object Pool. Reuse fixed allocations rather than per-tick alloc/free. Matches KEC Lisp’s arena discipline (ADR-0004).
• Spatial Partition. Indexing entities by location. Probably not v0.1 KN-86 (the 80×25 grid is small; full-scan is cheap). Park for a hypothetical map / strategy cart.
• Service Locator. Decoupled access to runtime services. KN-86: cart Lisp asks NoshAPI for “draw a sparkline” rather than knowing how sparklines are implemented. NoshAPI is the runtime’s service-locator surface.
• Subclass Sandbox. Cart authors get a sandboxed API surface; the runtime owns the dangerous parts. NoshAPI’s whole shape is this pattern.
• Type Object. Define behaviors by data rather than code. Useful for mission-template / cart-content authoring — a mission template is data the runtime executes, not code the runtime compiles. (Fe is a tree-walking interpreter, not a compiler — it evaluates the forms directly; either way the authoring feels like data.)

Key takeaways for KN-86

• Direct citation in docs/software/runtime/ architecture writing. When the nOSh runtime architecture gets its formal spec pass, cite Nystrom’s chapters by name — Game Loop, Update Method, Command, Observer, State, Dirty Flag, Object Pool, Service Locator, Subclass Sandbox, Type Object. The names are well-known to anyone who’s built a game-style runtime; citing them shortcuts a lot of architecture conversation.
• The book’s framing of “when not to use a pattern” is as important as the patterns themselves. KN-86 should not over-engineer toward elaborate object-oriented hierarchies for their own sake. Patterns are tools to reach for when the problem matches, not templates to apply universally. Worth a doctrine note.
• The C++ example code is MIT-licensed and freely usable. Algorithm-level patterns can be translated to KN-86’s C runtime + KEC Lisp cart authoring without license concern.
• Book prose is copyrighted. Cite, link, do not reproduce.

License note

• Code under MIT. Algorithm reference, freely usable.
• Book text copyrighted. Free to read online; do not reproduce in KN-86 documentation. Write KN-86’s own prose citing the patterns by name.

Image

No image downloaded.

Notes

• Strong direct cite candidate for the runtime architecture spec.
• Cross-link tuibox.md — explicit Dirty Flag implementation.
• Cross-link aethertune.md — the FFT visualizer + audio capture + UI render pipeline is a working real-time architecture worth comparing against Nystrom’s patterns.
• Cross-link l123.md — l123’s layered Rust architecture is a contemporary working example of “pattern-disciplined runtime separation.”