MWG framework architecture

Real module dependencies, read from src/ by walking its runtime import graph

MWG framework architecture Real module dependencies, read from src/ by walking its runtime import graph battle · 13 files · No renderer - usable from any renderer, or none battle 13 files simulation · 6 files · No renderer - usable from any renderer, or none simulation 6 files world · 8 files · No renderer - usable from any renderer, or none world 8 files actors · 24 files · No renderer - usable from any renderer, or none actors 24 files board · 9 files · No renderer - usable from any renderer, or none board 9 files roguelike · 25 files · No renderer - usable from any renderer, or none roguelike 25 files rpg · 12 files · No renderer - usable from any renderer, or none rpg 12 files i18n · 6 files · No renderer - usable from any renderer, or none i18n 6 files audio · 10 files · No renderer - usable from any renderer, or none audio 10 files two-d · 74 files · Renderer-facing · PixiJS two-d 74 files PixiJS 3d · 9 files · Renderer-facing · Babylon.js, optional 3d 9 files Babylon.js, optional core · 32 files · No renderer - usable from any renderer, or none · zero dependencies core 32 files zero dependencies assets · 6 files · Renderer-facing assets 6 files Renderer-facing No renderer - usable from any renderer, or none Legend Frontend Backend

core has zero dependencies

  • • Imports no other module and no renderer, enforced by tests/renderer-isolation.test.ts
  • • Every module in the No renderer group reaches it; lets a Babylon.js game reuse core's input, saves, RNG and scene stack unchanged

Renderer isolation

  • • Only two-d and 3d import a renderer package: PixiJS or Babylon.js
  • • assets is the one loader both renderers share for compiled resources

Genre modules build on the shared floor

  • • rpg, battle, roguelike and board each depend on core, never on each other's peers
  • • simulation layers procedural systems on top of roguelike's algorithms