Games
Hold the backend of your game — its catalog entry, the engine it runs on, and the rooms, spells, items, connections and effects it declares.
Where a game’s content lives, not where it runs.
Every game needs somewhere to keep what it’s made of before an engine can read any of it. Games is that place — the catalog entry, the engine pointer, and everything the game declares, kept in one address instead of scattered across whatever storage the engine happens to bring with it.
A game needs a backend before it needs an engine.
Building a game already means building an engine. Building it a second time — a place to keep everything the game declares, and to hand it back when the engine asks — is work no engine should have to repeat. Games is that backend, built once and shared by whatever engine you point at it.
Five things, in order.
Name it
the game’s catalog entry: what it’s called, what it’s about.
Point it at an engine
which runtime plays it.
Declare its content
the rooms, spells, items, and everything else the game defines.
Connect that content
the edges between what you declared: which room leads where, which spell needs what.
Say what happens, and when
the effect each declared thing applies.
Create a game, then build out from it.
- Create a game and point it at the engine that runs it.
- Declare what the game is made of — its rooms, spells, items, and the rest.
- Connect the pieces and say what each one does when it happens.