Splash Damage's Paul Wedgwood shares some insights on the technology being used for the upcoming Quake Wars.

 This August, GameSpy made its annual pilgrimage to QuakeCon, where thousands of Quake and DOOM fans gathered for four days of fun, games, tournaments, and special hands-on opportunities with games like the upcoming Enemy Territory: Quake Wars. In the second installment of our Quake Wars developer diaries, Splash Damage owner and lead designer Paul 'Locki' Wedgwood offers his thoughts on QuakeCon feedback, and shares some insights into using the advanced technology created for the game.

In today's diary I discuss the challenges Splash Damage and id have overcome in building an advanced multiplayer game engine that features the new "MegaTexture" technology, brute-force rendering, advanced vehicle physics and stream-lined networking, all with the goal of significantly improving player immersion, and ultimately, gameplay.

The Initial Decision

My good friend Kevin Cloud (co-owner of id Software and creative director on ETQW) and I started working together on the high concept for ETQW back in the summer of 2003 (right around the time our two companies finished Wolfenstein: Enemy Territory together).

For both of us, the vision of ETQW's gameplay and universe was pretty straightforward… We'd lived and breathed Wolfenstein: Enemy Territory together for a year and a half, and had a million ideas for building on Enemy Territory's teamplay; today, this remains our shared obsession.

However, ETQW would be Splash Damage's first full commercial project, with little commercial development experience, and unlike Wolfenstein: Enemy Territory, no existing game, engine or art assets to use as a base. I was always confident that the game design and art direction would do the gameplay and universe justice, but less confident about technology. We knew that the DOOM 3 engine would produce the quality of visuals that we wanted, but like most everyone, we wondered if it could be extended into a large outdoor terrain engine. We also needed advanced vehicle physics, streamlined networking, and a ton of other features that are required to build a fast-action, outdoor multiplayer combat game. The id programmers had experimented with some of these elements through a few physics and vehicle test cases during DOOM 3 development, and the knowledge in that R&D was beneficial, but we were clearly facing a challenge.

Terrain Rendering

After nine months of attempts at different technology directions at Splash Damage, we went back to id Software with our hats in our hands. Ironically, it took John Carmack about nine seconds to give us the answer -- why not render the entire terrain with an unbroken unique texture right to the horizon? In addition, we should do away with fogging/far-plane culling so we can actually see this massive texture, right to the horizon. Easy, huh?

In truth, it's an ingenious, but actually pretty straightforward, idea. Somewhat like normal mapping (where a texture that looks super high-poly is applied to a low-polygon model to give the impression of lots of polygons), John Carmack's code applied a highly detailed texture to a comparatively low-polygon terrain model -- the result (after around another year of collaborative development between our two companies) was a terrain rendering system that had lots of incidental benefits for gameplay. We could now derive vehicle traction, particle effects, audio effects and various other gameplay affecting elements from the MegaTexture itself (rather than relying on the underlying polygons). This gave us far greater accuracy for these effects, yet used even less polygons. It's probably not hard to imagine what the next generative step for this technology might be, but more on that some other time.

Vehicle Physics

For most multiplayer games that are developed, a single-player game is used as the base. In doing so, the developer is forced to strip away at the effects and physics present in the single-player game to allow them to send everything across the Internet or a LAN for multiplayer. The decision to make ETQW as a pure multiplayer game from scratch solved this. The terrain rendering, physics and networking were designed from the start for a multiplayer experience.


Instead of having a simple physics box (representing a vehicle) that moved across smooth terrain, we knew we wanted vehicle roles that reinforced the game's character classes, and route types that constrained the types of vehicles that could use them -- we wanted jumps, off-roading and better flying physics. Jan Paul from id Software and Gordon Biggans from Splash Damage worked together, and what we've ended up with is something more akin to a single-player vehicle physics engine, where suspension, propulsion, collisions and feedback are much more realistic. This is key to gameplay, because although we use a traditionally arcade-like control scheme, we want the feedback (and therefore the sense of what you can accomplish in the vehicles) to be realistic.

The proof for me that we'd achieved this came when we first implemented analog controller support. With more accurate analog control over the vehicles (the rate of acceleration, turning or braking) than you can get with a keyboard, I noticed that our physics system felt like a good single-player console racing or adventure game, and nothing like the bad multiplayer vehicle experience I'd grown used to in the past. I'm really pleased with the outcome. As we approach beta we're now focusing on tuning the controls for keyboard and mouse, to simulate the benefits that come from analogue controllers use.

Networking

Not a lot of people know that Wolfenstein: Enemy Territory had a number of networking advances over its predecessor Return to Castle Wolfenstein, but DOOM 3's networking model was completely different, and so these features (such as anti-lag code for better sniping) couldn't be ported over.

Instead, we needed a completely new approach; we wanted everyone on the battlefield to see exactly the same thing, and almost as importantly, we wanted everyone on the battlefield to see as far as possible.

The first new idea was called "Area of Relevance." Somewhat like "Level of Detail" for graphics (or Stephen Hawking's Time Cones -- depending on your preference), it's a set of circles that emanate out from you, and the amount of data that we send back depends on what can actually affect you at a distance. A good example of this is the sniper scope. When you're not using the scope, we send less information about players that are a long way away from you -- for example, the exact direction their head is facing -- but when you zoom in with the scope, we tighten that cone (and area of relevance) and again send this data with more regularity.


Another new feature is split-stream networking. All our data is split into two streams, with things that happen at great regularity that the client can reliably predict (such as certain vehicle physics results) being sent less often, while things that happen less often (such as the firing of an artillery gun) are sent real-time. We halved the bandwidth used with this feature alone.

The Future

We're at that stage now where optimizations for performance will soon be the primary focus of our Programming Team. Lead by our Technical Director Arnout 'RR2DO2' van Meer (who was also Lead Programmer on Wolfenstein: Enemy Territory and our original mod-project Quake 3 Fortress), I'm confident that we're in good hands, and I feel very proud that our company has contributed to a whole new generation of id technology in Enemy Territory: Quake Wars.