The Simple Game That Took Me 6 Years to Release
Published • 4 minutes
I wanted to make a simple game that would take 30 seconds to play while you were commuting to work, standing in line, or otherwise bored. I came up with an idea in January 2018 and demoed a fully functional game in September of the same year. I finally released it in April 2024.
Why did it take me this long? What happened?
Let me take you on a journey into my mind. A mind wrought with dreams of unit tests, continuous integration, documentation, separation of concerns, and, my favorite, open source.
I just wanted to make a game. I had just shelved a prototype I had been working on for months because of an issue I could not solve without learning Blender for the umpteenth time. It was an AR game where you could build a golf course from pre-built pieces and then play it.
A few nights later, I was sitting in my living room fiddling with a deck of cards. Then I started tossing them onto my card table to see if I could get them to land face up. I began to see if I could throw a specific number of cards onto the table to make a decent poker hand.
"Huh." I thought, "This could be my next game."
And so it was. Over the next few months, I built a working prototype. I even demoed it at an event before PAX East 2018. This prototype was built to be pretty simple. It worked on a desktop with mouse controls and on mobile with touch controls. Simple enough.
However, once I started building more features, I found some of Unity's built-in functionality lacking. Like most developers I've talked to, I solved this by creating a small library of reusable components and functions.
This is where it all broke down.
I love open source and sharing what I've learned. So, when I started building simple, reusable components and functions in Unity, I wanted to share them. However, sharing them as is wouldn't work; I would need to clean them up, add tests and documentation, and release them publicly on GitHub. My first open source repo was a collection of these reusable components called CandyCoded.
After I made the component library, I realized I would need an AR component library. So, I polished up my custom AR components, wrote a bunch of documentation, and released that as well.
You can see where this is going.
The same thing happened when I built anything reusable, which is why all of these (16) open source projects exist.
I even open sourced my poker logic as a C# only library.
This process took years. And because I found excitement in releasing open source packages, I started to lose interest in the reason I started down this path in the first place.
Within the first year of development, I rekindled my interest in the game after demoing it at a local game showcase called BostonFIG.
Unfortunately, even that didn't motivate me enough to finish and release it.
Another issue that contributed to my not releasing the game earlier was that I wasn't marketing my game. Because of this, I had no outside accountability aside from myself and people I knew personally. This was a massive factor in my not releasing the game earlier.
But in the end, I finally released it. I'm happy I did, and I'm proud of my work.
Will I market it now that it's out? Probably not. It was, first and foremost, a passion project, but it was also a way for me to learn Unity. Maybe I'll market my next game before it comes out in six years.
Am I making a new game? I am! It's a rhythm game like Guitar Hero or Rock Band, and as is tradition, I'm building an open source library first. Because of course I am.
Wait, before you go, I should probably share the link to the game I've been talking about right?
