     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Stardock's Don't put too much faith into official quality control. The QA people at Stardock and Strategy First are very good at their job. But they are always constrained by time. As a result, it's very easy for some subtle change in the game to get past them. What we had to do early on is put together a pre-quality control team. This was a team made up of developers on the game testing out other developer's code changes. This caught more bugs than our QA team caught, and a large percentage of these bugs would never have been caught by any QA team because the problems were so subtle.
It's an ongoing challenge to be able to add things quickly while making sure that there isn't some nasty side effect. But you can imagine how challenging it is to play test some feature that may not come into play for two hours of game time that wrecks everything. This is particularly true in a strategy game. The 1.0 version of Galactic Civilizations, for instance, didn't take the difficulty level into account when deciding what random events would be called up. To us, who had been playing for months, none of the events were a very big deal. But imagine playing your very first game and a space monster shows up and starts wiping you out while you're still trying to figure out how to pilot the ship. Don't let hardcore players determine features. It is very easy, especially for a small game developer, to let the hardcore players have a disproportional effect on the game design. I spent a lot of time as a project manager nixing proposed or half-completed features by someone who read an idea from one of the "regulars". These special features took precious time away from mainstream functionality to satisfy a hardcore group. Early in development, this was especially problematic. Our young development team was hungry for any sort of good word, so the regulars on our forums carried a lot of weight. It was often difficult to say no to their ideas, even if their suggestions made the game unplayable for the vast majority of users. For a game designer, it is challenging to differentiate between a "hardcore feature" and something that will appeal to most people. I have a general rule of thumb for this, which goes like this: If the person proposing the new feature uses the phrase "You could always enable/disable this feature from the options screen…", it's likely a hardcore feature. For example, one design decision we made was to prevent the AI from winning the game via a technology victory or an alliance victory. The purists really objected to this. To them, if the Arceans (one of the civilizations in the game) ally up with everyone, they should win - too bad for the player. The hardcore players also felt the same about the technology victory: if the Yor reach "The Final Frontier," they should win. We nixed these two victory conditions for the computer players, because they aren't the ones paying for the game. As soon as the Drengin and Altarians start buying games from our company, they can win an alliance victory. Until then, too bad for them. Play the game on low-end hardware as much as you can. Galactic Civilizations would have been a pig if it weren't for some of us playing/developing the game at home on our lower-end hardware. Most of my coding was done on a ThinkPad T20 (600Mhz P3) laptop. Probably about a third of my development time was spent rewriting the internals to improve the speed. For a 2D strategy game, it was very slow game, and I was astonished that the beta testers didn't complain about this more. On the Pentium IV's at our office, the machine flew. But on the lower-end hardware, the beta version's frame rate was very slow. That's because early on, we painted everything on the screen constantly. The game might as well have been a full-screen first-person shooter at 1024x768 - without the hardware acceleration. By working on lower-end hardware, we made improvements that resulted in significant frame rate increases. One change, as you might guess, was to make the painting more intelligent. There was no need to repaint the mini-map 30 times a second - once per turn, or when a button on it was pushed, was fine. The performance improvements opened up other doors. Originally the game only supported up to 144 sectors on the largest map. But because of the performance tuning, we could support 24x24 galaxies (over 500 sectors). It also let us do more with the computer AI. As long as I could still play the game on my home Pentium Pro 200, then it was fast enough. That was our threshold of pain. If you're working on a game on a high-end machine that came out in the last six months, make sure you spend some serious time testing the game on a machine used by normal people.
Wrapping It Up Of all the games that I've worked on, the development of Galactic Civilizations went the most smoothly. It stayed on budget and on schedule throughout the project. In the process we put together a solid team and we've retained all of our staff, so we're positioned to develop a sequel if its economically viable, expand into other games, or just work on a different game entirely. As with previous games, the most nerve-wracking part is reading the reviews. We feel comfortable with the quality of the game. It wasn't rushed and we think we've done a good job with it. I tend to have a hard time not taking reviews somewhat personally - at least game reviews. Even though our company's financial health is determined by our non-game software, the games really are a personal development experience. This is the best game we were capable of making at the time. We've learned a lot from this experience and can apply that to future endeavors. It will be interesting to see how Galactic Civilizations fares in the real world.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|