Hi all,
I read a few comments the other day where people were disappointed that an upcoming feature was coming out later than expected or later than originally estimated.
I sympathize with the frustration, but I want to present some behind-the-scenes observations as to why you may want to be very understanding and forgiving when folks communicate information, even if their timing ends up being off occasionally.
Over the years, I've been lucky enough to work on many games in various capacities. Probably over 100 different games in various formats (online games, card games, board games, miniatures games, RPGs and even a dice game…).
There were many different project managers (or producers) and many different methods of estimating and tracking work, but I've found the following rules to be true:
When you are working on a game release that has the exact same work each time, you can reliably predict a launch date of that release, within some minor variance.
When you are working on a game release or feature that has a new set of development variables or completely new tech, the ability to accurately predict a launch date is decreased.
Some examples:
If you’re working on a new card set for Magic: The Gathering or Vs. System or Pokemon, you know it will take exactly 18 months from start of initial concept to launch of the finished, localized product worldwide.
If you’re working on a new hero for Marvel Heroes, you know it will take exactly 4 months from start of “paper design” to launch of the hero. You can schedule around that pretty reliably and hit the date within a couple of weeks.
Some other things to consider about predicting launch dates:
In my experience, the number of moving parts in a system directly affects the release date. Seems simple, right?
One way I internally estimate a release date is by looking at a design doc that is referenced for the feature. We generally use a database or spreadsheet with every element of the design listed out. I look at the number of individual moving parts in the doc.
Looking at the achievement system design doc, there are about 10 elements to each achievement, multiplied by about 600 achievements that need to be built (in a nested achievement, each step in the nest has to be built individually).
So that’s 6000 fields of the design doc that need to be processed. (Much more than any other feature we’ve ever done.)
Processing of each achievement includes the following steps:
- Designing the achievement and designing each component of it
- Having at least one peer-review pass
- Iterating based on peer comments, if needed
- Having a designer implement that achievement using the custom achievement interface that was built. This could take one hour for a simple achievement to a couple of days for the most complex ones.
- Marking each field and implemented and ready to be tested by QA
- Have QA execute their review pass and verify each field
- Have the designer make changes or fixes based on QA comments, if needed.
- Have QA go back and verify to make sure that changes were successfully made and no new problems were created. (Repeat if needed)
- Get the latest updates on the alpha test server for review.
- Solicit feedback from the alpha testers for every achievement.
- Alpha test feedback, in some cases, will require this process to be restarted if an achievement is modified or redesigned based on feedback, to make it more fun or fix some kind of issue
- Once all of that is done, you’re then ready for public testing, which will likely re-engage the design process on some percentage of achievements based on feedback.
Some of the time, an achievement sails through and the total work isn't too much and sometimes iteration and improving quality means a week of total manpower just for one of the fancier achievements.
This whole process doesn't even include the work to actually have engineers build the back-end achievement tech, determine the most performant method of setting up everything, creating the design tools needed to implement each achievement (a critical part of the process) and support the feature throughout the design process by adding new tech. (“Oh, you guys want to have some timed achievements? We’ll build that for you. You want to be able to check to see what gear a person is wearing for a specific achievement? You got it!”)
So, the number of moving parts of a system is what I generally use to estimate a release date. I also tend to factor in a reasonable number of rounds of testing and iteration for brand new systems. This means if you ask me when a new system is being released, I will generally give the furthest release dates out of anyone, and even then I will probably be too optimistic by some amount.
That’s some background on why things take a long time.
(continued...)