Being active in a few forums, I read about how long some people spend working on their apps before releasing them. Some solo developers spend 6 months, 1 year or longer working on one app. Tweaking one aspect of the game or another until they feel it is perfect and a certain hit.
This sort of thinking reminds me of the old methodologies that were used a few years back in software development. The methodologies that were brought over from manufacturing.
In said methodology you gather the requirements from your head, from whatever you perceive is missing from the market or whatever great idea you came up with. Then you spend days and years locked up building something that nobody wants, needs or finds any use for.
In manufacturing, it makes sense because the cost to get suppliers in line, building a plant, tooling and other aspects I don’t know about are astronomical. As a solo-developer of games and apps, it doesn’t make any sense because there are fees that are re-occurring and the longer you wait the more of those fees you will have to pay. There are also little or no costs to change the game or app in mid-flight.
A few years back I thought of this great idea. What if I could make a game like 1024 but instead of joining numbers to make bigger number what if I join colors to make other colors. So instead of 4 + 4 = 8 how about blue + blue = Green.
Although I planed may aspect of the game ahead of time, I only implemented the bare minimal to get into the marketplace. From the end of planning to the release of the game took me a total of 3 months. I then spent some advertising dollars until I had enough data on how people were playing the game and how the key metrics compared to my successful game.
I realize that most people didn’t get it and even when they figured out how to play the game it was extremely difficult for most people. Apparently, I made the miss-calculation that people are more comfortable with colors than they would be with numbers. The game has other problems, but the core concept is flawed. I could have spent a year or more as a solo-developer tweaking every aspect of the game and then realize that it was not a viable game. I am stubborn and still have plans for that failed game.
This is my process: I create a list of task or features and then I prioritize them by descending order of required for release. So in my list, a feature like “help screens for gameplay” is a lot higher than “help screens for menu scenes”. After I have the list I draw a line on the list of where in this early stage I consider minimal features for release. I then decide on a release date usually 3 months to 2 months for a new game and 1 month for an update to a game.
I then work on the items on the list. Two things usually happen. The happy path is where I get to the line before the deadline. In that case, I release the game early. The not so happy path is where it is getting close to the release and I am not near the line. In those cases, I go through the items that are left and decide if I can live without them for the release. Remember the most import release features should be at the very top. At a minimal a play button, the gameplay scene with a few levels, setting up ids, onboarding process, and other key features/tasks.
I then release it and wait for feedback or observe data from the analytics package. Based on the information I get I add items to the feature/task list. Re-order them for the next release (usually in a month), draw a line on min feature for release and start working on the task until I reach the line or times up.
Some indy studios do this repeatedly. They create a game, limited release, check the data coming back and then either abandon it or make tweaks and release it to a bigger population.
