Today, the strategy title "Empire Earth 3" launched. We had the chance to talk with the developer Mad Doc. Our questions were answered by Matthew Nordhaus (Porject Director), David Gosselin(Graphics Programmer) and Daniel Sproul (Engine Programmmer).
Matthew Nordhaus
PCGH: Can Empire Earth 3 only offer improved visuals or other technical overhauls like a modified physics simulation? When starting the development do you program a new engine from scratch or do you just heavily modify the engine of the second part? If so, what parts have to be modified and what was the technical reason behind this? Or why was the technology of Empire Earth 2 outdated so that you require a brand new technology?
Mad Doc: We integrated physics into the MadEngine, the codebase which drives Empire Earth III primarily for visual flair. I describe the physics in detail below, but we actually have two systems for doing two different things. Vehicle and building death were handled by a system we wrote internally. Unit Ragdoll was handled by Aegia.
There was no true physics in Empire Earth II, so really we started from scratch on this game. The Technology of EE2 was outdated only because we released the game more than 2 years ago! Game technology is a moving target, and we always want to try to make our games as cutting edge as we can. From that point of view, it seemed like physics was a nice visual addition which would enhance the look of our game.
PCGH: Today visuals play an important role even in the production of strategy games. From your point of view how important are visuals for your game? Do you think visuals are even more important than gameplay? When developing a title what are you focusing on?
Mad Doc: In some important ways, visuals are actually an important part of gameplay in RTS games. Most of the time, the player has his camera zoomed out, to see as much of the battlefield as possible. Identifying units quickly is very important. You want to be able to tell different unit types apart, and you want to be able to tell your units from enemy units quickly.
Adding normal maps to the units, exaggerating their features, and making sure we had a robust system for creating player color on the units are all things we focused on to make sure the player has a positive experience.
The outline of the unit is often the first and most important visual feature that people use for identification. With this in mind, we increased the polygon count of the units in EE3 so that we could put in more edge detail, which must be created in geometry. The normal maps and increased texture detail in specular, diffuse, and glow maps enhanced the units appearance when you zoom in, but often its that first quick visual that you need 90% of the time to identify units when you are playing.
PCGH: Can you please list the major graphical changes when you compare the second part of Empire Earth with the third part? Can you give technical details how you modify the rendering engine?
Mad Doc: A large portion of the graphics engine was completely rewritten for Empire Earth III. We really wanted to include some of the newer graphical features starting with shader technology. The Empire Earth III engine was written with shaders in mind from the start, which gave us a lot of flexibility in terms of graphics technology. In addition to incorporating shaders we wrote several custom renderers for terrain, water, particles. Another addition to the engine was the ability to script the rendering of the scene; this allowed us to more easily add new rendering techniques as we were developing the game. In addition we added some special code to try and take advantage of available hardware features (FSAA, alpha to coverage, shadow depth maps).
PCGH: Does the modified version of the renderer support techniques like HDR, Parallax-Occlusion-Mapping, Soft Shadows, Ambient Occlusion Shader 3.0 support etc.? Are there other rendering techniques that are worth mention?
Mad Doc: Our engine was written to allow us to use pretty much any shader version that we wanted, in the end we settled on supporting 2.0, 2.B, and 3.0. These covered a large range of hardware as well as keeping a high minimum feature set. As far as features go, we are currently supporting HDR lighting, ambient occlusion, and screen distortion effects (like the Quantum Singularity Gun). There are also a lot of smaller shader based effects we use for a lot of the weather and environmental effects. For example the snow accumulation and height based fog are all shader based effects that we apply when conditions are right.
PCGH: If you have a look at the CPU market you can hardly buy a single core CPU. So one technical trend in the gaming industry is dual or even multicore processors. Will your improved/new version of the engine scale with two or more cores? If yes, what are the threads that can be separated and what is the estimated performance gain compared to single core machine?
Mad Doc: The last time we measured, when we were doing opimizations with Intel, dual core bought us around 15% according to their measurements. This was deemed acceptable but not impressive. Most of this was due to multithreading being added late in the project due to other, pressing issues.
I suspect with optimizations we added near the end of the project the performance improvements are greater than that, but we dont have any recent test results. Intel indicated that 40-50% is the most you could reasonably expect to get. During really intense battle situations we might be able to realize 50-100% increase, but we have not actually tested that rigorously.
We also should have a smoother framerate when running dual-core, because of the thread used to stream assets, and because the simulation is running in a separate thread, but we don't have any hard numbers on this.
Our threads are:
- Main (rendering) thread
- Simulation thread
- Asset loading thread
- Input thread
- Sound thread
- Networking thread
The ones relevant to dual core and beyond are the main, sim, and loading threads.
David Gosselin
PCGH: A detailed and realistic physic simulation has become popular even in RTS-Games. Where you beware of that when starting to develop Empire Earth 3. How important are physics for you game? Will the third part feature an improved physics simulation? What are the differences between the physics in the second and third part of Empire Earth? Is you physics engine build inhouse or do you license a technology? What were the reasons for/against programming a physics engine on your own? Will the physics even affect gameplay?
Mad Doc: There are actually two separate systems running physics in our game. We created, from scratch, a system which can handle impulses and collision for non-simming objects. For example, we can break a building, vehicle, or airplane into chunks when it dies and give the pieces an impulse away from the center of the explosion. We also compute the ground plane based on the location of the unit and bounce the pieces around. For this system we did not need to do a great deal of high level computation. It was necessary to minimize the computation because we could have dozens of units onscreen at the same time chunking and we wanted to make sure the physics didnt drag the framerate down. The bounding boxes around the chunks are cubical or rectangular, and the ground plane is a flat plane, but the explosions are still very satisfying and look quite realistic.
This system also allowed us to impart impulses to units when they fire weapons or are hit by a projectile. This leads to some nicely realistic motion (think of a modern tank firing and rocking back on its treads a little bit).
The second system uses Aegia to ragdoll units when they are dead. We chose to use Aegia because it allowed us to integrate ragdoll into our Gamebryo middleware all at once. There were some special steps we had to take to make sure that our animation rigs were set up properly as we created the units for this.
Its important to note that both of these systems only affect items which are not being simulated in lockstep for multiplayer. The chunks from buildings do not interact with units, and the chunks from vehicles only appear after they die. The impulses from projectiles perturb the unit but do not change its position. Ragdoll only occurs after a unit is dead.
We dont have sim-affecting physics for two reasons. One is that we want to keep network traffic to a minimum. When you have 800 units moving around and you add physics chunks as well your network latency can start to affect the perceived performance of the game. The other reason is that we want to make sure the RTS portion of the game is deterministic for players. Adding in random damage from rolling chunks of buildings or flying debris from exploding airplanes would complicate our balancing efforts, which are already quite complicated.
PCGH: During the developing process have you ever thought about implementing support for Ageias PhysX card or even Havok FX? What is your opinion about hardware accelerated physic?
Mad Doc: We did look at both the Ageia hardware and Havok engine. We actually implemented Havok in our game as a trial early on, but in the end went with Ageia. I think accelerated physics is a great idea, but we havent really seen it catch on yet as far as having an install base. It will be interesting to see how they handle the chicken and egg problem of having no games that use the hardware, because there are not enough machines with the hardware installed, because there are not any games that use the hardware
PCGH: During a presentation we were told that Empire Earth 3 will not support the new DX 10 API? What were the reasons to do without? What do you think about the new Vista API? Is it really a milestone as far as development is concerned? What are the advantages DX10 visuals have to offer to the RPG Genre?
Mad Doc: At the time we started Empire Earth III D3D10 was a long ways off and it didnt make sense to target it for our release. As we got closer to our release it just didnt make sense to add it at the last minute and not really take advantage of any its feature set. There are some definite advantages I can see to using D3D10 and some specific features like texture arrays that I can see being very useful for developing an RTS
Matthew Nordhaus
PCGH: Can Empire Earth 3 only offer improved visuals or other technical overhauls like a modified physics simulation? When starting the development do you program a new engine from scratch or do you just heavily modify the engine of the second part? If so, what parts have to be modified and what was the technical reason behind this? Or why was the technology of Empire Earth 2 outdated so that you require a brand new technology?
Mad Doc: We integrated physics into the MadEngine, the codebase which drives Empire Earth III primarily for visual flair. I describe the physics in detail below, but we actually have two systems for doing two different things. Vehicle and building death were handled by a system we wrote internally. Unit Ragdoll was handled by Aegia.
There was no true physics in Empire Earth II, so really we started from scratch on this game. The Technology of EE2 was outdated only because we released the game more than 2 years ago! Game technology is a moving target, and we always want to try to make our games as cutting edge as we can. From that point of view, it seemed like physics was a nice visual addition which would enhance the look of our game.
PCGH: Today visuals play an important role even in the production of strategy games. From your point of view how important are visuals for your game? Do you think visuals are even more important than gameplay? When developing a title what are you focusing on?
Mad Doc: In some important ways, visuals are actually an important part of gameplay in RTS games. Most of the time, the player has his camera zoomed out, to see as much of the battlefield as possible. Identifying units quickly is very important. You want to be able to tell different unit types apart, and you want to be able to tell your units from enemy units quickly.
Adding normal maps to the units, exaggerating their features, and making sure we had a robust system for creating player color on the units are all things we focused on to make sure the player has a positive experience.
The outline of the unit is often the first and most important visual feature that people use for identification. With this in mind, we increased the polygon count of the units in EE3 so that we could put in more edge detail, which must be created in geometry. The normal maps and increased texture detail in specular, diffuse, and glow maps enhanced the units appearance when you zoom in, but often its that first quick visual that you need 90% of the time to identify units when you are playing.
PCGH: Can you please list the major graphical changes when you compare the second part of Empire Earth with the third part? Can you give technical details how you modify the rendering engine?
Mad Doc: A large portion of the graphics engine was completely rewritten for Empire Earth III. We really wanted to include some of the newer graphical features starting with shader technology. The Empire Earth III engine was written with shaders in mind from the start, which gave us a lot of flexibility in terms of graphics technology. In addition to incorporating shaders we wrote several custom renderers for terrain, water, particles. Another addition to the engine was the ability to script the rendering of the scene; this allowed us to more easily add new rendering techniques as we were developing the game. In addition we added some special code to try and take advantage of available hardware features (FSAA, alpha to coverage, shadow depth maps).
PCGH: Does the modified version of the renderer support techniques like HDR, Parallax-Occlusion-Mapping, Soft Shadows, Ambient Occlusion Shader 3.0 support etc.? Are there other rendering techniques that are worth mention?
Mad Doc: Our engine was written to allow us to use pretty much any shader version that we wanted, in the end we settled on supporting 2.0, 2.B, and 3.0. These covered a large range of hardware as well as keeping a high minimum feature set. As far as features go, we are currently supporting HDR lighting, ambient occlusion, and screen distortion effects (like the Quantum Singularity Gun). There are also a lot of smaller shader based effects we use for a lot of the weather and environmental effects. For example the snow accumulation and height based fog are all shader based effects that we apply when conditions are right.
PCGH: If you have a look at the CPU market you can hardly buy a single core CPU. So one technical trend in the gaming industry is dual or even multicore processors. Will your improved/new version of the engine scale with two or more cores? If yes, what are the threads that can be separated and what is the estimated performance gain compared to single core machine?
Mad Doc: The last time we measured, when we were doing opimizations with Intel, dual core bought us around 15% according to their measurements. This was deemed acceptable but not impressive. Most of this was due to multithreading being added late in the project due to other, pressing issues.
I suspect with optimizations we added near the end of the project the performance improvements are greater than that, but we dont have any recent test results. Intel indicated that 40-50% is the most you could reasonably expect to get. During really intense battle situations we might be able to realize 50-100% increase, but we have not actually tested that rigorously.
We also should have a smoother framerate when running dual-core, because of the thread used to stream assets, and because the simulation is running in a separate thread, but we don't have any hard numbers on this.
Our threads are:
- Main (rendering) thread
- Simulation thread
- Asset loading thread
- Input thread
- Sound thread
- Networking thread
The ones relevant to dual core and beyond are the main, sim, and loading threads.
David Gosselin
PCGH: A detailed and realistic physic simulation has become popular even in RTS-Games. Where you beware of that when starting to develop Empire Earth 3. How important are physics for you game? Will the third part feature an improved physics simulation? What are the differences between the physics in the second and third part of Empire Earth? Is you physics engine build inhouse or do you license a technology? What were the reasons for/against programming a physics engine on your own? Will the physics even affect gameplay?
Mad Doc: There are actually two separate systems running physics in our game. We created, from scratch, a system which can handle impulses and collision for non-simming objects. For example, we can break a building, vehicle, or airplane into chunks when it dies and give the pieces an impulse away from the center of the explosion. We also compute the ground plane based on the location of the unit and bounce the pieces around. For this system we did not need to do a great deal of high level computation. It was necessary to minimize the computation because we could have dozens of units onscreen at the same time chunking and we wanted to make sure the physics didnt drag the framerate down. The bounding boxes around the chunks are cubical or rectangular, and the ground plane is a flat plane, but the explosions are still very satisfying and look quite realistic.
This system also allowed us to impart impulses to units when they fire weapons or are hit by a projectile. This leads to some nicely realistic motion (think of a modern tank firing and rocking back on its treads a little bit).
The second system uses Aegia to ragdoll units when they are dead. We chose to use Aegia because it allowed us to integrate ragdoll into our Gamebryo middleware all at once. There were some special steps we had to take to make sure that our animation rigs were set up properly as we created the units for this.
Its important to note that both of these systems only affect items which are not being simulated in lockstep for multiplayer. The chunks from buildings do not interact with units, and the chunks from vehicles only appear after they die. The impulses from projectiles perturb the unit but do not change its position. Ragdoll only occurs after a unit is dead.
We dont have sim-affecting physics for two reasons. One is that we want to keep network traffic to a minimum. When you have 800 units moving around and you add physics chunks as well your network latency can start to affect the perceived performance of the game. The other reason is that we want to make sure the RTS portion of the game is deterministic for players. Adding in random damage from rolling chunks of buildings or flying debris from exploding airplanes would complicate our balancing efforts, which are already quite complicated.
PCGH: During the developing process have you ever thought about implementing support for Ageias PhysX card or even Havok FX? What is your opinion about hardware accelerated physic?
Mad Doc: We did look at both the Ageia hardware and Havok engine. We actually implemented Havok in our game as a trial early on, but in the end went with Ageia. I think accelerated physics is a great idea, but we havent really seen it catch on yet as far as having an install base. It will be interesting to see how they handle the chicken and egg problem of having no games that use the hardware, because there are not enough machines with the hardware installed, because there are not any games that use the hardware
PCGH: During a presentation we were told that Empire Earth 3 will not support the new DX 10 API? What were the reasons to do without? What do you think about the new Vista API? Is it really a milestone as far as development is concerned? What are the advantages DX10 visuals have to offer to the RPG Genre?
Mad Doc: At the time we started Empire Earth III D3D10 was a long ways off and it didnt make sense to target it for our release. As we got closer to our release it just didnt make sense to add it at the last minute and not really take advantage of any its feature set. There are some definite advantages I can see to using D3D10 and some specific features like texture arrays that I can see being very useful for developing an RTS
Zuletzt bearbeitet von einem Moderator:
