Design philosophy
A foundation,
not a cage.
VOID should remove work without removing choices. The normal path stays simple, while the deeper architecture remains available when your project needs control.
Useful defaults, not mandatory defaults.
Very low-level frameworks give you freedom, but often leave you rebuilding the same infrastructure. Large engines can solve more out of the box, but may also pull a project toward one workflow. VOID sits in the middle: provide the useful framework-level pieces, then expose the places where another solution may make sense.
Extend, don't fight.
The built-in implementation is not assumed to be the only implementation. Renderer backends, asset sources, atlas packing, log sinks, cameras, render targets, custom assets, and other systems expose extension points so projects can grow without requiring an engine fork.
Transparency matters.
A framework should be understandable. VOID aims to keep normal game code straightforward while avoiding hidden machinery that becomes impossible to work around later.
Start simple. Go deep when you need to.
You should not need to understand swap chains, native window handles, or backend contracts to draw your first sprite. Those systems belong underneath the easy path, not in front of it.
Focused by design.
VOID deliberately stays focused on framework-level systems. It does not need to absorb every possible game-development feature. Full physics, UI frameworks, and specialized game systems can come from your game or the libraries you choose.
Your game owns the decisions.
Use what works. Replace what doesn't. The defaults are there to save time, not to claim ownership of the project built on top of them.
See it in practice
The renderer follows the same rule.
OpenGL is included, but the public rendering architecture does not lock the rest of the framework to OpenGL.