Overview
LDGE is a custom 2D game engine built in C++ with SDL3 and Lua 5.4. The goal was to create a small, understandable engine that supported fast gameplay iteration through native engine systems and scriptable game logic.
The project was completed by a 4-person team over roughly 3 months. I served as the technical lead, software architect, and product owner, with primary ownership over the entity runtime model, main game loop, Lua scripting integration, and rendering pipeline.
My Contributions
I designed and implemented the engine's entity runtime model around a simple ECS-style architecture. Each entity is represented by a unique ID, which provides a lightweight way for engine systems and scripts to reference objects without adding unnecessary complexity. This made it easier to connect gameplay logic, rendering, input, and script-side behavior through a consistent runtime model.
A major part of my work was integrating Lua with the C++ engine. I built the scripting interface, exposed entity data and engine functions to Lua, and implemented the script lifecycle for initialization, per-frame updates, and event-driven behavior. This gave programmers a faster iteration path for gameplay code while keeping performance-critical systems in C++.
I also implemented the core rendering path using SDL3's 2D rendering tools. This included connecting sprite data to entities, integrating rendering with the component model, and keeping the system simple enough for the rest of the team to understand and extend.
Beyond individual systems, I was responsible for the broader engine architecture. I scoped features, defined system boundaries, made major technical decisions, and helped the team break the project into manageable pieces so we could complete a functional custom engine within the project timeline.
Lessons Learned
LDGE was my first game engine project, and the hardest part by far was the beginning. We were working on a tight timeline, and I had less than a month to teach myself as much as I could about engine architecture, then break that knowledge down into pieces my team could actually build from. That trial by fire taught me a lot. I gained a much deeper appreciation for lower-level game systems: how games manage objects, when and how data gets loaded into memory, what kind of custom tooling teams build to make development smoother, how spatial audio fits into an engine, and even the small rendering tricks used to squeeze out a few more FPS. That process gave me a broader foundation as a game programmer and made me more interested in the engine work behind the games themselves.
It also taught me how important technical leadership is on a small team. I had to make architecture decisions, explain tradeoffs clearly, and research unfamiliar problems quickly when the team needed direction. The project reinforced that gaps in knowledge are normal, but leaving them unaddressed slows the whole team down.