Introducing Lithium
Why we built a small, explicit framework for modular s&box games and what its first stable building blocks look like.
The Panic Department
Lithium maintainers
Lithium started with a practical question: how can an s&box project grow without every gameplay system becoming aware of every other system?
The answer is not a larger abstraction layer. It is a small set of explicit contracts for packages, lifecycle and communication.
A framework that stays out of the way
Lithium treats features as addons with a clear package identity. An addon owns its startup and shutdown behavior, while shared runtime systems live in scene-owned component services.
That separation keeps feature code portable and makes dependencies visible before they become hidden runtime assumptions.
The first building blocks
The initial public surface focuses on four ideas:
- addon packages with explicit identity;
- component services that follow the s&box scene lifecycle;
- dependency manifests for ordering and compatibility;
- named events for communication across feature boundaries.
Each piece can be used independently. Together, they create a predictable path from a small prototype to a project with multiple packages.
What comes next
We will use this blog to share design decisions, migration notes and implementation patterns that are too contextual for API documentation. The documentation remains the source for contracts; these articles explain why those contracts exist.