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:
But, even though the scheduled chunk of nothing-assigned polish time is often filled with unexpected chaos, there are different flavors of chaos. I don’t want to curse us – we are not done yet – but Millennia has thus far (happily) enjoyed the mild variety in this phase leading up to release.
Compared to earlier phases of development, life for the team is more focused. We know what is going to be in the launch version of the game and we know when it will need to be done, so perspective shifts from more open-ended discussion about new systems or features to increased attention to completion. In the earlier stages, we spent more time in “hey, I had this idea” conversations and those often ended up with someone putting something in the game later that day. Now, those ideas go into our backlog for later so we can remain focused on tying things off.
While it’s always fun to be in a wide-open creative mode, there’s a lot of enjoyment in the current stage too. There are numerous small issues to address, so if you’re the kind of person that likes crossing things off of your list, you get to do a lot of that. And the list dominates too – unlike early stages of development, everyone is now working on specific items on the punchlist.
Another change in this stage is that the game is no longer a secret. Millennia has been shown to players (in this case played by some) and feedback is coming in. Seeing people having fun playing the early builds and the demo of Millennia is really exciting. It is fuel for the team. I think we were the seventh most-played demo at Next Fest and when we started getting notes that began with things like “so, I’ve played 40 hours of the demo and here’s what I think”, we were all happy.
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:
That’s maybe a little difficult to read. :)
I went through those and did my best to make most of what is in there make some kind of sense to someone not on the team. (I also made some notes in there on any of the changes I remembered being called out by beta or demo players, just because people have said they like knowing about those things).
