A New Game Engine?
Yes we are. It's called the "Siege Engine". If you ask "why are you building yet another game engine?" the answer is mostly "because of the Rust language and what it promises." But we have to admit, the answer is also because we want to deeply understand and fully control everything.
We have no allusions or aspirations of competing with commercial game engines. We will probably never be a real-time editor. We wont have tools for game developers to program games with dropdown choices (only real coders with real code). But we will try to do all the major systems, and to do them well.
We think we can get more out of Vulkan than Unreal and Unity do. They added Vulkan on, but didn't design around it.
We think we can prevent cheating at a level of confidence that no Unreal Engine based game could ever hope to achieve (We believe Epic Games is still marketing an engine that fundementally was not designed for the Internet, but rather for LANs).
We also plan to open-source the client and network protocol eventually, both allowing players to build custom clients, and also allowing game developers to build their own compatible proprietary backend worlds.
Some of the things that go into a game engine include:
- Graphics Rendering, of course, including:
- Geometry rendering
- Lighting, ambient levels, exposure level/white point, point/directional/area lights
- Shading (forward, deferred, or otherwise. We do deferred shading).
- Shadows (shadow mapping)
- Transparency pass
- Blur and Effects
- Texturing with Mipmapping
- Model LOD (level of detail)
- Asset management, Asset Paging
- GPU Memory management (in Vulkan it is the responsibility of the app not the driver)
- Various custom rendering systems including
- Raleigh Scattering
- Terrain (and zone paging)
- Particle systems, fire/smoke
- Animations (bones/joints, skinning)
- Cameras/Viewports, projections
- Scene Graph, octree culling
- Sound, e.g. 3D Positioning, background music
- Keyboard/Mouse I/O
- Network protocol
- Generally UDP based
- Fast encryption/authentication
- Clock synchronization
- Latency compensation
- Game-independent generic command language
- Asset generation, including terrain generation, texture compression, etc
- A patch server
- A game server -- we dont talk much about our game server because that is where the most proprietary stuff lies. We will open-source the client and open the protocol, but we will never open the server (or people could easily cheat!)
- Support libraries for math, color management, asset management, etc