Arcane Engine: an in-house OpenGL game engine built around deferred rendering

An in-house engine, and what that means for adoption

Arcane Engine is a real-time game engine developed and maintained by Tyrannical Games, and the README is direct about its purpose. A large focus of this project is to develop an in-house engine catered to building indie games, and the development roadmap will be game development driven, meaning it will be influenced by actually making games and prioritising features needed to ship great indie games.

That sentence reframes everything else in the repository. This is not an engine product with a compatibility promise. It is a working engine that a small studio uses to make its own games, published so that the code is available and so that other people can read it, use it or contribute to it. The engine is described as maintained and developed by Tyrannical Games, and the project site is at ershany.github.io.

The topic list gives the technical scope precisely: OpenGL, deferred rendering and forward rendering, physically based rendering, image-based lighting, HDR, GLSL, and graphics programming in general. The licence is MIT, the primary language is C++, and the last push to the repository was on 2026-08-14 with no GitHub releases.

For an evaluator the honest question is what kind of reader this is for. If you want a renderer to study, to extend, or to lift techniques from, this is a well-commented C++ codebase with a documented feature list and a stated body of reading behind it. If you want a dependency to ship a game on, you should read the roadmap and the release milestone first and be honest about the risk.

Forward and deferred, and why both are there

The first feature in the list is Forward plus Deferred Rendering, and having both in one engine is unusual enough to explain why the second exists.

The forward path draws geometry and shades it in one pass per light. It is simple, has no intermediate buffers, and handles transparency naturally, but every pixel pays the cost of every light that touches it. The deferred path rasterises geometry into buffers, then shades each pixel once with all lights, which is efficient for many lights but has trouble with transparency and needs extra memory and bandwidth.

The README shows the engine carries both and picks between them, and it shows the consequences. MSAA is described as Forward Path Anti-Aliasing and FXAA as Deferred Path Anti-Aliasing, which is a straightforward statement that the anti-aliasing technique differs by path because the techniques are not interchangeable between them.

The lighting model is physically based and specified in detail: Physically Based Rendering with Fresnel on Everything, a Cook Torrance Specular BRDF with Lambertian Diffuse, and a PBR Material System. Fresnel applied to everything is an unusual phrasing, and it is worth noticing because Fresnel is normally a term in the specular reflection equation rather than something applied across the shading model. The source list at the end of the README names Real-Time Rendering and the LearnOpenGL tutorials, which are the standard references for that kind of work, and the combination of PBR, IBL and volumetric effects is a graduate-level rendering stack rather than a beginner's engine.

The choice of an in-house engine that supports both paths is consistent with the stated goal, which is shipping games rather than being a general-purpose engine.

Image-based lighting through light and reflection probes

Light Probes and Reflection Probes are both listed, and both are annotated with IBL, image-based lighting. This is how the engine handles ambient and specular environment lighting without shipping an environment map per scene.

A light probe captures the irradiance at a set of positions in the scene and stores it, so a diffuse surface at that position knows how much light arrives from every direction. A reflection probe captures the scene's appearance from a point, which becomes the specular environment for objects nearby. The pair is what lets an object sit in a scene and look lit by it rather than by arbitrary constants.

The other lighting features are the conventional set: directional, point and spot light sources, and shadows for all three. Skybox Support handles the background, and Linear Lighting with Gamma Correction is the colour pipeline, with HDR and a Reinhard Tonemapper at the end of it.

Reinhard is a filmic-style tone mapping curve rather than a modern one, and the difference matters if you are comparing engines. It compresses highlights smoothly and has no obvious artefacts, but it desaturates as it approaches white, which is the behaviour later operators were introduced to fix. The README lists it as the engine's tonemapper, so it is a deliberate choice, but it is the kind of detail that shows how the rendering stack is assembled from the literature of its period.

Other screen-space effects listed are Screen Space Ambient Occlusion, Volumetric Cloud Rendering, Parallax Occlusion Mapping, Terrain Material Blending, Water plus Wave Simulation, and a post-processing stack of Bloom, Film Grain, Chromatic Aberration and Vignette. Emission Maps and Displacement Maps round out the material feature list.

The engine libraries and the ECS

The Engine Libraries section is short and says a lot about the project's dependencies. OpenGL 4.3+ is the graphics API. GLFW handles input and window creation. Model loading goes through ASSIMP, with bone data, which means skinned meshes and the animation system read from the same pipeline. ImGUI provides the UI, which is the usual choice for a developer tool and an in-game debug interface. STB handles image loading. And EnTT provides component storage and management.

The Entity Component System is listed as an engine feature, and EnTT is the reason it is cheap. EnTT is a header-only, sparse-set component store, so adding and removing components does not invalidate the others, which is the property that makes an archetype-free ECS practical in C++.

The Basic Animation Clip Player is listed without a fuller description, which is worth noting against the ASSIMP bone data support. The pieces are there for skinned animation, but the README does not describe a full animation system, so a reader should not assume a complete skeletal pipeline without checking the source.

A Debug Rendering API is listed among the features, and it sits naturally with ImGUI in the same list. For a project whose purpose is in-house development, a debug renderer is not a luxury, it is how the person building the game finds out what the GPU is actually doing.

The repository layout matches a Visual Studio project: an Arcane Engine.sln solution file, an Arcane/ directory for the engine, an Arcane Editor/ directory for the editor, Dependencies/, Setup/ and a premake5.lua build script. The premake file means the project generates its Visual Studio solution rather than requiring a specific IDE version to be installed.

How development is planned, and how to contribute

The development section is where the project's process shows. If you want to see what is currently being worked on, the README points at two Trello boards: a Rendering Trello and an Engine Trello. The Roadmap for Arcane's Releases section points at the Arcane v0.1 GitHub milestone.

So there is a public view of the work: what is rendering work, what is engine work, and what the first release is meant to contain. That is more transparency than most in-house engines published to GitHub offer, and it also tells you that v0.1 is a milestone rather than a released version, which is consistent with there being no GitHub releases.

Contributing is the standard fork and pull request flow, and the README lists the steps:

1. Create your feature branch (`git checkout -b new-feature-branch`)
1. Commit your changes (`git commit -m "A description for your feature"`)
1. Push to the branch (`git push origin new-feature-branch`)

The engine showcases a Tech Reel 2019 video, and the Sources section lists LearnOpenGL, Game Engine Architecture, Real-Time Rendering, GPU Gems, GPU Pro and the Hazel Series on YouTube. Those are the books and tutorials the renderer is built from, which is the closest thing to a design document the project has.

The Arcane TODO.txt file at the repository root and the Workflows and Setup directories are the other places to look for what is planned and what the build expects.

Where Arcane Engine is the wrong choice

Three limits are structural. The first is that this is not a supported product. There is no release history, the roadmap is a Trello board, and the stated purpose is a studio's own engine. If your project needs a bug fixed next week, or needs an LTS branch, or needs a compatibility statement against a graphics driver version, none of that exists here. The difference in approach against a productised engine is exactly that: a productised engine trades openness of internals for guarantees, and Arcane has made the opposite trade.

The second is the platform. The engine is built on OpenGL 4.3 with GLFW for the window, and there is no mention of DirectX, Vulkan, Metal, consoles or mobile. For a desktop Linux or Windows developer that is fine. For anyone targeting a console, a handheld with a different graphics API, or the web, it is a dead end, because the renderer is written against one API.

The third is the completeness of the feature list, read carefully. The animation support is a Basic Animation Clip Player, with no description of a full skeletal pipeline. There is no mention of physics, audio, resource streaming, build tools, asset pipelines or platform deployment. The feature list is a rendering feature list, and an engine that renders well is only part of what a game needs.

The alternative is a mature general-purpose engine such as Godot or Unity, which ship a complete toolchain with asset import, physics, audio, editor and platform exporters. The difference in approach is that those projects treat the engine as a product with a user base to serve, so every feature has to work for someone in general, while Arcane can implement exactly what one studio's next game needs and skip everything else. That is the right trade for a studio shipping its own games and the wrong one for anyone who needs a general engine, and the README is clear that this is the former.

Editorial conclusion

Arcane Engine suits a developer who wants to read and modify a complete renderer rather than configure an off-the-shelf one, since the source is the deliverable and the rendering pipeline is documented feature by feature in the README. It is the wrong tool if you need something you can pick up and ship, because the project describes itself as in-house and game-development driven rather than as a supported product, and it is the wrong tool if you are on a platform other than desktop OpenGL. Verify first which of the forward and deferred paths your content targets, since anti-aliasing and lighting features differ between them, and note that the last push was on 2026-08-14 with no GitHub releases.

Frequently asked questions

Official sources

1. Ershany/Arcane-Engine on GitHub
2. Issues
3. License: MIT
4. README