03
2026The Inception of LoL Engine
Inception
LoL Engine did not start as a product. It started as a way to avoid rebuilding the same game systems over and over again.
But the seed was planted much earlier.
Curse of the Manticore
In college, I made my first game in C++ and Visual Basic. It was called Curse of the Manticore.
It was not graphical in the way people usually think of games. It was a Windows application with copious amounts of text on the screen, buttons for choices, and a branching story underneath. You played as a Samurai stuck on an unknown island battling the monster inhabitants as you tried to get back home via a portal in the Manticores lair. The Manticore final battle was a battle where the Manticore had 3 forms before it could be finally vanquished, each with their own attack types.
The structure was closer to a choose your own adventure book. The player would read a scene, choose one of the options, and move to another part of the story. Sometimes the next step depended on a virtual dice roll. Battles were also resolved through randomized dice, and bad choices or bad rolls could end the game, no saves no reloading!
Built before internet was common, the game came together the old way; hours spent in college libraries and computer labs, learning from whatever books, machines, and time I could get access to.
Unfortunately, the handwritten designs and source code was lost. The source only existed on 3.5 inch floppy disks with backups on other 3.5 inch floppy disks, and those did not survive the years.
What did survive was the idea that I wanted to make games.
Years of Ideas
For a long time, I had game ideas that I wanted to play myself.
Some were too large. Some were too vague. Some were waiting for the right time. Some were just plain impractical. Life and work kept getting in the way, as they do.
After Covid, I finally decided to stop only dreaming about it and start building again. I began working with Unity and made several prototypes as I got more of an understanding of how modern games are made.
All of them were bad.
For someone whose professional background was in mainframe programs and Pro*C, stepping into Unity game development with C# was a real shift in language, tools, and mindset.
That is not false modesty. They were useful prototypes, but they were not good games. They were scrapped because I did not yet have the experience, discipline, or maturity to build the games I had in my head.
That period taught me something important: making games is hard in a very specific way.
You are not just a programmer. You are also a level designer, sound designer, music director, artist, UI designer, writer, tester, producer, and technical support. Even a small game asks for many different skills at once.
The Lazy Programmer
While making and scrapping prototypes, I started noticing the same patterns.
Every project needed some version of
- Audio playback
- Save and load
- Events
- Object pooling
- Resource loading
- Localization
- Logging
- Time control
- Game state handling
- Notifications
- Randomization
- Configuration
- Startup order
The game ideas were different, but the infrastructure kept coming back. That is where my professional brain took over.
At work, I spend a lot of time thinking about systems, data, repeatable work, and automation. A good lazy programmer instinct is not about avoiding work. It is about refusing to do repetitive work manually forever.
If I was going to keep prototyping games, I needed to stop rebuilding the same foundation each time. So I decided to make a library with commonly used functionality for myself.
Personal Library to LoL Engine
At first the library was just meant to help me move faster. If a prototype failed, I did not want to lose the save system, audio system or setup code with it. I wanted those pieces to survive the prototype and follow me into the next attempt.
One thing led to another.
The library went through multiple iterations, rewrites, removals, and hard lessons. Some systems were too game-specific and had to be deleted. Some APIs were too loose and had to be tightened. Some features worked in the editor but needed hardening for real builds, clean package imports, and IL2CPP.
Over time, the shape became clearer with each iteration of the library (now called LoL Engine):
LoL Engine should not be a complete game.
It should be the reusable layer underneath one.
Why the name
The name LoL Engine means Labour of Love Engine.
That is exactly what it is!
It came from years of wanting to make games, losing early projects, restarting later, building bad prototypes, learning from them, and slowly turning repeated pain into reusable infrastructure.
The Asset Store version is the final result of that process: a Unity 6 framework with modular services, samples, documentation, tests, and production ready systems.
It exists because I still want to make games I want to play.
And because I know I am not the only person who has restarted a prototype and thought, “I cannot believe I have to build all this again.”
LoL Engine will be available for Unity 6000.0+.
– Asset Store: TBD
– Documentation: TBD