FireAnt | PC/Nintendo Engine

A cross-platform engine demo featuring particle systems, ECS architecture, inspector hierarchies, and GLTF 3D model support.

🎓 About the Project

FireAnt is a cross-platform engine, with Nintendo and PC. It was made to create strategy game in a team of 7 programmers, over 8 weeks. I focused on graphics programming and on the cross-platform API for Nintendo using OpenGL.

🛠️ Skills Developed

Cross-Platform Development: Designed and implemented the rendering layer, ensuring compatibility across Nintendo and PC targets. Contributed to the overall engine architecture with a focus on abstraction and maintainability.
Core Engine Systems: Worked within an ECS architecture using entt and cereal for serialization. I built core gameplay systems, including a particle system and a 2D unit animation system, enabling other developers to easily integrate effects and animated sprites into the game.
Engine Inspector UI: Utilized ImGui to create editor windows for managing game entities, resources, and scene data.
Teamwork: As this was my first “large” collaborative engine project, I contributed to code reviews, helped enforce team coding standards through using Github Actions, and worked to maintain a shared vision across the team. I got the opportunity to lead some of our meetings.

🎮 Demo

Isle Be Damned was a strategy game in the style of Bad North.

We also attempted to make a more “traditional” RTS using our engine, similar to StarCraft or Cossacks 3.
We never managed to finish the Terranox demo, mainly because it was very hard to adapt it to our target, the Nintendo Switch, and the time ran out.

Isle Be Damned

Terranox

⚙️ Key Highlights

🎇 Particle System

The particle system was our main tool for adding “juice” and responsiveness to the game.
It supported basic parameters with interpolation: color, velocity, acceleration and scaling.

Scaling Interpolation

Moving Emitter

Acceleration

Hit Particle Effect (on enemy impact)

🎯 Frustum Culling

To optimize rendering, I implemented an early out check using a two-stage culling system (quite simple, but effective for our use case):

This was especially effective for the RTS use case, where the camera looked down.
With 8000 billboarded sprites, frustum culling reduced the render time from ~30ms to 5ms.

Color-coded sphere and frustum culling (Green: visible, Red: outside frustum, Orange: outside sphere)

8000 animated sprites: ~30ms without culling → ~5ms with culling

⛰️ Terrain with Tessellation Shaders

I first tried to implement tessellation while working on the Grand Strategy Renderer, but didn’t manage to finish it due to time constraints.

In this project, I got it working, rendering the same terrain ~4× faster than geomipmapping on the CPU, with better visual quality and lower memory usage.

Technique	Naive	Geomipmapping	Tessellation Shaders
Performance	~17ms	~4ms/frame	~1ms
Memory Usage	High	Lower than naive	Low
Implementation Difficulty	Trivial	Medium	Hardest
Scalability	Poor	Good	Best
Visual Quality	Good	Good (with tuning)	Best
Frustum Culling Support	❌ No	✅ Yes	✅ Yes

Tessellation shaders could be improved further by subdividing geometry based on complexity—
something done in Sebastian Lague’s Geographical Adventures.

🎬 Animation system for billboarded sprites

Our brief required that we have a 3D world with 2D sprites that represent units.
I was in charge of this system and implemented an animation system with events that were used in gameplay by the other programmers.

Animation system controls: flip, speed, loop

Event-based animation system triggering console messages

The videos showcase how I can use the animation system through the UI, and how the event based system triggers, using a console message.

📂 Source Code

Unfortunately, due to NDA restrictions, I am unable to share the codebase.