Fallen Enchantress Is Set to Rise: Part 1

In 2010, Stardock released an ambitious turn-based strategy game called Elemental: War of Magic. In what has become a cautionary tale of game development run wild, the Elemental that hit shelves was a smorgasbord of bugs and bad design, but great ideas. It was a beautiful disaster.

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.

Screenshot: http://www.elementalgame.com/

Complex Worlds, Mainstream Graphics

Red River moves the near-future storyline of the infantry shooter from the tundra-covered island of Skira to the sandy deserts of Tajikistan. It retains the key hallmark of an Operation Flashpoint game: vast, seamless playing areas many kilometers wide in which players can choose their own tactics. It also has the same realistic squad-based combat -- with AI teammates or four players in co-op -- and an unnerving attention to detail and authenticity.

“The goal was to make it more accessible to a wider audience,” says Steve Bennett, Red River’s lead programmer. “We wanted a mainstream game rather than a hard-core military simulator. From a technology point of view, we wanted to make everything more efficient, with higher detail and better visual quality right out of the box.”

Increasing Complexity
The rendering team’s challenge at the start was to match previous Operation Flashpoint games in terms of scale, but to live up to modern gamers’ expectations for detail. To make things more difficult, the designers decided that in addition to the wide-open spaces for which Flashpoint is acclaimed, they wanted to improve the density of built-up areas to create more intense battle scenes in tighter spaces.

“The environments in Operation Flashpoint: Red River are more detailed and complex than the last game,” explains Bennett. “Much of the gameplay is based in small villages with narrow paths around a very complex environment with a lot of objects. This expands the range of combat -- from very long range over open terrain, to close up with people coming out of doors and shooting out of windows.”

Stuart Merry, a senior programmer on the Operation Flashpoint graphics team, reckons that as a result of the effort, in some cases there are three times the number of objects on screen at any one time as there were in Operation Flashpoint: Dragon Rising. Although this game is set in a hot, arid environment, most people don’t realize how difficult it is to make a desert look convincing.

“The technical challenge we faced was changing the location and increasing the detail,” says Merry. “The artists wanted shaders and detailing on the objects themselves, so in addition to having many more objects, we had a lot more detail on each object. So we’ve had to implement things like occlusion culling, which allows us to have very dense areas as long as one part of that area isn’t too busy in itself.”

Dave Smethurst, principal programmer on Operation Flashpoint: Red River, says that rendering only what the player can see reduced the overall workload, saving about 30 to 40 percent of the objects in the scene.

“A building may be broken down into five or six draw calls because of the number of materials in them,” he says. “By doing one draw call for the occlusion culling, we can remove, say, six draw calls later on in the pass. Occlusion culling allows us to achieve better frame rates on our minimum hardware target and to render the high detail worlds the artists are authoring it in,” says Smethurst. “Anyone with a minimum spec piece of hardware will notice changes that will bring the game to life.”

Spinning off Physics
Being able to render a more complex world on entry-level graphics introduces new problems, though. Every extra rock, for example, presents a greater path-finding challenge for the AI.

“As the graphical density has increased, so have other elements of the game, such as physics and AI,” explains Merry. “We’ve moved those off to other cores as necessary to achieve our target frame rates, because that’s obviously a huge hit when you double the amount of objects that you can collide with or that the AI has to avoid.”

At the same time, designers were keen to add more non-playable character soldiers into battles. To achieve this, the programming team has reworked the way the engine handles multithreaded routines, introducing dynamic thread distribution that can scale from two to 12 or more cores.

“Learning the lessons from the previous game, we’ve had a look at how we can load balance some of our jobs even better,” says Smethurst. “We’re increasing the number of threads that are running, for instance, and the AI has been threaded out of the main gameplay thread.”

A key target for Operation Flashpoint: Red River has been getting the game running acceptably on entry-level hardware. Obviously some visual compromises will be necessary, but the quality of integrated GPUs now is such that Codemasters believes it is possible to match the graphical performance of, say, a Microsoft Xbox 360 on a midrange laptop. “That’s a scenario that’s only going to get better”, says Bennett.


Photos: flashpointgame.com

The Art of War: Shogun 2

The way of the samurai, with its violence and pageantry, is one of the most romanticized martial traditions in the world -- and no video game has done it quite the justice that Total War: Shogun 2 has. Released on March 15 to almost universal acclaim, the PC-only strategy game is a visual feast. DIG spoke to Mark O’Connell of The Creative Assembly, the developers of Shogun 2, about bringing the world of feudal Japan to life with art and technology.

Digital Innovation Gazette: Shogun: Total War was an offbeat game with a devoted, but relatively small, following. What brought you back for a sequel?

Mark O’Connell: The Sengoku period of Japanese history was a fascinating time, from both a political and a martial perspective. We’ve always harbored a longing to revisit it and apply everything we’ve learned through the evolution of the Total War series. The number of people who play Total War games has of course grown considerably in the last 10 years, and it feels good to bring the intrigue and military challenges of the period to new players as well as old.

Also, Empire: Total War and Napoleon: Total War were vast in scale. We felt a need to reduce this and focus more on the core values of the series. We aimed for depth rather than breadth.

DIG: Can you give us a rundown of the basics of the series?

M.O.: The Total War games have evolved in an enormous number of ways over the years, but the core mechanics have remained the same. Total War features a turn-based campaign experience involving exploration, diplomacy, city management, economics, and army building, coupled with real-time battles on an epic scale.

DIG: The game is very beautiful. How did you go about bringing traditional Japanese art into the digital world?

M.O.: Our dedicated art team basically did a hell of a lot of training. One of our artists literally learned how to paint with Japanese brushes, in the Edo style. We completely immersed ourselves in Japanese culture, with its music, its artwork, its literature, its language and its people. We then worked to apply this style to every part of the game.

DIG: How important was balancing the beauty with realism?

M.O.: It’s worth noting that we took inspiration from the artwork and styling from the Edo period -- which came later than the Sengoku period -- for Shogun 2. These styles resonate much more with a modern audience; they’re more recognizably Japanese, and that’s where the balance comes in. We wanted to create a strong sense of authenticity, and to do that we used a little artistic license.

Other than that, we never really felt constrained. While the period promoted a culture of focus and purity, the daimyos indulged in flamboyant designs that turned their armies into walking works of art. Personal heraldry, armor variants and coloring made samurai armies stand out with tremendous vivacity.

A great example of this is the Horo -- a painted silk balloon stretched over a bamboo frame that the general’s personal mounted guard would strap to their backs before riding into battle. From a design perspective, it was a uniquely beautiful period, and our art team really resonated with that.

DIG: What elements of the game, like motion capture, morale systems, and the like, do you see as being most important to the realistic aspects of the game?

M.O.: It’s impossible to say which are the most important, as different elements contribute to a sense of realism in different ways. Recreating the troop and the weapon types prevalent in Sengoku-period Japan, and achieving the correct balance between them, is a pretty key aspect.

But I’d also say that authenticity of atmosphere plays a large part. This comes from many aspects -- artwork, music, employing skilled and appropriate voice actors, for example -- which all merge into a single, compelling tapestry. It’s impossible to create an identical analogue of medieval Japan, but through extensive study of her history, culture, people and politics, we’ve created a compelling fiction that we feel reflects the cultural and martial aspects of the period with a sense of clarity.

DIG: What goes into developing a great tactical real-time strategy game? How do you approach innovation without alienating your core audience?

M.O.: Smart planning, lots of historical knowledge, and a team of brilliant people following a single vision are what you really need.

And innovation doesn’t have to be about a pile of new features or mechanics. With Shogun 2, we chose to innovate by creating a game of such sumptuous detail that every strand of its DNA speaks of the period in which the game is set. Every unit card, every icon, every encyclopedia entry and menu screen reflects an aspect of the era. During development, we often referred to a concept we called “The Zen of Total War.” It was like a torch that the whole development team carried to help us generate the sense of thematic depth that can come from simplicity.

Creating any kind of game, not just a strategy game, is about building a system for which there are set rules. As you learn how those rules work, you learn how to apply your knowledge for more desirable results -- for example, more victories and fewer casualties. Creating a smart and balanced ecosystem of unit types is obviously crucial to this, and achieving that balance requires an awful lot of experimentation and testing.

DIG: What tools did you use to develop the game?

M.O.: We have our own in-house tools, which we used to develop the game. Alongside these, we use standard tools that you might commonly find at any studio: C++, 3DS Max, and so forth.

DIG: Are there any unique technologies at play in Shogun 2?

M.O.: Yes. As the Total War experience is split across two major areas -- the turn-based campaign and real-time battles -- we need two completely different kinds of AI that still complement each other. Multiply this complexity across numerous AI factions all vying for supremacy -- factions that are capable of making and breaking alliances among themselves -- and you have a hugely intricate situation that demands some pretty specific technology.

In addition, we’ve had to develop our own engine for battles (known as WarScape) because of the sheer amount of troops that can be involved. We’ve been modifying and improving WarScape as we go, and we feel it’s in a great place, as it’s able to handle enormous, visually stunning battles at really decent frame rates.

Read even more about Total War: Shogun 2 from our sponsor

Photo: totalwar.com


Creating the Baseball Simulation in MLB 2K11: Part 1

There were over 2,000 games in the 2010 major league baseball season, and the creators of MLB 2K11 looked at video from almost every one of them while preparing the 2011 version of the baseball simulation game, according to game designer Sean Bailey. “These videos are the same broadcasts that fans at home watch,” says Bailey, a developer with 2K Sports.

Capturing the Movements
“We selected the best shots from the videos that will be most helpful during the motion capture session,” explains Bailey. As a baseball video played in the motion capture, or “mocap,” facility, an actor wearing a black suit lined with sensors mimicked the player’s movements as seen on the video. Hundreds of cameras picked up the motion-capture data from these sensors.

To capture the bat swing as accurately as possible, the actor used a bat of similar weight and material as the real-life hitter uses. And when an actor mimicked a pitcher, he threw the ball from a regulation-size pitcher’s mound constructed in the studio. “Depending on the shot type, they would throw to everything from a catcher to a target to a net,” says Bailey.

Players Get Into the Game

When it came to capturing the motion of pitcher Roy Halladay, the game developers got the best possible person to mimic his pitching: Halladay himself. The Philadelphia Phillies star, who appears on the game box cover, came to the mocap facility and put on the black suit.

“Halladay told us that he throws four pitches: a cutter, a 12-6 curve, a sinker and a split-finger changeup,” says Bailey. “We have equipped him with these same four pitches in MLB 2K11.

Several other players also did their own motion capture work, including San Francisco Giants pitcher and 2010 World Series hero Tim Lincecum. He and other players discussed details of their performances with the developers.

As it turned out, talking to pitchers was especially helpful when the developers were capturing the behaviors of hitters. “Pitchers are always insightful because it is part of their job to be true students of the game,” says Bailey. “They know which hitters are going to battle and foul off six or more pitches when faced with two strikes.”

“Last season, the San Diego Padres patiently took most of Lincecum’s pitches, resulting in a high pitch count in the early innings,” says Bailey. “The Atlanta Braves and Texas Rangers, however, came out swinging at everything against Lincecum in the postseason and ended up striking out a lot against him.”

Getting the Stats Right
Even though pitchers told the developers what they throw and how the batter reacts, the developers still used Inside Edge scouting reports to get the percentages right when simulating outcomes. These scouting reports are the same ones the real-life teams use.

“This allowed us to have players behave just like their real-life counterparts when it comes to the decision-making and tendencies, both on the mound and at the plate,” says Bailey. “For example, Phillies second baseman Chase Utley has a .312 batting average against fastballs versus right-handed pitchers. He hits .392 against pitches thrown to the inside middle of the strike zone.”

This data also helped 2K Sports plan for when the gamer is playing against the CPU. While there are hundreds of different swing animations, there are only three basic swing types: power, contact and defensive. When the gamer is pitching against the CPU, the CPU will select for the batter “one of these swing types based on multiple factors, including the pitch count as well as their contact and power ratings,” says Bailey. These ratings are generated from the Inside Edge scouting reports.

Likewise, when the gamer is batting against the CPU, the scouting reports ensure that “each pitcher in our game will throw each of their different pitches, per count, with the same frequency that they would in real life,” says Bailey.

A starting pitcher in MLB 2K11 typically has between three and five different types of pitches. But each pitch can have more than one signature animation, since a pitcher will pitch out of the stretch rather than use a full windup when there are runners on base. The speed of pitching out of the stretch also affects the ability of the runners to steal bases.

Of course, not all of the motion-capture animations involved game action. Check out part two of our MLB 2K11 coverage and find out how the developers captured the little details and the atmosphere that made the game truly come to life.

Photo Credit: http://2ksports.com/screens/new/mlb2k11

Saving the Universe, One LEGO Brick at a Time

NetDevil, based in Louisville, Colo., is one of those fairy-tale software developer stories: guys who love games start company in basement; work hard; move upstairs to spare bedroom; attempt to save the universe. That would be LEGO Universe, the online game the company recently released in collaboration with the LEGO Group of Billund, Denmark, and NetDevil’s parent company, Gazillion Entertainment.

LEGO Universe is a massively multiplayer online (MMO) game that takes place in an alternate universe populated by LEGO mini figures. Players must protect the final existing vestiges of pure imagination from extinction -- clearly a worthwhile quest and, very probably, a useful skill in life outside the MMO gaming environment.

Everyone Loves LEGO
What sets LEGO Universe apart from most other MMOs is its audience, a posse largely composed of children 8 years and older playing on hand-me-down desktop systems or inexpensive netbooks. It’s a great niche and a natural target for the LEGO Group, but the age of the fan base and the limitations of their gameplay hardware conjure a host of technical and functional challenges.

Erik Urdang, NetDevil’s technical director for LEGO Universe, was in charge of devising an engineering strategy that delivers a superlative user experience, while leveraging all the gameplay a particular player’s platform can deliver. “We’re aiming at youngsters with LEGO Universe, so we are unswervingly dedicated to having a very low minimum specification for the hardware required to play the game,” says Urdang. “Kids don’t usually get new computers; they get their parents’ old computers. So our target market may be playing on computers that were manufactured three, four or five years ago. We are also able to run well on netbooks,” he says. “We’ve made that a priority because they are starting to come to a price point that is very affordable for families.”

“This focus on broad compatibility makes our development process demanding because we have a very lush, beautiful 3D world with large, open spaces” says Urdang. “Supporting a game environment this visual, this complex and this endlessly dynamic on low-end, legacy platforms turns out to be an extremely complex undertaking.”

Engineering Challenges
Predictably, this kind of application architecture calls for fierce software development skills and serious heavy-lifting tools. Urdang is supremely focused on both the development process and the tools. “We develop most of our game code in C++ using Visual Studio,” he says. “Each engineer has a pretty high-end Velocity Micro workstation. To get quick build speeds, we use build servers and automate the process using cruise control. We also use a number of third-party tools and middleware elements that allow us to concentrate on creating the game experience.”

Graphics performance analyzers (GPA) were used extensively in LEGO Universe. “Most people, when you talk to them about rendering a universe made of LEGO bricks, say ‘Oh that should be easy. How hard is it to draw little square bricks?’” says Urdang. “But actually, the LEGO Group is extremely particular about their intellectual property. They don’t want the bricks to look just any old way; they have to look like real LEGO bricks. Shaders have to be precise; the bricks have to look like ABS plastic with the right kind of polish on them. Additionally, the bricks have little cylinders on top, and those have to look round. In order to get them to look right, we need a fairly high-count polygon model.”

Persistent user-generated content and freedom of player movement in the game environment implicitly create an infinite number of paths through the game world. This makes it impractical to test and optimize an MMO without GPA.

“GPA metrics showed one of the smoke effects in the game was using 14.2 percent of the scene budget,” explains Urdang. “We disabled just a small amount of smoke and got back a14 percent increase in frames per second. In another case, we found 21.9 percent of drawing time was being consumed by the way we were handling terrain and rendering a couple of wall pieces. Once identified, issues like these are relatively simple to optimize. GPA has been a huge help for us, finding things like that quickly. It reduces iteration time dramatically. If you’re just poking around, randomly testing things, it takes forever because you can’t optimize what you can’t measure.”

Read more about LEGO Universe from our sponsor


Photo: http://universe.lego.com/en-us/default.aspx