It’s finally time. After 600 days of work, mistakes, breakthroughs, and late nights, I can finally share the first trailer for my game.

When I started this project, I had no idea just how difficult it would be. I’ve made every mistake you can imagine, and probably a few new ones too. But in that same time, I’ve also seen something incredible: AI has gone from being a simple helper to becoming a real creative partner in this journey.

Some days, things come together so easily it feels like the game already exists and I’m just uncovering it piece by piece. Other days, nothing works, and even the simplest chain of events collapses into chaos. But no matter how messy it gets, I keep pushing forward, because this game means a lot to me.

I’m balancing this work alongside a full-time job and a master’s degree, so yes, it has been a true labor of love. And when this game launches, it will be completely free. This is something I’ve wanted to do for years, and checking it off my bucket list feels amazing. After that, I’ll roll straight into the sequel, which will have some monetization, but in a way that feels fair and respectful compared to what we’re all used to seeing in mobile games.

The vision has always been clear in my head: I wanted to make the kind of game I’d play while waiting for the bus. Something quick, engaging, and fun when you only have ten or fifteen minutes and nothing but your phone.

That’s what I’ve been chasing for 600 days. And now I finally get to start showing it to you. Thank you for following along and supporting me. I can’t wait to share what comes next.

I’m finally getting the hang of things—my code is starting to behave consistently, and the systems I’ve built are proving to be really flexible. I’ve spent so much time just trying to make things work that I rarely had the chance to focus on actual game design. But now that I’ve got a functional framework for abilities and spellcasting, I can finally shift my focus to the part I love most: designing the game itself.

Things are finally coming together now that the codebase is more organized and everything follows a consistent set of rules. The real challenge has been defining the overall paradigm: each team (Hero vs. Enemy) takes a “Turn,” each Turn is broken into Phases, and each Phase contains a queue of Sequences that must execute in order before advancing. I ended up spending a lot of time refactoring everything to follow this new Turn-Phase-Sequence structure, but it’s already making the system feel much more predictable and scalable.

It’s been a challenge to keep this project moving forward with everything going on in my personal life—family sickness, a recent injury, and some pretty intense hours at work. But despite all that, I’ve still managed to add or fix at least one feature every few days (haha). As I film this video and look at the game from an outsider’s perspective, I’m realizing that the gameplay feels too slow and the stats are a bit bloated. It needs to be more visceral and impactful, so that’s what I’ll be targeting in the next update.

I spent two full days creating a virtual keyboard to ensure the game is compatible with any device, regardless of hardware. I’ve seen so many games on Steam marked “Playable on Steam Deck” with a yellow exclamation point, often just because they require a keyboard for something simple like entering a name or a save file. So, I figured it was worth building one from scratch.

I’m pretty proud of it. It instantiates itself independently and destroys itself once the input is submitted.

It’s not glamorous, but a video game requires a lot of behind-the-scenes work. I spent the last few days wiring up menus and developing a save game system based on serializing and deserializing JSON files—it’s not complex, but I realized that if not done carefully, this is exactly the kind of thing that can result in game saves becoming corrupted. There needs to be validation before, during, and after saving, along with a disaster recovery mechanism to guarantee the validity of a save file. Now I have a splash screen, title screen, settings screen, load game screen, and credits screen. It’s starting to feel like an actual product!

Today wasn’t exactly a thrill ride, but I did wrestle with one of the more underappreciated beasts of game development: scene transitions. The challenge wasn’t just making them look smooth; it was ensuring that saved game profiles and database entries persist correctly between scenes without dragging the entire game’s dataset and graphical assets into memory all at once. Nobody wants their game to hog resources like a dragon guarding its hoard; efficiency is everything!

To tackle this, I leaned on static classes, but I might need to bring in Singletons if things start getting unwieldy. The real headache, though, was ensuring that no collections were being queried before they actually existed. Turns out, when the game boots up, players might take a scenic route. Hopping from the splash screen to the title screen, maybe checking out settings, loading a save, or even scrolling through the credits before diving in. That means any null reference lurking in the shadows can cause a crash before the real adventure even begins.

It’s the kind of problem that’s invisible when everything works, but painfully obvious when it doesn’t.

Trying to get all the swaps and overlaps to work perfectly was incredibly difficult. In the beginning, swapping simply meant an instantaneous flip-flop of two actors’ positions, which was easy but felt cold and sterile. Introducing sliding made the game livelier, but it also brought a host of issues that needed to be handled on a case-by-case basis. For example, if your hero moves so quickly that two enemies are set to share one location, the code must recognize this situation and designate a “winner” (the sliding enemy closest to the destination tile). The “loser” then aborts its current path, adopts a new behavior, and upon reaching the overlapped destination, redirects to the winner’s previous location, ensuring that no two actors ever occupy the same tile.

It’s not quite perfect, but compared to where it was I’m happy it’s working as well as it is.

I’m working on implementing portraits. When two heroes surround at least one enemy with no gaps between them, they initiate a pincer attack.

Went on a tangent and spent the day making a splash screen

One feature I’m excited about is character-specific abilities. I think there’s significant strategic value in assembling a team of heroes with distinct roles and skills. For example, I envision a Paladin Tank being able to shield-bash an adjacent opponent, stunning them for the round or reducing their accumulated action points (top bar). Incorporating classic MMO “Holy Trinity” mechanics could make the game particularly engaging.