A small
machine
for strange
worlds
A Rust game runtime with explicit limits, understandable resource use, and a minimalist aesthetic out of 1990s engines. Modern graphics where they serve. Direct control, compact representations, fast iteration, and a machine you can understand without wading through layers of infrastructure.
The central hypothesis
Carefully chosen technical constraints can produce expressive systems, unexpected strategies, and distinctive gameplay.
This is a philosophy for an initial prototype. Numerical budgets and specific backend choices remain open.
The machine has a comprehensible shape
Small enough for one person to understand its central mechanisms.
A developer should be able to explain where memory lives, what executes each frame, how assets become available, and what happens during a scene transition.
Prefer explicit data structures and execution order. Introduce abstractions when they clarify a real system or remove meaningful repetition.
Resources have explicit budgets
Capacity exhaustion must never silently corrupt state.
Actors, scene storage, draw commands, audio voices: every significant resource
has a visible capacity and an owner. Unbounded growth is a deliberate exception.
A Vec is fine where its growth and lifetime serve a clear purpose; it
is not the automatic answer to every collection.
Every bounded system defines its behavior at capacity: reject the operation, replace an existing object, degrade presentation, or report a development error.
Click a live slot to free it; its generation bumps. The log keeps 6 lines and drops the oldest.
Constraints should earn their place
Remove the ones that generate effort without value.
Choose constraints that improve comprehensibility, responsiveness, or creative possibility. A useful constraint encourages a compact representation or an interesting interaction. A poor one produces repetitive bookkeeping without improving the game.
Do not reproduce historical hardware limits for authenticity. Adopt restrictions experimentally.
Technical rules can become world rules
Incidental backend behavior should not determine the rules of the world.
Some resource limits and computational mechanisms are eligible to become gameplay. Shared storage might create dependencies between spells. A bounded simulation might make creation require reclamation. A small behavior language might let creatures and mechanisms be reprogrammed.
These are possibilities to investigate, not features committed to. When a technical rule does become gameplay, it must be stable enough for players to learn and exploit.
Compact representations create greater expression
Discover useful little machines, not a virtual machine inside every subsystem.
Favor systems in which a small vocabulary combines into many outcomes. A compact program, construction grammar, or shared simulation rule can say more than a large catalog of authored exceptions.
Interpreters and bytecode arrive only when a concrete game system benefits. Their execution limits, state and failure behavior must be inspectable. (The pattern behind this page is four rules on a fixed 160×96 grid.)
Responsiveness is part of the aesthetic
A modest world that responds immediately.
Protect fast startup, quick scene transitions, and short edit–run cycles. Prepare assets offline when that reduces runtime work. Keep loading paths explicit and measure their costs.
Scene transitions have understandable ownership changes and reclamation behavior. Prefer immediacy over unnecessary runtime machinery.
Modern graphics, minimal game architecture
Gameplay should not need to manage graphics API objects.
Use a modern graphics backend where appropriate, weighed against target platforms and implementation cost. Immediate-mode submission is an option, not a requirement; persistent GPU resources, batching and retained data all fit.
Keep graphics backend complexity behind a narrow boundary.
Build a game before a general-purpose engine
Extract reusable machinery from demonstrated needs.
Develop the runtime alongside a small playable experiment. Delay general-purpose editors, plugin systems, broad platform support and elaborate extension mechanisms.
Success means the prototype is enjoyable to develop and produces interesting play within its limits.
Keep them apart
World limits are not implementation limits
Increasing a draw buffer should not change which spells can exist. A spell budget exposed to players stays the same across graphics backends.
World limit
Belongs to the game’s rules. Players may learn it, lean on it, exploit it.
Implementation limit
Belongs to the renderer, the mixer, the loader. Players should never be able to tell where it sits.
For every budget, write down
- What it limits, and who owns it.
- Why the limit exists.
- What happens when it is reached.
- Whether players can observe or manipulate it.
Architectural direction
A no_std core in a conventional shell
no_std is a dependency boundary, not proof of allocation freedom. Where
allocation is allowed is defined separately, starting from none during steady-state
gameplay. The shell owns the operating system: graphics, input, audio devices, files.
Tools and asset processing use the standard library freely.
Starting points to evaluate, not mandates to build custom allocators everywhere. Prefer safe Rust; isolate and justify any unsafe.
The rule that makes the rest work
A principle that matters is enforced by something that fails
Pillars are aspirations, and prose asking people to remember things is how a codebase quietly stops meaning them. So the ones that matter become a test, a lint, a bound, or a type that does not compile.
To add a principle, add a check. When a check is inconvenient, reconsider the design, not the check.
First prototype
One constraint players can exploit
A small playable space with a scene transition, a few interacting entities, basic rendering and sound, and one deliberately constrained gameplay system. Everything else gets enough room not to obscure the experiment.
- Is the central runtime easy to explain and modify?
- Do allocation and resource lifetimes follow the intended policy?
- Do scene changes feel immediate and reclaim resources correctly?
- Does reaching capacity produce deliberate behavior?
- Does the constraint create an interesting decision, or an unexpected interaction?
Measure before setting final budgets. Preserve useful surprises: when an interaction produces an exploit, ask whether it is understandable, consistent and interesting before removing it.
A small, legible machine whose limitations become material for invention.