adriengivry / overload

3D game engine with lua scripting

Releases | Screenshots | Features | Wiki | Contributing

1. What is Overload

1.1. Description

Overload is an alternative game engine, inspired by industry standards, initiated by Benjamin VIRANIN, Max BRUN and Adrien GIVRY. Overload is now a community project, opened to any contribution.

Overload pillars are:

• Simplicity
• Documentation
• High-quality modern C++ code

1.2. Modules

Overload is divided into 12 modules (10 DLLs and 2 executables):

1.2.1. Overload SDK

The Overload SDK is the core of the engine. It is a set of libraries that our applications (OvGame and OvEditor) are using. We designed theses libraries with reusability in mind. They are extremely modular and easy to extract from a game engine context.

• OvAnalytics: Code and hardware profiling
• OvDebug: Logging, assertions
• OvTools: Serialization, ini files, events, time
• OvMaths: Vectors, Matrices, Quaternion, Transform
• OvAudio: Wraps irrKlang
• OvPhysics: Wraps Bullet3
• OvRendering: Rendering engine using OpenGL
• OvWindowing: GLFW + Windows API wrapper
• OvUI: Dear imGui wrapped into an event-based and component-based UI system
• OvCore: Mediator, resource management, scripting, component-based scene system

1.2.2. Overload Applications

• OvGame: Uses OvCore, asset dependent, generic executable for any game built with Overload
• OvEditor: Uses OvCore, expose game development to the end-user (From creation to building)

2. History of Overload

2.1. Context

Initially, Overload was a graduation project. We were 3 (Benjamin VIRANIN, Max BRUN and Adrien GIVRY) working on it for 5 months. We had to create a game engine from scratch, using the fewest libraries possible.

2.2. Goals

Our goals for this project were:

• Understanding how to architect a game engine
• Designing an application thinking of end-users
• Making a game engine as simple as possible
• Producing high-quality modern code
• Creating a game with our engine
• Dealing with a long-term project
• Developping documentation for developers and end-users

2.3. Pre-production

We spent about a month designing our initial architecture. We tried to provide a technical solution with UML diagrams, flowcharts, package diagrams and use-case diagrams. This was a long and tedious work, but it really helped us to start the production with a clear vision of the engine. We defined some coding convention to ensure that all of our work will stay homogeneous during the production. Defining these kinds of rules is crucial to keep a maintainable code during the whole project.

2.4. Production

The production made us realize that we had a naive idea of what a game engine is. During this phase our architecture has evolved. We found that our initial architecture was sometimes too complex, non-optimal. We went back to architecture design multiple times during the project.

3. Features

3.1. Implemented

Here is a non-exhaustive list of Overload main features:

• Game Editor
• Lua scripting
• Physically-based rendering (PBR)
• Custom shaders support
• Windows game building
• Profiling tools (Editor and build)
• Material editor
• 3D sound system
• Rigidbody physics

3.2. To implement

Again, a non-exhaustive list of Overload in-coming features:

• Shadow mapping
• Custom post-processing
• Renderer Hardware Interface (Multiple graphics backend support)
• More input device support (Gamepad)
• Prefab system
• Skeletal animation
• User scripts profiling

4. Details

4.1. Software

• Visual Studio 2022 (previous versions should also be supported)

4.2. Dependencies

• OpenGL with GLEW (Graphics API)
• GLFW (Windowing and inputs)
• Assimp (3D model loader)
• Bullet3 (Physics)
• irrKlang (Audio)
• Tinyxml2 (XML Serializer)
• SOL2 (Lua binder)
• imGui (GUI)

4.3. Requirements

Overload requires:

• RAM: 100MB
• OS: Windows 7
• GPU: Graphics card supporting OpenGL 4.3
• CPU: x64

4.4. Compiling sources

Overload is using Premake5 to generate project files. To generate these project files, execute GenerateProjects.bat located at the root of the repository. By default, GenerateProjects.bat will generate project files for Visual Studio 2022. If you want to use another version of Visual Studio (vs2019, vs2017...) or another IDE (c.f. https://github.com/premake/premake-core/), you can execute GenerateProjects.bat from the command line with an argument. (ex: .\GeneratedProjects.bat vs2019)

Overload only targets Windows x64.

4.5. Licence

Overload is licenced under an MIT licence.

4.6. More information

If you are interested in Overload, you can download our engine and the demo game we made with it on our website:
http://overloadengine.org

Learn about Overload (Tutorials and Scripting API) by visiting our Wiki:
https://github.com/adriengivry/Overload/wiki

You can also watch our features reel (Overload v1.0.0) on YouTube:
https://www.youtube.com/watch?v=ARXSJh-ZMHM

And join our Discord Server:
https://discord.gg/wqe775s

5. Getting started

Learn how to create your own games using Overload by visiting our wiki.

6. Contributing

Overload is opened to any contribution. Do not hesitate to open issues (Features or bugs) or create pull requests.

If you want to help us, visit our CONTRIBUTING.md guidelines document.

7. Screenshots

overload's Issues

Gamepad support

We should be able to handle gamepads in OvWindowing.
After that, we would need to add some binding for Lua in order to use gamepads in our gameplay logic

Check project folder on opening

When we open a project, we are currently not checking that the "Assets" and "Scripts" folders exists. If they don't, it will result in a crash.

We should add security and error message if one of these folders doesn't exist.

Physics dependent of framerate

Currently the physics seems being dependent of the framerate. If you try to jump in a game scene, the jump force will depend on the framerate while it shouldn’t. To reproduce this issue, you can disable vertical synchronization and jump

GameObject icons in Hierarchy

Problem this feature should fix
The hierarchy has a lack of information about GameObjects states (Enabled/Disabled)

Expected solution
We can add some icons to the left of GameObjects tree nodes in the hierarchy that can show if the GameObject is enabled or disabled. Layer, with a future prefab system, we will be able to use this icon system to identify GameObjects that are instances of a prefab.

Example

OvMaths vectorization

Our maths library is currently implemented the old scalar way. It could be great to vectorize our maths library using SIMD intrinsics.

CPU usage isn't critic for now, this feature makes more sense in combination with morphing and skinning algorithms that we could implement in the future.

As we target OpenGL 4.3, which is relatively recent (August 6th 2012), we can use SSE4.1 (2006) and AVX (2011) instruction sets.

In this implementation, we should avoid extending our data structures that are non-multiples of 16 bytes (Ex: Vector2, Vector3, ...). The usage of SIMD shouldn't affect the actual memory usage.

Sample project

Problem this feature should fix
When using Overload for the first time, it is sometimes unclear what you can do with the engine. Morehover, some users want to be instantly able to try the engine (Play with assets, modify scripts/shaders).

Expected solution
We should add a sample project that our users can use to discover the capabilities of the engine. This can be pretty similar to our "Showroom" sample, but with a focus onto user experience (Clean project, size is important)

Adding post-processing support

We should support adding custom post-processing into our scenes.

This will require to improve OvRendering to provide a proper abstraction layer for Framebuffer and RenderTexture

Auto-save

We should add an auto-save option (That can be disabled) for the current scene.

Save editor settings

Currently we have some editors settings. These settings aren't saved through overload sessions. We should automatically save them to a .ini file and recover them on startup.

Add documentation link in the game editor

We should be able to open the engine documentation through the game editor (Like our portfolio links and the scripting API link).

Documentation link : http://overloadengine.org/documentation

Pre-compiled headers support

Overload isn't using any pch system for now.

We should start using pch in our different projects to reduce compilation time.

Move OvDebug::Utils to OvDebug

In OvDebug we currently have 2 namespaces :

• OvDebug::API
• OvDebug::Utils

We shouldn't have this OvDebug::Utils and we should instead have all of this namespace content directly in OvDebug.

Find references to an asset

It would be nice to be able to find a reference to an asset into the current scene. We could add a "Find all references" option on the asset browser file contextual menu and show these references into the hierarchy

Crash diagnostic

It would be nice to print a popup with the call stack even in release to identify bugs quicker. For example this would be very nice with scripting, we would be able to understand why our game is crashing and correct our scripts in consequence.

Example:

Lua script profiling

We should be able to add profiler spies into our Lua code in order to profile it

Remove useless TestWidget in HelpWindow

During the production I found useful to implement some test widgets directly in OvEditor to avoid recompiling OvUI.

A TestWidget class is remaining in the HelpWindow of OvEditor, we should just remove this class. We should also verify that there is no reference to it somewhere in the engine.

Force Overload to use the dedicated GPU

We should force Overload to run on dedicated graphics card to prevent context creation failure due to OpenGL 4.3

Framebuffer wrapping

Currently we use framebuffers directly in OvEditor. We should wrap the framebuffer object into a class in OvRendering and use it in the editor.

Technically, we should have no OpenGL call in the editor, the use of the OpenGL backend should be transparent to the editor.

OvMaths::FQuaternion::Identity() should be a constant instead of a static method

There is no point having a method there. Morehover, it is inconsistent with OvMaths::FVector3 which has some constants (Zero, One...).

Prefab system

In order to be more productive while creating a scene with Overload, we should be able to create templates (prefabs). These are basically an xml serialized version of an actor that we can drag and drop into scenes.

We can start with a very basic system without the possibility to edit tempaltes/prefabs, but later it would be nice to have an editor for these kind of resources.

Undo/Redo system

We should be able to undo and redo editor actions to make Overload less destructive. We can for example store editor commands in classes with a "Do" and "Undo" method to be able to undo any command. These commands can be saved into a stack after they are executed.

Expose frustum culling to lua

We should expose new frustum culling settings to lua:

• Camera frustum culling for geometry
• Camera frustum culling for lights
• ModelRenderer frustum behaviour

Move "Window/Help" to "Help/Controls"

Currently we have a "Help" window that can be enabled via the "Window" menu in the menu bar. We should move this element to the help menu as it makes more sense to find it there.

Change color of a selected actor in hierarchy

Currently a selected actor in hierarchy is represented with this color:

We could use the color of a select tab for a selected actor too:

Frustum culling

A nice optimization would be to have frustum culling. This can be achieved simply by saving a sphere (Bounding sphere) in our models and use this sphere in conjonction with actor transform (Scale and position) to determine if the model is in the camera frustum. Frustum culling should be an option per model renderer. Sometimes (With particle system for instance) we wan't to disable this effect because shaders can actually render an object outside of its base geometry.

Example

Implementation example
https://github.com/gametutorials/tutorials/blob/master/OpenGL/Frustum%20Culling/Frustum.cpp

Default value on deserialization

When we deserialize elements we can't provide a default value if the parameters hasn't been found in the XML. We should be able to provide this default value in all case or to give information to the caller about the deserialiation result

Parallel texture preview loading

In the asset browser, when we open a folder containing some texture, we are freezing the editor while these textures are loaded for preview. We could instead load these textures asynchronously to prevent the editor from freezing and to have a smoother asset browsing.

Duplicate big actors cause crashes

Sometimes when duplicating and deleting some actors that has children the engine crashes.

It still being unclear how to reproduce this bug but you can try this :

• Create an empty scene
• Add an actor
• Add children to this actor
• Duplicate the parent actor
• Delete the duplicated actor
• Duplicate the parent actor again
• etc... till it crashes

QA Testing pass for 1.3

Description
As some major features has been introduced after 1.2, we are almost ready to deploy an 1.3 build. However, we have to enter a QA pass phase to ensure these new features aren't bringing new bugs to Overload

Expected
Tracking bug introduced by each new features from 1.3.

Negative light bounding sphere

Lights using negative intensity are not considered in the light effect radius calculation. We should use the absolute of the light intensity

Delete an actor using [Del] shortcut

It could be nice to have the possibility to delete a selected actor using [Del] key (In both SceneView and Hierarchy)

OvEditor OpenGL version set mistake

Currently, the editor OpenGL version set in OvEditor is incorrect. We are setting the major version 2 times instead of setting the major and the minor version.

See : OvEditor --> Context.cpp

The version that we should be using is 4.3 (Minimum GL version that supports SSBO).

This issue is kind of critical and we should create a new release of Overload for that (1.0.1).

Open .ovproject with Overload

We should be able to open an Overload project (.ovproject) by right clicking on the project file and selecting "Open with... Overload".

In order to make this work, we should support starting the editor with command line arguments (The project path will be given as an argument).

The OvEditor main should read this path and open the project instead of opening the project hub.

Search bar in hierarchy

Having a search bar in the hierarchy could really help to navigate into our scene entities. This could allow searching by name or component type

Show actor in hierarchy on picking

When we pick an actor in a scene, we expect the hierarchy to focus it in order to manipulate it. We should add this behaviour. Scene hierarchy should expend to show the focused actor.

Tip: We can recursively iterate through select actor parent and expend their matching node in the heriarchy

Add project to hub when opened with Overload

When you open a project directly (Open with... Overload) without using the project hub, this project won't be added to projects.ini. We should consider these projects

Remove `FTransform` from OvRendering::LowRenderer::Camera constructor

There is no need to pass this parameter to the camera constructor because the camera doesn't even use it.

Scene view actor picking

Context

We should be able to pick an actor (With a component such as CPhysicalObject or CMeshRenderer) by simply clicking on it.

They are 2 approaches to solve this issue:

Physics based

Creating an editor physical world (Requires to split PhysicsEngine into 2 classes, such as PhysicsEngine and World, as we did with @BenjaminViranin in the first physics implementation) and picking actors with raycasts. We will have to implement a layer system for the physics (Default, Editor, EditorOverlay). We will need to implement a PhysicalMesh system to ensure a good selection UX.

Rendering based

Creating a rendering pass (In a framebuffer) of the scene with unlit colors. Each color can represents a different actor. We can attribute colors depending on actors IDs (Ex: if an actor is rendered with a unlit color of rgb(1, 0, 0) it means that its ID in the scene is 1). This rendering pass is done when a mouse click occurs, and we will have to check the mouse position in the rendered texture, find the color under the selected pixel, and convert it to an actor ID. This solution implies that we wrap the framebuffer into an RAII-style class, like @maxbrundev did for other buffers. As we need to render the scene using unlit shader, and that Overload doesn't supports vertex and fragment shader in separated files, we can't make particle selection works with this approach. We can fix this drawback by supporting vertex and fragment shader in different files, so our rendering pass will keep vertex shaders but replace fragment shaders by unlit ones.

Scene View

Rendering pass with unlit colors

Split light SSBO into multiple SSBOs

We should split light SSBOs into multiple SSBOs to prevent useless shader branching

Note: This change will break any custom shader made with Overload.

Camera Orthographic

Problem this feature should fix
We should be able to setup a camera into orthographic (For 2D) or perspective mode (For 3D).

Expected solution

• Implementing a CreateOrthographic method into OvMaths
• Use it into OvRendering::LowRenderer::Camera
• Expose it into OvCore::ECS::Components::CCamera
• Add a setting to choose between ortho/perspective in OvCore::ECS::Components::CCamera
• Expose this new setting to the end user in Lua

Improving first time user experience

Problem this feature should fix
A new user of Overload, after downloading the latest release, can feel lost.

Expected solution
It could be nice to have some documentation to give our users the best first time experience possible.

Exemple of a guide for Unity beginners (Unofficial) : https://www.raywenderlich.com/unity/paths/learn

Orbit camera

Light 3D icon (billboard)

We should show light as 3D icons in the scene view using a billboard shader.

Here are some examples from Unity:

Use actor bounding sphere for focus distance

We should consider actor bounding spheres to focus them efficiently

Shader graph

Implementing an editor tool that can generate a glsl file using a node based approach.

We should be able to create:

• Input nodes
• Maths functions
• Buffer inputs
• Output nodes
• Conversion nodes
• Variable declarations

We should be able to create the graph using OvUI

Scene view camera jump

Sometimes that camera jumps when moving into the scene view.

The behaviour isn't precisely defined, you can try to reproduce it by moving in the scene view or to spam the right click in this view.

will you consider to support linux later?

do you have a plan to support other platform? such as linux, mac? that would be so cool!

Grid and angle snapping

We should be able to snap translation, rotation and scale while holding the shift key.
Some settings should be added to the editor settings too. (Snap units).

Example (From Unity):

[Bug] Uninitialized variable

Hi,

The diff can be show here

Strangely, this bug causes crash only when using my cmake scripts...

The original sln project does not...

P.S.
Uhm... I wrote a simple cmake script, and is about to make a PR...
But I just found... I've done the same thing... there is already a PR doing the same thing. ;-(
My version of cmake scripts are simpler (more straight forward)... So I decided to give my PR.

So I just tell you the bug I found..

Regards.

BTW. I think you guys would better use a .clang-format file to format the code

UI Rework with ReferenceOrValue

In the editor we encounter this case multiple times:

• Create a widget (Ex: Text)
• As Text inherits from data widget, we can add a DataDispatcher plugin to it
• Register a gatherer and a provider in the DataDispatcher or attach a reference

Another approach is to use events (OnValueChanged += ...) to keep, for example, our components up-to-date on the UI (And vice-versa).

It is very tedious to do that, I thought about a way to instanciate an object that can be a reference to another instance or directly a value (Like with our AudioListener which holds a transform pointer or instanciate its own one, with a m_internalTransform boolean to keep track of the memory management mode).

I added the ReferenceOrValue class that allow a such behaviour:

int toto = 5;
ReferenceOrValue<int> foo{ 1 };
ReferenceOrValue<int> bar{ std::ref(toto) };
bar= 8; // Toto is modified, because bar holds a reference to toto
foo = 3; // Foo value is modified, because it holds no reference

This way, we can create a UI widget (Ex: Text) with its content as a ReferenceOrValue<std::string> instead of std::string which can be a reference to a component value or a simple std::string. (No more need to add a plugin or use events to keep the UI up-to-date on the component value because the UI will directly affect this value).