The Seventh Month of a Three Month Project

In January, I said I had created a plan. This plan was to release a minimum viable product (MVP) and get it in the hands of at least one customer in at most 90 days.

My thinking behind this plan was that I should be able to put together a fairly complete game easily in that time, get it in front of paying customers, and get useful data about the market to help me decide what to do in the next three months. Maybe I would flesh out the game more, adding features and enhancements based on customer feedback. Maybe I would switch to a different project entirely if no one cared about this one. When I get real customer data from my 90 day project, I would interpret the data and make an informed decision then.

My project is now past its 180th day. Oof.

What happened?

Pride, partly, and the lack of a relatively satisfying game experience. I didn’t want to release a broken, ugly piece of software, and when my original deadline was arriving, I decided I couldn’t release it in the state it was in.

MVPs are meant to be fairly complete products. They might be missing key features, such as copy and paste in a smart phone, or might have some clunkiness, but they are meant to be something you can hand to a customer so you can get feedback from them. You can ask for feedback about different aspects of the game, but real customer behavior requires real customers, not just people who claim they would pay for something when asked in a survey.

So what was wrong with what I was making? I wasn’t worried about a lack of animations or polish. I was worried about a lack of satisfying game play. Various features were in the game, but they weren’t working together very well.

My plan did not initially accommodate the need for time spent on balancing the game mechanics and economy, and while I knew I would always playtest and tweak, I didn’t realize how far off the mark the initial implementation would be. My game didn’t just feel out of balance. It felt broken. I couldn’t release it in that state.

I’ve been in this situation before. My first major commercial game Stop That Hero! was originally supposed to be a one month project that I woefully underestimated. I worked on it for well over a year before my indie game development business ran out of money. I kept slipping my self-imposed deadlines constantly, and I just kept working harder to try to bring the game to a finish line that kept getting further and further away.

There are other similarities between STH! and my current project. STH! was a Ludum Dare game originally that I decided to flesh out into a full commercial project after getting some good feedback, and my current project started out as a physics-based One Game a Month project with similarly good feedback. Both projects were being built using my own code instead of leveraging an existing engine (eventually Daniel Cook will hug me, and I will check it off of my indie game development bucket list). And in both cases, I worked on them mostly solo.

But there are some differences.

STH! was built when I was running my indie game development business full-time. I spent more time in one day working on that game than I do sometimes in one week for my current project now that I have a day job, am married, and have other responsibilities. Looking at my numbers, I think I could have built my current project in its current state within a few weeks of full-time effort, and I would probably have plenty of time to play other games as well.

But STH! was primarily about feature development, especially since I opted to start from scratch, and it was a long time before I got to the point where I could even play the game, let alone figure out if I need to change anything about it as a result of playtests.

For my current project, I developed a few simple prototypes early on. I created a quick text-based version of the game that took me moments to put together, and I spent a few days tweaking and changing it. I had a few systems that I was able to test out quickly and determine if the concept would work.

And I focused on getting something playable quickly ever since. For many months, I’ve been able to play the game, show it to people, and get feedback, although I haven’t had any serious playtesting sessions.

While STH! was delayed due to missing key functionality for a long time, this game is delayed due to what might be called “informed feature creep”. I say informed because I am not just adding features when I think of them but only after recognizing that they would make the basic game more complete.

But it does have the effect of changing what is considered “minimum” for my minimum viable product. Focusing on the need to ship helps me decide if a new idea is a must-have or not.

While my initial project plan was a good first effort, I clearly missed the target.

But it was more out of underestimating what had to be done than in underestimating what I knew had to be done. Everything I scheduled time for more or less got done when I said it would, but playing the game showed me gaps and problems that needed to be addressed with work I didn’t anticipate at the start.

And that’s to be expected. You should learn about your project as you work on your project, and there will always be changes to the plan as it hits reality. You should expects lots of changes and tweaks to the design of your game.

I knew game development requires playtests and balancing, but I forgot to address it in my project plan. Whoops.

And that oversight is why I’m in my seventh month of my three month project. That, and the fact that it takes me weeks to do what could probably take me mere days if I was 100% focused on the project.