Enter Derek Paxton, a modder who earned his bones developing the most successful Civilization IV mod, Fall From Heaven. His task was to create a standalone expansion for Elemental that delivered on the original game’s promise while avoiding its pitfalls. (In fact, Fallen Enchantress will be available for free to anyone who bought the first game.)
DIG caught up with Paxton as production on Fallen Enchantress was wrapping up to see how he went about righting the ship.
DIG: Can you tell us about your role on Fallen Enchantress and the history of the project?
Derek Paxton: Fallen Enchantress is a turn-based strategy game set in a fantasy RPG world and inspired by Master of Magic. I am the lead producer and lead designer on the project. As the designer, I determine the features and mechanics for the game. There are talented game designers here at Stardock, including Brad Wardell, lead designer of Galactic Civilizations, and Jon Shafer, lead designer of Civilization V, so I get a lot of help from the team.
As the lead producer, I have three main responsibilities: to plan (schedule who is doing what and when they are doing it), to communicate (make sure everyone understands the plan and the final goal), and to control (make sure we are progressing against the plan and taking care of issues that come up).
DIG: What did your previous experience — and that of your team — bring to the development process?
D. P.: I came to Stardock in November of 2010. Prior to that, I worked as a project manager for an enterprise software company. My customers were banks, government agencies, and insurance companies. My professional experience comes from working on large software projects, which has helped me formalize the processes at Stardock and embrace the tenants of successful project management — constant communication, avoiding scope creep, and specific, quantifiable goals.
When I wasn’t working, I created a dark fantasy mod for Civilization IV called Fall from Heaven. I worked with a group of talented modders and artists, and it became the most popular mod for Civilization IV, with over half a million downloads. So my passion has always been in creating strategy games — particularly fantasy strategy games.
DIG: Have you used any specific technology, hardware or software in developing Fallen Enchantress?
D. P.: We use products like Bink, Havok and Miles as engine pieces for the game. Stardock has developed its own game engine, which is great because it allows us to add and change features as needed — which wouldn’t be possible if we produced a commercial engine. It does carry the disadvantage of having to support the engine. We can’t trust that there is another team of dedicated people that we can report engine memory leaks or crashes to. We need to fix them ourselves.
Personally, I live in Excel. The game assets are all in XML, but rather than changing them with Notepad or another text editor, I have them all in a huge Excel document. That way, I can easily tweak values and compare all the assets of a particular type to each other. It also does some data modelling for me so I can see a graph of all the monsters in the game and see if they are underpowered or overpowered for their level on various attributes.
DIG: While Fallen Enchantress is being characterized as a standalone expansion of War of Magic and shares some of the previous game’s assets, many of the gameplay mechanics appear to have changed. How have you identified systems that needed to change and how did you implement those changes?
D. P.: From a design perspective, it was a review from the ground up. Nothing was sacred, and we went through what we liked in the game, what Master of Magic did and the early concept docs for War of Magic. War of Magic changed so much in its development, largely because of the challenge of building a game engine at the same time as building a game (if the engine couldn’t support a feature, the feature would be dropped or significantly altered to fit). Having a complete game engine meant that we could focus on the game.
Implementing the changes was a scheduling task. Each major feature received its own functional design doc with the list of assets it covered and the systems that would be required to make those assets function. A developer was assigned to that feature according to the project schedule and was responsible to turn the design doc into an implementation plan. They would lay out the code-level plan, what functions would be needed and how existing classes would change. That plan would be reviewed by the senior developers who offer feedback for things like shared functions, efficiency and more mod-able designs — and once approved, they would start coding.