Gamasutra - Features - "Postmortem: Stardock's The Political Machine"

Flexible Design. We started development of this game in January 2004. That gave us 6 months to write a 3D engine for it, come up with the screens, the gameplay, multiplayer, and, of course, put together the statistical model and computer AI. In January we had a vague idea of what kind of game we wanted. We pictured it would be a kind of You Don't Know Jack for politics with a map. The final game, for those who don't know, is nothing like that. The design we started with doesn't remotely resemble the final game, despite the fact the title was sent to manufacturing right on time, 6 months later.

This flexible design extends to how our developers worked. We put the artists and the developers in the same room. and so they worked out more efficient ways to work together. For example, because we were so short of time, we needed a way to be able to crank out interface screens very fast. In a correctly managed project, screens are mocked up, gone over by the producer, marked up, and then submitted to the development team for implementation. We didn't have time for that process.

So, we used Stardock's own Windows desktop object creator/manager, DesktopX to create the interfaces. With that, the mockup was the interface. If we wanted to make a tweak, we could do it on the live interface (fonts, positioning, sizing, color, etc.). We then exported our interfaces as DesktopX .dxpacks, which we then read in the game and use. If someone didn't like a screen, no problem, they could tweak it themselves. Without this, we wouldn't have been able to finish the game on time. This wasn't planned, by the way. In fact, we were desperate, and our lead graphics designer (Paul) and lead engine developer (Cari) came up with this on their own, to solve the problem of needing the mockup to have live interface functionality.

Using DirectX 8/9. Microsoft deserves some credit for the changes it has made to DirectX, making it possible for us to easily combine our 3D engine with 2D elements. This is good news for us, and bad news for those who make 3D engines for games that they license.

Now, what's the big deal about DirectX 9? Well, the biggest thing that we got out of it was the ability to have TrueType fonts. Most games have to include their own encoded fonts. But with DirectX 9, we were able to just include and use TrueType fonts, which saved a lot of time, and made GUI elements look very attractive with little effort. It also allowed us to mix sprites and 3D elements much more easily.

For example, in our last game, Galactic Civilizations, there is no zooming in or out of the map. That's because it's a 2D sprite-based game. But with The Political Machine, you can zoom in and out on the map all you want, and it's very smooth and fast, even though the actual units are just sprites. Also, thanks to 3D acceleration, you can play the game on amazingly low-end hardware. My old Pentium II 400Mhz running Windows 2000 plays the game fine, even though it just has an old TNT graphics card in it.

Tools. This was the first game where we actually made tools to create the data. Anyone familiar with Stardock games knows that our "data" is usually just a collection of text files. But because of the complexity of the political issues and interview questions from the cable TV shows, we needed to create some tools. This made us able to create much more sophisticated interaction with the TV interviewers than would have otherwise been possible.

The tools were integral to the game because they let you focus on the content, rather than worrying that making a single typing error in a file would cause the game to crash. When you develop tools to create your content, you can then control the way the data is presented in a much more considered fashion. For instance, in a game like The Political Machine, it's vital that the game be equally fair to Republicans and Democrats. The tools would let us visually see how a given issue was tilted much more easily, compared to sifting through text files and looking at raw data.

New Bug Tracking System. Bug tracking at Stardock has been a long and questionable journey. We've tried out various systems and always ended up back to a spreadsheet. This time, we settled down with FogBugz which has worked terrifically for us.

In the past, we just used spreadsheets for our bug tracking. This works to a degree, but it's not as efficient as something like FogBugz. With FogBugz, our beta testers could email in a bug report, and it would automatically show up in the program. Then the project manager could go through and assign priorities, and the team could then jump in and see what they needed to work on. It's important to stress again - we started/finished this game in 6 months, which included development time for the 3D engine, all the artwork, and the multiplayer. We had to be very efficient in how we did it.

Good QA from Ubisoft. Ubisoft really provided great QA, and were very easy to work with. They were absolutely essential to the game's success because of their greater experience in dealing with problems of 3D engines. Their clout helped too. When we had problems with ATI or Nvidia cards, Ubisoft could ring up someone at one of those companies and get a response to help us with.

______________________________________________________

What Went Wrong