Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Stardock's Galactic Civilizations 2: Dread Lords
arrowPress Releases
August 15, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: Stardock's Galactic Civilizations 2: Dread Lords

April 5, 2006 Article Start Previous Page 3 of 3

What Went Wrong

For a game that has gotten critically favorable reviews and is selling like crazy, you might think that it was smooth sailing. But it wasn't. More things went wrong on this project than any other I've worked on. That the whole thing didn't fall apart was less a miracle than simply because the development team, individually, stepped up to make sure things went right.

1. Growing Pains. The entire GalCiv I development team stayed for GalCiv II. Moreover, they all are still here. That's good. But nearly every game developer we picked up between then and now we lost. So as I write this in March 2006, the GalCiv II team is a lot like the GalCiv I team except we have one additional developer.

So what happened? Each loss has its own story. In some cases, it's location. We're located in Plymouth Michigan. So some internal developers had a significant drive involved. For others, it was money. Contrary to what Game Developer magazine prints, the average game developer does not make big bucks. Game developers, on average, make less than developers in other industries. This is for the simple reason that it's more fun to make games than it is to write some database front end. Some game developers make a lot of money, but that is not the norm.

There was also a change in culture. Stardock had grown a lot and purchased a brand-new building. Our old place was a bit of a dump but it felt like a really unique small company feel. You might be working in a closet (literally) but it was your closet. The new building is very nice but it's much like any other office in some respect except with nice new furnishings. Some felt we lost a bit of that small company feel. As our staff increased, so did the difficulty of managing that many people. That meant the creation of policies and guidelines that we didn't need before. Some people resented that and eventually decided to leave.

And in some cases, it was personal conflict. With some of the senior level developers who came in, my style of development was in conflict with what they wanted to do. I tended to be more conservative with how I code things. I am less interested in using the latest/greatest STL techniques than I am in having readable code that is easy to look at in a debugger. This created some clashes during development as I would get frustrated when I'd find a bug in something that I found difficult to read. I personally get no joy from coding. I am only interested in making the game work. So I don't care about using some cool technique. I care about algorithms that are robust, reasonably fast, easy to modify, and will still make sense 3 years from now.

My way is not the best way to do things. It is simply one way. Because there's a counter argument to how I tend to do things: From a career point of view, unless you plan to spend the rest of your career making games, you need to learn and keep up with these new techniques so that you don't one day wake up as one of those 50-year-old COBOL programmers who has long since fallen behind the latest techniques.

Over time I did let up a little on this but too late for some of the people who left. But "latest coding techniques" can bring in other issues.

2. Underestimating compatibility with 3D. Our game is very multi-threaded. Unfortunately, some of the latest/greatest C++ goodies are not very thread safe. This is something that would cause us quite a bit of grief. Moreover, it made debugging difficult and time consuming. The project was months behind schedule by October of 2005, just months before shipping. My job at Stardock is running the company -- the whole company. But at that point, the project was so far behind that I ended up stepping in, moving out of my office and into one of the work stations in the main lab right in the middle of the team.

Features were altered and cut. And code thoroughly debugged. But we weren't ready. We thought we were. But we weren't. The game wasn't buggy. But we had no idea of how finicky different computers are with 3D games. We had no idea.

The last 4 weeks before release essentially involved us and our QA team sitting around playing the game all day. We took pride in our reputation of always shipping games that have virtually no support issues whatsoever. And we were probably a little too cocky about that reputation. We bought into the popular mythology that the reason why other games are "buggy" is because they're "rushed". Not us though. We were the developer and publisher. Nobody could pressure us to put out the game until we were ready. One gamma tester even accused us of having "separation anxiety". That we were holding the game back simply because we didn't want to commit to releasing it. It was ready to go.

And yet, within days of release it was clear that some people were having problems. We sold enough units to get a very specific numbers: 2.5%. A small number right? But on GalCiv I, that number was less than 0.25%. So that's a 10X difference. What was the problem? Had we missed something?

Well it turned out that we had. For one thing, competition in the 3D hardware arena between ATI and nVidia resulted in video cards that were running a lot closer to their max capacity than previous generations. And our game made heavy use of these new features. As a result, these cards could get hot. Very hot. So what would happen is that within a few minutes or a few hours, the game would just unexpectedly crash. We'd get these debug reports and they just didn't makes sense to us. Some simple drawing function would crash. What was going on?

When you combined that problem with the usual piddly bugs along with a not-so-piddly bug with a case where a user could click on a Goto button in a report screen which took them to another screen, which they could then go to another screen, which they could go to another screen, and if they then tried to create a ship and save, the game would crash (too many dialogs -- none of us had ever tried doing that), you ended up with a small but important percentage of people who were unhappy. Most of the reviewers didn't run into it. But if you have a problem that affects 2.5% of people and you have 100 reviews, then you are going to have at least 2 people who are going to have a problem.

We fixed it within the first couple of days of release with a GPU throttling option. Suddenly, by magic, the game became very stable for those people.

The other issue we totally underestimated was how many people don't ever update their video drivers. This continues to be one of the most frustrating problems to deal with. We got a harsh lesson in customer support and the limits of it. Even though the game would pop up a dialog saying "Your video drivers are too old to run this game, you will experience random crashes if you do not update them." (even the 1.0 retail version had that because we knew this from testing) we still had people who would ignore this, have the game crash, go to our forums and post a big "This game is bugggy!!111". It was very frustrating to work through these users only to find they had a 4-year-old video driver that didn't support the new DirectX 9 functionality we were using.

The usual response when we'd ask them why they ignored the warning dialog was "My other games work fine." Other games usually being 4-year-old sprite-based games.

What we learned from these two experiences were:

First, keep adding new users to your testing process. As people become experts at the game, they start to play the game differently from others. Yea, there's probably some QA guy reading this saying "Well duh" but it was not something we had done.

Secondly, users won't heed warnings or readmes. Next time, the game will have a dialog that will simply not allow them to play the game until they update their drivers.

3. Publishing: Babes in the woods. You go to some store and they have a big promotion for "Game X" or you go to some game website and they're promoting "Game Y". How do they go about promoting that? I don't know. It seems like I should know that. As a publisher, especially one with oodles of marketing dollars just looking for a place to spend them, I should know this. But I don't. I still don't. And what's worse, we have the money. But we don't know. That's something we're going to have to improve on.

Marketing was much the same way. We learned a lot about the media this time around that I wish I could forget. It's not corrupt. At least, it's not corrupt in terms of reviews -- though if you're a big name game, you'll get a heck of a lot more benefit of the doubt than an indie game. Make no mistake on that. We couldn't even get preview coverage in all the game mags even though we had AEG as our PR firm. It got consistently better over the months and I think things will continue to get better as we learn more and the powers that be outside the editorial departments realize that Stardock isn't some start-up. We've made a lot of stuff over the years that was published by others. But we didn't do as good of a job at marketing as I would have liked.

We met our sell-in numbers but I would have liked to do more promotion to help push more people to the stores.

4. Are we a board game or a simulator? It's tough being a sell-out. It's less tough being a spineless sell-out which is the one thing that saved me from utter despair. In my strategy games, I like what is called "fuzzy math". I'm not alone in that. I don't like games whose game mechanics are so crisp that there's no intuition involved. But I also know that reviewers generally prefer strategy games to be almost like board games where every number in the game has a simple, straight-forward source.

In a board game, you'd ask: Why is your approval rating 40%? "Oh, because I have a population of 10 but only 4 entertainment centers. 4/10 = .4 = 40%."

In a simulation, you'd ask "Why is your approval rating 40%?" "Oh, because your population is 10.4 billion, your tax rate is 46%, your morale ability is +20%, you are mining a Harmonic Crystal formation in sector 2,5 which is adding another 15% to your morale ability plus you've built a virtual reality center which is adding another 10%." Huh?

In a board game, you read the manual and you understand the mechanics. In a simulation you play the game and you start to get a feel for how things are interlinked. I prefer the latter but I know that most gamers prefer the former. Since I'm a spineless sell-out, we made GalCiv II like the former much more. Factories now produce X industrial units. Research labs produce Y industrial units.

But.. we still have that Civilization ability that can be increased in a variety of ways during the game. And that is where we end up having bits of intuitive play come in because you end up having to play-balance things and you can't do it all just by "nerfing" modules or starting values. Sometimes you have to tweak values and the result is fun for most people. But for some people, they really don't like that.

So we'll have to keep improving the game to try to make both camps happy. We want to keep the game from being a spreadsheet but we want to put areas in where people who want can really dig in and find out why every number is what it is if they really want to look it up.

5. IT backbone. Our websites all use technology we developed. Our forums, accounts, articles, libraries, etc. They all use the same stuff. Unfortunately, the popularity of Galactic Civilizations II put on a tremendous strain on this that we found ourselves unprepared for. You'd think that companies like us would learn from companies like Blizzard who end up having to beef up their infrastructure after their games ship. But we didn't and so we had to scramble to add more capacity.

Ships can become increasingly complex due to the engine's ability to take on increasingly advanced models.


Lessons Learned

Don't overspecialize developers. Because we had never had anyone leave during a project before, we were unprepared for the consequences of someone leaving mid-game. While no one left suddenly (everyone gave plenty of notice), it put us in the situation of having parts of the game engine that were not well understood by anyone.

Bring in fresh beta testers throughout. This was a key lesson we'll be applying into future games. New testers play the game differently than people who know a lot about the game. The most serious bugs in QA were found by new players.

Test on very high-end hardware. In the postmortem for GalCiv I I wrote as one of the key lessons:

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 PIII) 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 4's in our office, the game flew. But on the lower-end hardware, the beta version's frame rate was very slow.

And we took that to heart. Too much to heart. Because we focused so much on working on older, slower machines we missed the group of users who were buying the latest/greatest 3D cards and putting them into their existing computers which weren't well ventilated enough to deal with the GPU getting hot. If we had, the game would have had GPU throttling built in and a lot of problems fixed. For non-developers reading this, GPU throttling doesn't slow down the game, it just puts a sleep(10) call between frames if the frame rate is getting ridiculously high. GPU throttling has no negative on performance. It just keeps the card cooler.

Luckily, things worked out fine, but I would have liked to not had to put out an update to address something that could have been caught if more time was spent checking out the latest hardware.

License more technology. One of the things we learned is that we will likely license more of our technology in the future. For instance, GalCiv I had its own built-in sound system. This time, we used the Miles sound system that we licensed from Rad Game Tools. It was much much better and easier to work with.

Features that enable the users to be part of the content creation process are good. The ship designer in Galactic Civilizations II has become almost as popular as the actual game. In future games, we will be looking to see what kinds of features we can have that allow users to show off their creativity.

Sampling of ships designed by players using the included in-game content.


Unlike the first Galactic Civilizations for Windows which was the smoothest project I'd worked on, this one was the toughest. It was big and ambitious. The sales and reviews and customer feedback indicate that it was worth doing. But it was a real challenge. The first GalCiv went so easily because we didn't really have to push ourselves to make it. This one was a real challenge to make and tested our entire company's ability to make something that was truly for the big time. We got a taste of what the difference is between a "B" game and an "A" game. With any luck, Galactic Civilizations III will be a AAA game in every sense.

Final UI design


Publisher: Stardock
Number of Full-time developers: 12
Number of Contractors: 3
Length of Development: 18 months
Release Date: February 21, 2006
Platform: PC (Windows)
Budget: $1.3M
Development software used:
3D Studio Max, Visual, Maya.
Development hardware used: Various PC Compatibles
Notable Technologies: BINK, Stardock 3D engine, Stardock DesktopX, Miles Sound System.
Project Size: ~5 Terrabyte, released game uses around 1.4 Gigabytes.





Article Start Previous Page 3 of 3

Related Jobs

innogames — Hamburg, Germany

Java Software Developer
Wooga GmbH
Wooga GmbH — Berlin, Germany

Unity Game Engineer
innogames — Hamburg, Germany

Expert / Senior Java Software Developer - New Mobile Game
Disbelief — Cambridge, Massachusetts, United States


Loading Comments

loader image