Landing the Plane
From a theoretical standpoint, finishing a game is pretty straightforward. The typical practice is that you make a schedule with a chunk of time after everything is done and during this time you plan that nobody on the team has anything assigned to them to build. You then use that block of time to have everyone play their game, find and fix bugs, and polish everything as much as you can. In practice, you almost never get that perfect chunk of time with nothing to do but test and polish. In fact, you can usually tell when the scheduled period of “nothing” has begun because it’s usually the day when you glance at your inbox and see something like this:
C Prompt’s Approach
Feedback from the demo players is the latest round of feed but not the first. We make fairly extensive use of external playtesters and have had people playing and giving us feed all through the development of Millennia. C Prompt is rooted in iterative development approaches. In our experience, the best way to make games is to build the minimum needed to get a skeleton of your idea shambling around, then start the loop of playtest -> feedback -> changes -> playtest. That means we play our games a lot, from very early stages (the earliest testing of Millennia was more or less a green plane filled with red or white cubes labeled things like “GRAPES” and “HOPLITE”). There are a lot of advantages that come from this approach, but it also introduces a few challenges. For example, the act of looking at and changing a game daily alters your perspective of it. After 1000 hours, it takes considerable effort to see your game with the same perspective you had when you started or from the point of view of a new player. In the same way, teams can develop a shared perspective on things over a period of time, playing and iterating on the game together. We have always enjoyed being pretty close with players and found it useful for keeping our perspective on our work. Things have certainly changed over the years, but this is something that has always felt like The Way to us. Back on Age of Kings, at a time when you couldn’t put up a build for people to download, we were burning CDs of the game and freaking mailing them to our beta players. You find some good things that should have been obvious to you by doing this (in early external tests, we found a bug with building Improvements that was immediately obvious to players but had been invisible to us because we all happened to place our Improvements in the same manner) and you get different feedback than what comes out of internal playtest. Once the game has become public and more people have been able to play through something like the demo or a larger open beta, the amount of feedback you get increases and conversations between players, which are also valuable to development. Part of our plan for the block of time before release is designed with this in mind – we know early players are going to find things we want to polish or fix, so we plan for that when we lay out our schedules.From then to Now
So, with the above in mind, with the idea that C Prompt’s focus is now on getting things tied off for a good initial release and that some of our tasks are being informed by beta and demo players, I thought what I would do is grab all of the change notes on our internal system from the point where we made the demo build up to the point where I started writing this. That looks like this: