DIG had the chance to talk to Paxton about his role in the development. In the first installment, we discussed the tools and philosophy behind the development process. Here, we talk about how to implement them.
DIG: Was there room for innovation in the Fallen Enchantress development process?
Derek Paxton: This was a new area for me, or at least a major difference between business software and games. Outside of requested changes coming in from major customers, business software has a fairly tight requirements doc that remains true throughout the project. Game development has to be more flexible.
At Stardock, this flexibility was a danger. Although I’ve had to be the gas on some projects I’ve worked on over the years, Stardock needed brakes.
Rather than constant innovation, we had a significant design cycle. The high-level design was produced in about a month, meetings were held to go over each aspect, and anyone interested in that aspect was invited to attend and offer ideas. That phase ended with approval from the executive producer (Stardock’s CEO, Brad Wardell) and detailed design began. In that phase, we broke the high-level concepts into the minutia, and again the team was invited to meetings to go over the various aspects.
Once detailed design was complete, we started the implementation phase. This is where innovation is the least important. The goal of this phase is to get a full-featured version of the game. It doesn’t have to be pretty; it doesn’t have to be all polished. But it needs to have all of the features so that designers can start playing the game and getting real feedback about what works and what doesn’t.
Once implementation is complete, we go into iteration. This should be about a third of the projects’ total development time. This is where we polish the game, add in bells and whistles, change systems that aren’t working, and provide more depth in systems that are more fun than expected. We innovate here, but it’s more about the fine touches than new systems. We do expect that at least one aspect will fall flat and need to be reworked, which is why it’s so critical that we get through implementation quickly. But in general, we shouldn’t be creating new systems at this stage.
DIG: How have you approached the range of PC processing power on the market?
D. P.: The most significant limitation for turn-based strategy games on the PC is the amount of memory a 32-bit operating system allows to an application. Our players want to play on large worlds, worlds that dwarf even the largest StarCraft II maps.
On most saves I check from players, there are well over 1,000 units on the map, as well as numerous cities, buildings and forests. One of the major focuses for Fallen Enchantress is to make the world as interesting as possible. Visual variety is a big part of that, all of which has to be stored in memory so the player can quickly scroll around the map. The problem isn’t storing just what the player is seeing on the screen, but everything the player could be seeing. It’s a significant limitation that we are constantly fighting with.
DIG: The story is a big factor for Fallen Enchantress. What can we expect?
D. P.: Stardock hired author Dave Stern to help create and write the story for the campaign of Fallen Enchantress. Jon Shafer is responsible for the gameplay.
Between the two, we have the talent we need to make sure that the campaign is engaging and fun.
Dave has also gone through the rest of the games, writing assets to help bring out the flavor of the game. I’m not a fan of forcing the player through fixed steps in the name of story, but we do want the players to feel like the world has depth and that the game feels unique and thematic. We want the monsters in Fallen Enchantress to feel right for our game, and feel like they wouldn’t fit in other fantasy games.
Special emphasis has been put on the sovereigns the players play as. They have more history, more specific powers, strengths and weaknesses. They feel like they are a part of this world.