-
Notifications
You must be signed in to change notification settings - Fork 0
Philosophy
Engines like Unity and Unreal try to do everything. They give you physics, networking, UI, animation, visual scripting, and everything else you can think of.
The problem is your game is unique.
Take physics for example. A 2D platformer needs simple collision detection and gravity. A racing game needs vehicle physics with traction, weight transfer, and suspension. A puzzle game might need no physics at all. Yet Unity and Unreal force their physics systems on you whether you need them or not. You cant strip out what you dont need. You cant replace it with something better suited for your game.
Or take UI. Unity uses UGUI. Unreal uses UMG. You use what they give you or you fight the system to build something custom. This is why many Unity games use third-party UI solutions like Noesis or Coherent. They are fighting the built-in system because it doesn't fit their needs.
This is the hidden cost of big engines. You dont just pay with money. You pay with time fighting the engine. You pay with performance carrying systems you dont need. You pay with frustration when something doesn't work the way you expect.
You fight the engine instead of making your game.
At the other extreme, frameworks like MonoGame and FNA give you almost nothing. They handle rendering, windowing, and input. Thats it.
The problem is these systems are too basic. They give you the raw tools but none of the supporting infrastructure that every game needs.
Take rendering for example. MonoGame and FNA let you draw sprites. Thats it. If you want texture atlasing to reduce draw calls and improve performance, you have to build it yourself. You have to write your own packing algorithm, your own atlas management, your own defragmentation system. This is a significant amount of work that every game benefits from.
Or take asset loading. These frameworks give you file I/O. Thats it. If you want automatic asset caching, LRU eviction, or mount-based virtual file systems, you build it yourself. If you want encrypted asset packs to protect your work, you build that too.
Or take audio. They give you the ability to play sounds. Thats it. If you want pooling, priority-based voice stealing, or category volumes, you build it yourself. Every game needs these things but every developer has to rebuild them.
The same goes for saving, pathfinding, coroutines, and logging. These are solved problems. They have been solved thousands of times by thousands of developers. Why rebuild them every time?
You waste time reinventing wheels instead of making your game.
Void sits in the middle.
It gives you the essential building blocks every game needs: rendering, assets, input, audio, saving, pathfinding, coroutines, and logging. It then gets out of your way.
Unlike big engines, Void doesn't force you into rigid systems. You aren't locked into a specific physics engine or UI framework. You bring what you need and leave what you dont.
Unlike bare frameworks, Void doesn't make you rebuild solved problems. The essentials are already there, tested and working. You can focus on what makes your game unique instead of writing an audio system from scratch.
This balance is what makes Void different. You get the foundation without the bloat. You get the freedom without the friction.
Void doesn't tell you how to make your game. It gives you the tools and steps aside.
The engine is built around interfaces and base classes, not rigid systems. You can swap out any part without fighting the framework. This keeps your code clean, your options open, and your game your own.
Here is how that works in practice:
Every major system in Void exposes an interface. Want a different texture packing algorithm? Implement IAtlasPacker and plug it in. Need assets from a network drive or cloud storage? Implement IMount and add it to the system. Want logs sent to a database instead of a file? Implement ILogSink and register it. Need to save custom data types? Inherit from ContentTypeWriterReader and the save system handles the rest.
You dont modify the engine code. You dont fork the repository. You just implement the interface and register it. The engine finds it and uses it.
When you release a game, your assets are your intellectual property. Art, music, levels, dialogue. These represent money, time, and creative work.
Here is how the problem works in practice:
- Someone buys your game on a platform like Steam or Itch.io
- They use readily available extraction tools to open your asset files
- They pull out every image, sound file, and level
- They list your entire asset library on asset stores as "Royalty Free" or "Commercial Use"
- Other developers buy these assets thinking they are legitimate
- Those developers use your assets in their own games and release them
- You discover your work being sold and used without your permission
- Those developers get DMCA takedown notices because they unknowingly used stolen work
- Everyone loses time, money, and reputation
This is not hypothetical. It happens constantly. Most engines leave your assets exposed by default. Unity asset bundles can be opened with free tools. Unreal PAK files are well documented. MonoGame and FNA leave everything as loose files on disk.
Void takes a different approach. Asset protection is built into the foundation.
Assets are packed into encrypted, tamper-proof archives using AES-GCM 256-bit encryption. The same standard used by governments and militaries. Without the key, the pack is just random bytes. Extraction tools do not work. Your work stays yours.
- Indie developers who want a lightweight foundation without rebuilding everything
- Teams that need asset protection built in
- Anyone tired of fighting their engine
- AAA studios that need a low-level, customizable framework without the bloat of monolithic engines
Void is lightweight enough for small projects and robust enough for large-scale development. The extensibility and asset protection systems scale to any size team or project.