# Overload: A C++20 3D Engine Where Lua Is the Gameplay Language

> Overload is an MIT-licensed 3D engine and editor built around C++20, OpenGL 4.5 and Lua scripting. Its 11-module split and Premake build are the interesting parts, and its Windows-only build target is the constraint that decides most adoption questions.

**Overload-Technologies/Overload** — 3D game engine with lua scripting

- Repository: https://github.com/Overload-Technologies/Overload
- Website: https://overloadengine.org/
- Stars: 2,488 · Forks: 289
- Language: C++
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/overload-technologies-overload

## What Overload Solves, and for Whom

Overload is a free, open-source 3D game engine written in C++ with Lua as its scripting language. The README states it began in 2019 as a graduation project by Benjamin VIRANIN, Max BRUN and Adrien GIVRY, and has since become a community-driven initiative. The stated pillars are ease of use, simplicity, pragmatic design, documentation and modern C++20.

The audience is narrower than the feature list suggests. Because gameplay logic runs in Lua while the engine itself stays in C++20, Overload suits people who want to write game behaviour without rebuilding a C++ binary each time, but who are still willing to work inside an editor that ships with the engine rather than a general-purpose IDE. The engine ships two executables: OvGame, described as a data-driven executable for any game built with Overload, and OvEditor, the editor used to build the game. That split matters. Your game is data plus Lua, and OvGame is the runtime that consumes it.

It is not aimed at teams that need console targets or a decade of shipped titles behind the toolchain. The README lists Windows game building as a feature, and the platform badge on the repository points at Windows. Everything else in the feature list (Lua scripting, prefabs, physically-based rendering, custom shaders, profiling, material editor, spatial audio, rigidbody physics, skeletal animation) describes what the editor and runtime can do, not what platforms they ship to.

## The 11-Module Split Inside Overload

The architecture section is the most concrete part of the README, and it is worth reading before you clone anything. Overload divides into 11 modules: 9 libraries forming the SDK, plus 2 applications.

The SDK libraries are named by responsibility. OvDebug handles logging and assertions. OvTools covers serialization, file system, platform, events and clock. OvMaths provides vectors, matrices, quaternions and transforms. OvAudio wraps SoLoud. OvPhysics wraps Bullet3. OvRendering wraps BareGL, described in the dependency list as a C++20 OpenGL 4.5 wrapper. OvWindowing handles inputs and windows via GLFW. OvUI is a widget-based UI layer built on ImGui. OvCore holds the component-based scene system, scripting and resource management.

The README is explicit about intent here: these libraries are designed with reusability in mind, highly modular and easy to extract from a game engine context. That is a real design claim, not marketing filler, and you can check it against the repository layout, where Sources/ contains the module tree. If you only want a component system or a maths library, the split means you are not forced to drag the renderer along. The trade-off is that each wrapper adds a translation layer over a third-party library, so debugging a physics or audio problem can mean reading Bullet3 or SoLoud source through Overload's abstraction.

Third-party dependencies are listed plainly: BareGL, GLFW, Assimp for 3D model loading, Bullet3, SoLoud, Tinyxml2 for XML serialization, Sol3 for Lua binding, ImGui, and Premake5 for project generation.

## Installing Overload and Opening a First Project

The README offers two paths. If you want to skip the build, it points at the releases page for pre-built binaries under a heading that reads "In a rush? Get the latest release!". The latest release listed is Overload 1.9, dated 2026-08-25.

If you build from source on Windows with MSVC, the README gives this sequence. It clones the repository, changes into it, generates Visual Studio 2022 project files with gen_proj.bat, and then opens the generated solution.

```powershell
git clone https://github.com/Overload-Technologies/Overload
cd Overload
.\gen_proj.bat vs2022 # generate project files for Visual Studio 2022
.\Overload.sln # Open the solution in Visual Studio
```

The README notes that officially supported actions for gen_proj.bat are vs2022 (the default), gmake, and codelite, and refers to Premake's documentation for the rest. So if vs2022 is not your toolchain, gmake and codelite are the documented alternatives rather than something you invent.

On Linux with Clang, the parallel path generates Makefiles and builds with all available cores. The README adds an important note for this route: the editor requires zenity to be installed.

```bash
git clone https://github.com/Overload-Technologies/Overload
cd Overload
./gen_proj.sh gmake # generate project files for Makefile
make -j$(nproc) # build the project using all available CPU cores
```

Supported actions for gen_proj.sh are gmake (the default) and codelite. Before running anything, the README recommends downloading one of Overload's sample projects from the wiki, which is also where tutorials and the scripting API live. That is the sensible first use: open a sample project in OvEditor rather than starting from an empty scene, because the wiki is the documented source for sample projects and the scripting API, and the README itself does not walk through scene creation.

## Where Overload Is the Wrong Tool

The clearest limitation is platform reach. The README's feature list says "Windows game building", and the platform badge points at Windows. The build instructions cover Windows with MSVC and Linux with Clang, but nothing in the README describes exporting a Linux game binary, a macOS build or a console target. If your release plan includes consoles or macOS, this engine does not document a route for you, and you should treat that as a blocker rather than a gap to be filled later.

A second constraint is the editor's Linux dependency on zenity. That is a small thing, but it is stated as a requirement in the README, so a headless build server will need it if you intend to run the editor there.

The third issue is documentation depth. The README points to the wiki for sample projects, tutorials and the scripting API, and it does not document the Lua API inline. The repository also carries a CONTRIBUTING.md on the develop branch and a CODE_OF_CONDUCT.md, but the README does not describe a stability policy, a deprecation process or a versioning scheme beyond the release tags. Anyone planning a long production cycle should read the wiki's scripting API pages themselves rather than assume the surface is frozen. The release cadence visible in the repository is uneven: 1.7 in November 2025, 1.8 in January 2026, then 1.9 in August 2026. That is not a criticism of the maintainers, but it is the actual rhythm you would be planning around.

## Overload Compared With Godot and Defold

The natural alternative for a Lua-scripted, open-source engine is Defold, which uses Lua as its scripting language and ships an editor. The difference in approach is architectural. Defold is built around a component and message-passing model with its own build pipeline, and it targets a wide set of platforms including mobile and web. Overload instead exposes a C++20 SDK of nine libraries with an OpenGL 4.5 rendering backend and a Bullet3 physics layer, and its README documents Windows game building. If you want to read or modify the engine's internals in modern C++ and you are targeting Windows, Overload's module split is the more approachable codebase. If you need mobile or web export, Defold is the one that documents those targets.

Godot is the other comparison worth making, though it is a much larger project with its own scripting languages. The relevant difference is that Overload keeps Lua as the gameplay language and C++20 as the engine language, with Sol3 as the binding layer. Godot's C++ extension model is different in kind. Neither is better in the abstract. Overload's README claims ease of use inspired by commercial engines, and whether that holds depends on how much of the workflow lives in the wiki rather than the README, which is where the tutorials and scripting API are.

## Licence and Maintenance Cost

Overload is MIT licensed, and the repository includes a LICENSE file at the top level alongside VERSION.txt, premake5.lua, gen_proj.bat and gen_proj.sh. MIT is permissive, which generally means you can ship a game built with the engine without publishing your own source. That is the practical implication for a commercial project, and it is worth confirming against the LICENSE file itself rather than this summary, since licence text governs and this article does not give legal advice.

The maintenance question is separate from the licence. The repository is not archived, and the last push was on 2026-09-20, which is eight days before this article. So the project is being pushed to. That does not tell you how the Lua scripting API changes between releases, and the README does not document a deprecation or migration policy. The upgrade cost you should budget for is re-reading the wiki's scripting API pages at each release and re-testing your Lua scripts, because the README gives no compatibility guarantee between 1.7, 1.8 and 1.9.

The build side has its own recurring cost. Premake5 generates project files from premake5.lua, so a new toolchain or a new Visual Studio version means regenerating with gen_proj.bat or gen_proj.sh and checking that your supported action is still listed. The README names vs2022, gmake and codelite for Windows, and gmake and codelite for Linux.

## Who Should Adopt Overload

Adopt Overload if you are building a Windows game in C++ and want Lua for gameplay logic, and if you are comfortable working from the wiki for the scripting API because the README does not carry it. The nine-library SDK split, the Premake build and the OvGame/OvEditor separation are all documented, so the path from clone to running editor is short: generate project files, build, open a sample project.

Do not adopt it if your target list includes consoles, macOS or mobile, because the README documents Windows game building and nothing else in that direction. Do not adopt it if you need a written API stability guarantee before committing a production schedule, because the README does not provide one.

Before you commit, verify three things yourself. Open the wiki and read the scripting API pages for the release you plan to use, since that is where the Lua surface is documented. Check the releases page for the pre-built binary that matches your platform so you can evaluate the editor before building. And confirm the zenity requirement on your Linux machines if you intend to run OvEditor there, since the README states the editor requires it.

## Conclusion

Overload fits a Windows-focused C++ team that wants Lua gameplay scripting and is willing to treat the wiki as the real documentation. It does not fit anyone who needs console, macOS or mobile export, because the README documents Windows game building only. Before adopting it, read the wiki's scripting API pages for the release you intend to use, check the releases page for a pre-built binary, and on Linux confirm that zenity is installed, since the README states OvEditor requires it.

## FAQ

### What is Overload?

Overload is a free, open-source 3D game engine written in C++ with Lua as its scripting language. It began in 2019 as a graduation project by Benjamin VIRANIN, Max BRUN and Adrien GIVRY and has since become a community-driven initiative.

### Which platforms does Overload build for?

The README's feature list says Windows game building, and the platform badge points at Windows. Build instructions are given for Windows with MSVC and for Linux with Clang, and the README notes that the editor requires zenity on Linux.

### How do I build Overload from source on Windows?

The README gives the sequence: clone the repository, change into it, run gen_proj.bat vs2022 to generate Visual Studio 2022 project files, then open Overload.sln. Officially supported actions for gen_proj.bat are vs2022 (the default), gmake and codelite.

### What third-party libraries does Overload depend on?

The README lists BareGL for OpenGL 4.5 wrapping, GLFW for windowing and inputs, Assimp for 3D model loading, Bullet3 for physics, SoLoud for audio, Tinyxml2 for XML serialization, Sol3 for Lua binding, ImGui for GUI, and Premake5 for project generation.

## Sources

- [License: MIT](https://github.com/Overload-Technologies/Overload/blob/main/LICENSE)
- [Overload-Technologies/Overload on GitHub](https://github.com/Overload-Technologies/Overload)
- [Project website](https://overloadengine.org/)
- [README](https://github.com/Overload-Technologies/Overload/blob/main/README.md)
- [Releases](https://github.com/Overload-Technologies/Overload/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/overload-technologies-overload