What the fortune-teller didn’t warn us about.
In Russian, there is a proverb: “The ship will sail as you name it.” When we chose the logo and slogan for the team, we joked. “To invent a bicycle” – is a Russian analogue of “reinvent the wheel”. So, it was a joke about most of the guys like us, about ourselves, about the mistakes, which, as we thought, were made and understood.
But it seems that fate keeps sending us “bicycles” again and again. The most recent “bicycle” has shown us that we are not quite right approached the problem of task-tracking.
It is believed that 80% of the result is achieved during the first 20% of the time spent. If we take as a starting point the day when we stopped using Lightfeather and began working with OGRE (in fact, it was a moment when we have finished studying the problem and began active work), we can quite accurately say that it took us 170 days of active work to get the first playable beta, which was shown to the community.
After that, we still had a lot of fixes and polishing, but we can take the first beta version for 80% of the result.
Following the “principle of 20 and 80 ‘, the overall development time could have been determined even then. It should be 850 days, starting with the selected reference point, and we should have planned to release the game in mid-June 2012. However, at that moment we didn’t took this principle into account. We have estimated the time on the basis of already completed tasks, and hoped to release the game until the end of 2011.
Unfortunately, most of these tasks quickly split into several tasks of equal complexity. Some minor issues “pulled in” larger tasks. Simple improvements suddenly have required significant changes in the already written code.
On the 5th of May, we released version 0.7. In this version the game code has been rewritten almost entirely to make it possible to add a new game mode (shisen-se) and the possibility to save/load a game.
After 3 months we have released version 0.8, in which a substantial part of the code had to be rewritten again (despite a small development time and a modest list of changes). At this time we did it to support dynamic loading of localized text (which, however, was fully implemented only in the next version).
After the release of version 0.8, we began to understand what is actually the amount of work we still have to complete before we can say, “now the game looks just as we had planned it, it’s time to move on to the next project.” Then it became obvious that we can not do all this before the New Year. There were three solutions:
increase the amount of time given to the project (in an average week I spend 8-12 hours of my time to this project, and Michael dedicates this project the equal amount of time);
significantly shift the time of release;
significantly reduce the quality to finish at the appointed time.
Any of these paths is suitable for the open-source project that isn’t trying to claim something more than it is. We have chosen a compromise between 1 and 2. To avoid large gaps between versions, we released 0.9 in late January. We called it the first release candidate, and it really has almost all the functionality that we would like to see in the final version of the game.
According to our current estimates, we will end up with “polishing” the game in early summer. And the same date, we could have gotten with a simple arithmetic operation, more than a year ago.
Of course, we could pre-empt all planned functionality in architecture, and solve all problems “in general” to eventually get something like “Lego”, which allows for a few hours to implement almost any feature. Unfortunately, this requires a completely different experience levels. I as the designer had no such experience (despite a few years of working in a team where everything was done that way). Michael as programmer did not have it either. However, the creation of such an instrument would require a huge amount of time, so the project could have died from the syndrome of “lack of visible results,” long before the first playable beta.