From a 2D framework to a 3D production tool
Liberation Engine 3D is the custom C++ engine developed by our nine-person team for Lost during SEP5–6. My contributions focused on the scripting architecture and the workflows around it, alongside reflection, asset loading, editor tooling, graphics integration and export. The project extended the engine work from our earlier 2D project into a 3D development environment.
Designing the scripting engine
Designing the scripting engine was the most interesting part of the project for me. I designed the workflow for compiling native C++ gameplay scripts into a DLL and connecting that module to the engine’s ECS and editor. My implementation history includes script compilation and loading, dependency updates, build-time improvements, re-enabling scripting after integration changes, and handling the module during game export. Implementation and integration took place within the wider team codebase.
From C++ files to a loaded module
The script manager scans the project’s script directory for source and header files. The DLL workflow assembles a compiler command from the script sources and configured dependencies, invokes the Windows compilation process and routes compiler messages into the engine log. The engine loads the resulting module and resolves exported functions for script registration, unloading user systems and updating the editor’s ImGui context.
Reloading and exporting gameplay code
The module supports an explicit reload path that unloads the existing DLL, recompiles scripts and loads the result. Separate editor and game compilation configurations support authoring and export. The resulting workflow lets gameplay code live in a project module while using the engine’s shared systems and interfaces. My contribution log records both DLL build-time optimization and fixes to game export.
Reflection across editor and persistence
I developed the reflection-inspired metadata layer used to expose class names and members. Macros provide tuples of member references, name arrays and a templated Apply operation. Shared traversal and type registries connect those definitions to inspector editing and serialization, continuing the reusable-metadata approach from Liberation Engine 2D.
Asset preparation for a 3D pipeline
My asset work includes loading models, restructuring asset management, integrating materials and implementing DDS texture compilation and loading. The editor exposes texture compilation operations for linear and gamma workflows, while resource-browser work supports asset previews and fixes to browsing performance. These changes connect source assets to the engine’s runtime resource pipeline.
Rendering and engine integration
I contributed graphics-pipeline restructuring and integration across renderers, materials, framebuffers, animation and application setup. The log also records lighting and shadow integration, shadow-buffer preallocation, normal fixes and collider visualization. These are contributions to the team’s renderer and engine, alongside the scripting and tooling work that forms my main project story.
The part I found most interesting
The scripting engine brought several interests together: native C++, module boundaries, explicit interfaces, build tooling and editor integration. Designing the workflow meant thinking beyond executing a script: the engine also needed to compile it, report diagnostics, register its types and systems, reload the module and prepare it for a standalone game.