     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Stardock's 1. Stardock Central. If you asked anyone who bought Galactic Civilizations during the first week to name the top thing didn't like about it, it probably would have been updating the game via Stardock Central. In our original plan, Galactic Civilizations was to ship in February, followed a month later by our "BonusPak" -- a giant, single file containing new features and fixes for any significant bugs that managed to get by us. A month after that, in late April, we had planned release Stardock Central as a way for us to provide updates to players.
But when we agreed to delay the game until the end of March, that made its release temptingly close to the Stardock Central release. We began contemplating a simultaneous release of Galactic Civilizations and Stardock Central, which would just require moving up the Stardock Central release date by a month. We were tempted by the thought of launching with impressive software updating technology that also included chat and discussion forums. Unfortunately, when the game shipped on March 26, Stardock Central wasn't quite ready. Stardock Central not only had to deal with people downloading the full 500 megabyte game from the Internet, it also had to deal with people who bought the game at retail. It had to recognize what was already installed and update only what was new. It had to handle myriad date/time formats from around the world. And on top of that, we didn't take into consideration how many inexperienced computer users we'd be dealing with. Our Object Desktop customers had been using the beta version of Stardock Central for months with great results. But they are much more experienced computer users than the typical game player. Stardock Central, in short, was too complicated and too error prone upon release and caused us quite a bit of grief. We were able to respond to that by allowing people to download the game as a single big file, and to download the BonusPak as a traditional patch. But the online distribution system was more complex than we would have wanted it. If we had kept the original April 21 release date for Stardock Central, I think it would have been hailed as incredibly cool, and would have demonstrated how serious we are to releasing lots of meaningful updates to our game. Eventually we think it will be viewed that way, as it has already evolved considerably. But in hindsight, I wish we had waited to release Stardock Central. By the time people read this, Stardock Central should be fine. But that first week was, unfortunately, painful for quite a few people trying to download our updates. 2. The ship angles. During development, we debated whether to have the game objects be displayed at an angle, or from a top-down vantage point. We ultimately went with a top-down vantage point, but one side effect of that decision was that all of the ships in Galactic Civilizations, which were modeled as 3D objects, effectively became 2D objects. In retrospect, we should have had used an angled point of view in the game, so the beauty of the ships would have been more apparent. When you play Galactic Civilizations and see flat-looking ships, you'll know the irony that every single one of those ships is fully rendered in three dimensions. This was my decision and I wish I could take it back now. 3. No integrated technology tree. I actually vetoed this feature. Our development team wanted a hyperlink system for looking at all of the technologies in the game. But as a long time Civilization player, it always bugged me that in these games you could magically know how to get to a certain technology, so I axed this request during development.
I was wrong. I still don't like that feature, but it should be up to the individual player whether to view the technology tree or play it blindly. I won't use the feature, but I shouldn't try to prevent others from doing it if they want. So we'll be adding this feature into an update now. 4. Lack of team discipline. As a project manager, I tend to be hands-off. But early on in the development of the game, that approach nearly proved disastrous. Games need a single vision that is precisely executed. On our non-game projects like Object Desktop, I tend to just guide the development teams towards a general goal and let them go and add things they think are necessary. But in a game, that can be a real detriment. Early on, we had features sneak into builds that were buggy or wrecked the game balance. For instance, a user on our forum would suggest a feature and one of our developers would throw that feature in without telling anyone on our team, and consequently no one else would know to test that feature - including QA. Fortunately we had an open beta and we quickly learned the error of our ways. But quite a bit of energy early on was spent killing features or fixing bugs in unplanned features. So we switched to a much more disciplined system. This is one of the toughest things deal with on a game project. You want your developers to feel like they can add in features on their own without having to get them all approved, but you also want to make sure they don't throw in something that wrecks the game. Often times someone would put in a little update and it would nearly get out the door without some nasty side effect getting caught. 5. The user manual. The final version of the Galactic Civilizations manual isn't terrible, but it isn't what we had hoped for. This the fault of anyone in particular - in fact, ultimately it's my fault. We planned to contract out the user manual to a third party, but we never seemed to get off the ground with that project. I had written an outline of the manual some months before the game was to be released. In early December, Strategy First informed us that the manual needed to be finished within two weeks. At the time, the release date was scheduled for the end of February, so I hadn't expected such an early date on the manual. I figured either a contractor or I would write it during December and January. So instead of having two months to really flesh it out, it was written in two weeks. As a result, it's far less detailed than I would have liked. When the game was delayed until March, I was surprised to discover that the manual, as late as early February, had not yet gone to manufacturing. This was just a series of miscommunications between us and our publisher. Our publisher didn't realize that we wanted more time to work on the manual. The manual provides a decent overview of the game, but I wanted to put in more details about how economics, influence, morale, and industry factor into the game so that users could see the relationship between them. The correct way to do the user manual would have been to early on hand it off to someone who is not coding on the game. Find someone who is really into this type of game. After the game went gold, I sent the game on to friends I know in the game industry and it became pretty apparent based on their questions that we had missed the boat on a lot of really basic concepts. For our future games, we'll try to get someone who is very… intense to be part of the documentation from early on so that when we're done, we have a really thorough user manual. If we had done that, then we would had something strong right away and not felt like we had to rush to put something together.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|