Elegy Engine

Overview
Philosophy
About

Note: This engine is a very early work in progress! 🛠
Check out the development articles and the roadmap.

Modular - Plug-in, plug-out

Elegy is practically a framework. There are several modules to facilitate game and app development. Or even CLI tools! You can extend the engine with plugins too.

Retromodern - Best of both worlds

From Quake and Source: modding out of the box, no "importing", no "projects", no waiting for shaders, and yes to baked lighting and occlusion culling. From modern engines: mainstream file formats like glTF 2.0, physics, ECS, no weird asset limits.

Optimised - Light as a feather

Written in high-performance C#, with a Vulkan backend and small filesize, Elegy swiftly runs on hardware from 8 years ago. It also provides you with plenty tools to optimise your game!

Productive - Batteries included!!!

That's right! The Elegy Game SDK has you covered: client-server model, weapon system, AI system, player controllers, all out of the box. Make games by modding!

Note: This engine is a very early work in progress! 🛠
Check out the development articles and the roadmap.

General workflow

In mainstream game engines, you have a centralised editor where you import assets, place them in a scene, and you run the game in-editor. That is not how we do things around here.

Instead, you just place assets into directories, and run the game. There's no import step. Simply export your glTF from Blender into a location like game/models/ and you're done, it's ready to be used.

There is no concept of a "project" or "exporting" the game, either. The game is the project, and the project is the game.

In short, it's just you and the filesystem. No fluff.

Modding

It should never be the gamedev's job to explicitly add mod support later on. That's why Elegy provides this out of the box, as part of its virtual filesystem.

There are two kinds of mods: addons and "game-mods", mods for short. Addons are smaller in scope and replace one or more game assets (models, sounds, scripts...). Full-on mods can be total conversions and they override a lot of content from the base game, including code. This is rarer, but it is possible and allows one to easily get into game development.

Ultimately, this means easier Workshop support, and installing mods outside of that is as simple as extracting a zip archive. The modding experience is consistent and predictable across all games made in this engine.

A modding-unfriendly developer would have to actively work against this mechanism, as opposed to modding-friendly developers having to actively work to achieve it.

Graphics

Today's games suffer from all kinds of things. Noisy visuals, smearing, horrid rendering inefficiencies, thousands of shaders affecting loading times. Even "retro" games tend to suffer from some of these - and that is especially unacceptable.

Elegy sticks to more old-school techniques. Lightmapping does not need denoising at runtime. MSAA does not smear. The best occlusion culling is the precomputed kind. That is not to say we don't innovate on any of that. The lightmaps are rather dynamic, for one!

There is a concept of a "rendering style", which defines how surfaces are to be shaded. The builtin styles include RenderStyle99 and RenderStyle2004. One looks very much like Unreal and Quake 3, while the other looks like Half-Life 2.

You can write your own, and nobody prevents you from implementing a modern path-tracer or even virtualised geometry. You could go even further into the past and go all-in on vertex lighting, or sprites and sector lighting. That's entirely up to you.

For simplicity, the engine also sticks to one graphics API: Vulkan. It supports the desired platforms, and avoids some of the headaches (and overhead) when working with multiple GAPIs.

Level design

There is no "Elegy level editor". Instead, there is first-class support for TrenchBroom, the Quake level editor. There is also partial support for J.A.C.K. and NetRadiant-custom.

You make your levels directly in the level editor, build the geometry, place all entities inside, set up logic, triggers and lights, and bake the level to test it. For fast iteration, there are fast baking modes, and the same goes for final, high-quality bakes.

You can still utilise Blender and other 3D modellers to author secondary level geometry. Terrain, complex organic pieces etc. can be embedded into the level. Furniture and other props can also be placed in the level editor as reusable prop entities.

On top of that, the game SDK provides you with plenty of builtin entities to play with. Triggers, logic entities, buttons, doors, moving platforms and the like.

Responsibility

Certain mainstream game engines are quite irresponsible with their workflows. They make it very easy to do the wrong thing.

Techniques like node-based shaders are great for rapid iteration and prototyping, but in mainstream implementations they are extremely easy to spiral out of control, generating thousands of shader permutations. This can be done responsibly.

Another one is occlusion culling. Modern engines, in their attempt to be super generic, let you forget about it. There are hardware occlusion queries, hi-Z culling, all done in real time. This is great for games that are completely dynamic, but for mostly static environments it's a great upfront cost. 100% realtime lighting is similar.

The worst part is that beginners are unaware of it. The path of least resistance is usually the default, and there is no incentive to learn the more efficient path. They are not taught to pick a strategy, they are subconsciously taught to use a hammer and that everything is, in effect, a nail.

Elegy tries to be responsible. Lighting is mostly static. Dynamic lights are only to be used when necessary, e.g. player flashlights or other moving lights. Occlusion culling is baked, with dynamic culling options for situations where those are beneficial.

Architecure

Even though Elegy is a specialised engine, the underlying systems are mostly generic. Subsystems (logging, VFS, plugins) are highly independent of each other. You can take whatever you like and use it in a whole other project.

What the "engine" really is, is just some glue code that initialises all these systems in order, expects a certain structure and runs some special logic to run an app/game.

This makes things a little complex, but the reward is that the whole thing can be reused across CLI tools, GUI tools, games and even completely unrelated apps.