Most Entertaining Lecture: Probably Splash Damage's post mortem of Wolfenstein: Enemy Territory, as they regaled us with tales of office nerf gun fights and unicycle races.
Most Disappointing Lecture: The presentation on Game Assets in Rome: Total War. Going in with high expectations, it turned out that neither of the two advertised speakers were able to make
it, so they'd drafted in a substitute who didn't really know enough about it to give a full presentation.
Most Impossible To Understand Lecture: I made a brief attempt to watch ATI's presentation on the making of Ruby, the computer generated female star of ATI's demos and advertising campaign.
Unfortunately, I was stuck at the back, peering around the corner through several people's heads at the screen, and completely unable to hear most of what the speaker was saying due to the level of
noise on the show floor.
Best Booth: Lipsync Creative, for the simple reason that they had a couple of lovely girls giving free massages all day – greatly appreciated after sitting in the GDCE seminar rooms
Most Disappointing Booth: I'd have to say the Relic Entertainment booth. Given the enormous amount of interest in Relic's games, both old and new, they could have put on a bit more of a
show, but as it was, the booth was tiny, mostly unoccupied, and empty apart from a battered old Homeworld box and a few job adverts. That said, they were probably the biggest game developer that even
HAD a booth, and you could at least play Dawn of War on one of the PC stations elsewhere on the show floor, so I can't be too harsh on them.
Most Bored Exhibitor: The poor chap in the Shmangle booth who seemed to spend his entire time playing around on his laptop, with almost no-one seeming to show any interest in testing out
their comfy beanbags.
Most Non-Existent Booth: Too many candidates to pick a name!
GDCE Day 1: XNA Tutorial day
Ever since Microsoft announced the development of the XNA technology, there have been rumours flying around the net about exactly what it means for game development. The first day of GDCE was
supposedly devoted to a series of lectures on XNA technology and about where Microsoft is going with XNA and DirectX, and their Windows and XBox platforms.
Essentially, XNA aims to do away with all the tedious platform specific boilerplate code that gets reinvented every game by providing a basic game framework that does it all for you. There are a
number of advantages to this, for example the game's interaction with the OS can be standardized and thoroughly bug tested. Alt Tabbing in Windows for example, will be handled silently within this
framework, resulting in less work for the developer and fewer bugs in the game. (No more crashing to the desktop when you accidentally hit the windows key…) This exposes a common interface to
the developers, meaning that a porting from PC to XBox or vice versa should be an even simpler affair.
Currently, the only platforms Microsoft are aiming to develop these frameworks for are Windows, XBox, and Mobile platforms. However, they have no intention of stopping third party developers from
developing frameworks for additional platforms such as the Sony Playstation 2 and Nintendo Gamecube consoles, which would further increase the portability of games developed with this technology.
The first step in Microsoft's convergence towards the XNA platform is to port some of the powerful tools developed for the XBox to Windows, and much of the event was devoted to discussing these
tools. XBox programmers may want to skip a few paragraphs, as they'll be familiar with technologies such as PIX and XACT already.
The first tool on the agenda was XACT. (XBox Audio Creation Tool) XBox developers will already be familiar with this technology, but as part of Microsoft's convergence towards XNA, this tool is
being ported to Windows. Essentially, this tool allows sound engineers to design parameterised sound patterns, which will cross fade, mix and match sound effects automatically based on a few
variables. A racing game was used to demonstrate the power of this tool. A different engine noise was used for each gear, and parameterised so that simply by changing a single variable representing
the rpm of the engine, the sound effect would change in pitch in a controlled manner. Then, at a certain number of revs, automatically switch to the next gear, and so on. All this would be set up by
the sound engineer, and could be tested without the need for a working game engine. All the programmer needs to worry about is passing the 'revs per minute' variable to the sound engine. The system
is highly configurable, and can cope with a wide number of effects, any or all of which can be parameterised or randomised. The result is that you can create interesting, non-repetitive sound effects
or music with only a handful of actual sound files.
Next up was PIX, the graphics pipeline profiling tool. Again, this tool is already available for the XBox, but is now being ported to Windows in order to help developers get the most out of their
graphics engines. This tool allows you to set a wide range of counters, covering DX calls, and maybe even driver specific calls if you have a suitable plugin to do so. The logged information can be
inspected in great detail, allowing you to view a series of frames, a single frame in detail, or even individual calls within a frame. It also allows you to view a great deal of information about the
rendered image, showing overdraw, z buffer state, or even the complete history of a given pixel. This tool should make it possible to efficiently optimise the graphics pipeline, rather than relying
on guesswork as to where the problems lie.
Unfortunately, the Windows driver model makes a full port of PIX impossible, so for the time being at least, the Windows port will only have a subset of the functionality of the XBox version.
However with the revisions to the driver model proposed for Longhorn, a more complete version should become possible.
Common Preview Pipeline
The common preview pipeline is another tool aimed at content creation. As the use of shaders increases in games, artists face the problem of not being able to see what their creations will look
like in the game once the shaders have been applied. Furthermore, they are often reliant on the programmers to tweak the shaders, which slows down their productivity and makes it harder to get the
The common preview pipeline consists is a set of plugins for the common tools such as Maya and 3DSMax, which puts one of the viewports into a special preview mode, which allows the artists to view
the effects of shaders in real time. Perhaps most importantly of all, the shaders can contain embedded parameterisation (known as 'Annotations') information that can be parsed by the plugin and shows
up as a series of UI controls. These controls allow the artist to tweak various elements of the shader, such as colour, or frequency etc, within the constraints set by the shader programmer.
Several of the lectures dealt with various enhancements that have been made to the HLSL in the latest version of DirectX. For example, the addition of Annotations and Semantics, which are designed
to give hints to the application about how an HLSL variable should be used. For example, Semantics allow you to denote unambiguously that a particular variable should be filled with the world
transformation matrix, or perhaps a random number, or the elapsed time. Annotations allow you to define UI information about a variable, so that variable can be tweaked by an application such as the
Common Preview Pipeline plugin mentioned earlier. Other tricks included the use of preshaders to drastically reduce the amount of code that needs to be executed in a shader, by performing all the set
up and preparation code in the preshader.
The Future of DirectX
The day closed with a session on the direction Microsoft is planning to take with the DirectX API and Windows.
It seems that the various components of DirectX are set to go their separate ways, as the new XNA tools supersede them. DirectPlay is unlikely to change from its current incarnation, but the
addition of the XBox Live tools will more or less replace it. DirectSound and DirectMusic will be effectively replaced by the XACT interface. More changes are in store for Direct3D, which will be
replaced by WGF (Windows Graphics Foundation) and will be upgraded on a regular basis so as to remain in step with technology. This splitting up of DirectX makes a certain amount of sense –
some technologies change more frequently than others, and it makes little sense to download a huge SDK containing everything just because one element has changed.
WGF should see the end of much of the fixed function pipeline – vertex lighting, fog, alpha testing, FVFs, triangle fans and point sprites are all being chopped. Vertex and Pixel shaders
will become more closely connected in the Common Shader Core. If Microsoft have their way, it will also bring the end of Device Caps. IHVs will be more or less forced to meet a minimum set of
requirements for WGF compliance. This is a rather contentious issue of course – the IHVs often compete with each other on features as well as raw speed. This could mean that while WGF should
give developers a good, powerful and importantly, consistent set of features to work with, developers who are prepared to go the extra mile with a more flexible API may be able to take advantage of
extra features that different cards may provide.
Another key feature of WGF is stability. With the introduction of Longhorn, the whole desktop will be hardware accelerated, making it essential that the graphics pipeline is stable. The new driver
architecture for Longhorn will help in this regard, by bringing some of the driver processing out of the kernel and into user mode, making it easier to recover from horrible bugs. Microsoft are
hoping to completely do away with BSODs caused by driver problems, instead handling such errors in a rather more graceful manner.
New features include improved state management, high-definition rendering formats e.g for high dynamic range lighting, normal map compression and the addition of texture compare filters. They are
also planning to add a new element to the graphics pipeline for processing more complex geometry, which may in turn lead to the use of the GPU for non-traditional tasks, such as collision detection
In conclusion, Microsoft stressed very strongly that the XNA platform and related tools are aimed entirely at developers. They want to deliver powerful tools that will make development more
efficient without compromising quality or creativity. It's very important to them that these tools offer all the features that developers want, and therefore they want as much feedback from
developers as they can get. They emphasised the importance of signing up to the beta programs and getting as many developers as possible to make sure that they can meet our requirements.
GDCE Day 2: Conference Day 1
Keynote Session: Electronic Arts
The opening session on Wednesday was a talk by Rory Armes from EA's European studio, rather than Bruce McMillan as originally advertised. However, the session was entertaining as he claimed he was
a 'Canadian Cattle Rancher' and an 'Independent Developer' despite working directly for the largest game publishing company in the world...
He started off with the prediction that the Europe rather than the US would be the driving force behind the next generation of games. While there may have been an element of audience ego stroking
here, EA certainly seems to be prepared to put it's money where it's mouth is. EA are apparently planning to recruit a large number of new developers, increasing the size and number of their own
studios as well as the number of developers under the EA Partners program.
EA also seem very keen developing their own IP rather than licenses. Armes suggested that by next year, the only externally owned IP EA would be working with would be the Harry Potter license. He
also mentioned a little sorely the risks of licensed tie ins, using the failure of Catwoman as an example. As he said, "If the movie sucks, no one cares about the game".
He went on to cast a critical eye over some of EA's previous games as he ran through his list of 'Six things I know about Game Development'. These were:
1. Never underestimate the universal joy of blowing stuff up
It may sound rather shallow, but there's a certain element of truth to it. There will always be a place for simple mindless fun in games. This item also provided an opportunity to show off a
trailer for the forthcoming Burnout 3 game, a racing game packed with things to crash into and blow up.
2. Nobody likes getting their ass kicked
Armes briefly mentioned a selection of games that fell foul of being too hard or too impenetrable, as well as some that were just too easy. He also cited Burnout 3 as an example of a game where
the difficulty of the play is not too important – even if you're hopeless at it, you can still have fun. His overall point was that the designer's job is not to beat the player, but to ensure
that he enjoys the game.
3. The first three minutes are critical
The beginning of the game really does count. Armes mentioned the tendency of designers to save the best stuff for last – but in reality, perhaps it would be better at the beginning, where
more people will see it?
4. How many people are working on cool stuff?
Armes broke down the importance of various elements as follows: 60% gameplay, 20% presentation, 15% depth, and finally 5% cool stuff – yet all too often developers spend a disproportionate
amount of resources developing extra features that serve little purpose.
5. Never say Never
This provided an opportunity to show off another trailer, this time for Def Jam, a beat-em-up style game that will end EA's moratorium on mature rated games.
6. Stop worrying about the business and get back to making great games
This is perhaps easier said than done for smaller developers, but ultimately his point was that developers should focus at what they're best at, and let the games sell themselves.
Keynote Session: When the Barriers come Tumbling Down
Hosted by Tim Christian of Media Forensics, this session explored the future of game development. Peter Molyneux of Lionhead and Karl Jeffery of Climax represented the developers, while Rory Armes
(EA) filled in for the absent Mike Gamble (THQ) on behalf of the big publishers. (despite his continued objections that he's an independent developer) Finally Seamus Blackley of CAA was available his
input on the industry from a Hollywood perspective.
A core theme of the session was comparing the game industry to the movie industry. The movie industry is well known for it's profitability and success – whereas the gaming industry, although
larger, is struggling somewhat, with many developers and publishers going out of business. Seamus' job is to use his experience in Hollywood to help the game industry mature into a more stable and
lucrative state. He compared the talent in the game industry favourably to that in Hollywood, noting that "The guys in Hollywood spend two or three years developing a couple of hours of storyline;
you guys spend the same amount of time developing forty hours of storyline".
Blackley went on to talk about the ability of people in the industry to recognize a good idea when they see it, and he felt that this ability was lacking in the game industry. "[Hollywood
producers] can take a screenplay and tell whether or not some writer is awful or an idiot or has some sort of bizarre taste for gophers or something… And I can tell you quite honestly that with
very, very few exceptions, it's hard to find anyone like that today in a position of power who has the ability to green light something." Jeffery noted the increasing need for developers to have a
working prototype or some work already complete on the project to be able to sell the game to a publisher.
Molyneux also mentioned the importance of hanging on to your own IP, and the value of sequels. While he pointed out that several years ago, you'd be embarrassed to write a sequel, the value of
creating a strong franchise is enormous, to both the developer and the publisher.
The need to streamline development was emphasised, in order to make maximum use of the individual developers on the project. It was noted that while a movie's credits may contain a long list of
names, not all those people would necessarily be working on the project at the same time – some would be involved with the initial stages, and then move on to another project once the next
stage of the project begins. Development times are also an ever-present problem, and Molyneux made it known that even well established developers such as Lionhead need to work on this problem.
Single Platform vs. Multi-Platform Development
Unfortunately I only caught the end of this seminar, again in the discussion panel format, but this time with Olivier Goguel of Argonaut, Dave Ranyard of SCEE, and David Braben of Frontier
Development. However, a small crowd gathered around David Braben at the end of the seminar, so I joined in to try and get an idea of what had gone on in the rest of the session.
The key issue in the talk was not so much related to platform specific programming, but the issue of resource scalability; Obviously different platforms have different capabilities, and the
objective is to ensure that the sound effects, models and textures etc. are the best they can be on any given platform. Frontier seems to have developed a good solution to this problem in the use of
their own set of tools for resource management, as well as a 'virtual OS' that can be used to test out behaviour in a completely platform independent environment. Although these tools are currently
proprietary, Braben suggested that he might consider licensing some of these tools to other developers.
Of course, we couldn't let Braben go without someone asking about a new Elite game, and Braben seemed more than happy to confirm that it's very much in the pipeline…
Graphics For Dynamic Game Worlds
Presented by David Dow of the Lionhead Satellite company Intrepid Games, this session discussed how they approached the task of creating a highly dynamic game world in the forthcoming game BC.
Unfortunately Dow seemed a little uncomfortable giving the presentation, and it came across as a bit unrehearsed and stilted. The demo itself was certainly impressive though, showing off the
stylised prehistoric terrain of the game world.
Intrepid have taken a slightly different approach to texturing in BC. Artists often use highlights and shadows in the diffuse texture maps to make a model look more detailed. However, BC's
day/night cycle means that the direction and strength of the light is not fixed, so adding detail in this manner would simply look odd. Instead, Intrepid have opted for very simple diffuse texture
maps, and used geometry for detail where possible, and bump mapping almost everywhere else. This means that the models look right regardless of the position of the sun, and gives the engine a very
solid look and feel that works very well with the prehistoric styling of the terrain and models.
Fable: The Art of Combat
Joss Moore and Dean Finnegan of Big Blue Box (Another of Lionhead's Satellite companies) presented the final session of the day, discussing the development of Fable's combat system. The talk
concentrated on solving the problem of animating combat without harming gameplay.
Combat is an important element of many RPG's, and Fable it seems is no exception. However, Big Blue Box have attempted to find a compromise between the simplicity and accessibility of 'point and
click' style combat and a more complex interactive system more like those commonly used in beat-em-up style games. They key problem they faced was animating the combat smoothly without making it feel
unresponsive – once the initial set of animations were added, they found that triggering an attack left the player out of control while the animation played out.
The problem was solved by storing notes in the animation files that indicate the start and end of valid interruption points. These are parsed by the game engine and allow it to prevent the player
from initiating a new action until the next interruption point is met. These interruption points are chosen by the animators to ensure that the flow to the next move is seamless. This mechanism
proved essential to the gameplay, as it allowed a greater level of depth to be added to combat, introducing parrying moves and the ability to change targets mid combat when engaging multiple
GDCE Day 3: Conference Day 2
Keynote Panel: Playing All Platforms – Convergent games
Friday got off to a rather frustrating start, as I got caught in traffic and missed the fast train into London and as a result, took an extra half an hour to get in, causing me to miss the first
part of this talk. Chaired by Ian Livingstone of Eidos, the panel consisted of Mickey Kalifa of Playjam – OpenTV, Rio Caraeff of Sony Pictures Mobile, and Heikki Aura from Nokia.
Arriving late, I only caught Mickey Kalifa's presentation about the OpenTV platform. This particular platform has proven surprisingly lucrative in the Europe, and is soon to open in the US. Played
through the television through Sky, this platform works on a pay per play basis. The games themselves are relatively simple – platformers and puzzle games predominantly, and the games are
changed every six weeks to keep the players interested. While the shelf life of these games is very short, so is the development time, no more than six to eight weeks in total.
State of the Art in AI and Design
Chaired by Demis Hassabis of Elixir, this presentation took the format of a number of case studies, covering AI solutions for various different platforms. First up was Rob Davis of Solaris Media,
the developers of the educational strategy game Battlefield Academy, developed for the BBC.
Battlefield Academy is a turn based strategy game developed with Flash. The limitations of the Flash platform are fairly obvious: it's an interpreted language, and it's delivered over the web,
meaning speed and size are both limited.
In order to make the most of the available CPU resources for the AI, Solaris Media kept the graphics and animations down to a bare minimum. The performance restraints were so tight that they could
only implement a very simple A* for pathfinding. In order to reduce the search space they kept the visibility for each unit low and carefully designed each map to prevent too many pathfinding
The developers made good use of the map file for embedded AI hints, such as the locations of nearby objectives, which saves CPU cycles while enabling units to respond sensibly to nearby threats
and goals. They also managed to squeeze in a very simple form of influence mapping, which uses a single pass to get a rough idea of the shape of the battlefield and the position of the front
The Battlefield Academy game is available online from here:
The next speaker was Pierre Pontevia of Kynogon, a middleware developer working on AI for integration with Renderware engines.
AI can be broken down into three basic steps: Perception, Decision, and Action. Perception here is key, since without suitable information about the world, the AI cannot make good decisions.
Traditionally, AI's have relied on simple 'workarounds' to perception and decision-making, such as ray casting techniques and scripting. As game environments get larger and more sophisticated these
methods will prove to be inadequate.
Pontevia demonstrated their dynamic 3D topology analysis tools, which generate a model of the game world that the AI system can use to determine areas of interest. They showed off some impressive
demos, such as the 'Bodyguard' demo – three body guards surround the player and reposition themselves intelligently to cover areas from which a threat might present itself. More information and
demos are available from Kynogon's website: http://www.kynogon.com/
The final talk was presented by Hendrik Heimer of Navus, a middleware company specializing in MMORPG AI. Heimer started by highlighting the advantages and disadvantages of the scripts and FSMs
used in many current games. On the plus side, they are relatively easy to implement, and give the designers a high degree of control over the NPCs and thus, by extension, the storyline. The minuses
are rather obvious however; NPCs exhibit robotic and uninteresting behaviour, poor or non-existent interaction both with the player and with each other, and they are weak outside a manually tuned
Heimer identified the requirements of the next generation AI as being: Rich communication amongst NPCs and between NPCs and players, Machine learning, and 'freedom of mind' for NPCs – that
is, removing as many artificial limitations from their behaviour as possible. More information about their Multiagent system and MMORPG AI backbone can be found at their website,
The Easy Route To Console Online
Presented by Shawn Hargreaves of Climax, this session suggested some tips and tricks to getting a good multiplayer experience with a console game.
Hargreaves identified fan communities as being an invaluable resource – given enough tools these communities will happily develop new game modes and features that you didn't have time to
develop yourself – or else were unable to develop due to licensing issues. As an example of this was the 'Demolition Darby' game mode of Moto Cross, which would never have been allowed by the
license, and yet is one of the most popular game modes online.
He also suggested of carefully tailoring your scoreboards to a wide range of players. Rather than have a single 'top ten' or anything like that, have a series of tables so that players of all
levels can feel they have accomplished something. Also be wary that cheating can easily ruin a basic high score table. He mentioned a 'slipstream pausing' technique used in Moto Cross, which is
rather tedious to pull off, but gives you ridiculously short lap times that can only be beaten by someone else using the same cheat. As a result, making the top ten is no longer an exciting
challenge, but a very boring exercise.
Another item he felt was of key importance to online gaming was the user interface. All too often the user interface for setting up multiplayer games is farmed out to the least experienced
programmer, and as a result, it is often full of bugs and poorly designed.
Mods, Mission Packs, Doom 3 and Beyond
Perhaps the most entertaining session of the day was given by Splash Damage, the developers of the Wolfenstein: Enemy Territory expansion pack. In this talk they gave a post-mortem of the
production of W:ET, and talked about how they went from an amateur mod development team and evolved it into an award winning development company.
What went Right:
Plenty of reference material: A trip to a war museum gave the developers a chance to actually play with the weapons used in the game, allowing them to make them highly realistic, without needing
to create large amounts of concept art or making stuff up.
The Interface: Although they admitted that it's rather ugly and complicated, the Splash Damage felt that the interface of the game really worked – by having everything on one page players
can set up and configure their character very quickly in game, without the need to navigate lots of menus.
The Engine: The Quake 3 engine is well known, and there are plenty of resources available for developing mods with it. This made the learning curve much easier, and meant that the team had a solid
platform to work with.
Level Design: Each map in W:ET is a team effort, rather than the work of one developer. Each aspect of map design is given to the team member best suited for that particular work, ensuring that
each map is very high quality. They also managed to avoid wasting too much time on dud maps – they work with a two pass map creation process – the first pass consists of the basic
geometry, and playing it to make sure it's actually fun, the second pass consists of making it look nice.
The Game Design Document: The game design document was well maintained throughout the project, undergoing fifty-eight revisions over the course of development. Splash Damage shied away from
posting it on the intranet in order to allow everyone on the team to modify it, preferring instead to let the designers come up with the base ideas and hold regular team meetings to get feedback.
Throwing Out Rubbish: Every so often, something included in the game would turn out to be rubbish. Splash Damage were strict on throwing this stuff out, even if it meant missing a milestone. This
didn't always go down too well with the publisher, of course, and the team stressed the value of having a good relationship with a heavyweight developer such as Id – if Id agreed that a feature
was no good and should be thrown out, then Activision would defer to their judgement.
What Went Wrong
Not Enough Artists: With only two artists on their team, Splash Damage had a hard time generating the amount of content required for the game, and with their next project using the Doom3 engine,
this is likely to be even more problematic due to the number and quality of the textures needed to show off the engine at it's best.
The HUD is 'Pants': Splash Damage admitted that the head up display in Enemy Territory is utterly horrible, with nearly every corner of the screen being used for some bit of pop out information
– half of which the players don't even know about.
ECTS was rather disappointing this year, with relatively little to do or see. The world Cyber Games had the biggest and most impressive display, as they held the British playoffs for the finals
held in Seoul in October.
Sony were most notable by their complete absence, having apparently abandoned ECTS completely in favour of EGN at the other side of London. There were a number of game stations where you could
play various PC, Gamecube and XBox games, although actually getting a machine to yourself wasn't all that easy.
VIA and S3 shared a sizeable booth where visitors could challenge the professional gamer 'fatal1ty' to an Unreal Tournament Deathmatch. They were offering prizes to anyone who could frag him just
once, but it looked as though they were relatively safe – when I last looked the best score anyone had managed was twelve-nil to fatal1ty.
Discreet gave regular demonstrations of the latest incarnation of 3DStudio Max at their booth. I caught part of one demonstration during which they showed off some of the useful tools, such as the
turbo smoothing function and the painting tools that allow you to sculpt your model as though it were a lump of clay.
A number of booths were dedicated to weird and wonderful control devices, such as the 'action stick'. This device picks up your movements and translates them into punches and kicks in a beat-em-up
game. I'm not sure how effective they were, but it was certainly entertaining watching people try and play with them. Another such device was the 'playseat', a chair with built in pedals and steering
wheel ideal for racing games, although perhaps a little bulky to have sitting around in your living room.
"http://images.gamedev.net/columns/events/gdce2004/ects_playseat.jpg" width="500" height="279">
I spent a fair amount of time chatting with the guys at the Dare To Be Digital booth. Dare to Be Digital is a game development competition for Scottish students, although it is looking to expand
internationally. The object of the competition is to develop a working prototype of a game or education product within ten weeks. There are several prizes available, such as the Commercial Potential
prize and the Innovation prize, but it isn't all about winning – all the entrants receive invaluable experience, get something impressive to put in their portfolio for when they apply for a job
in the industry.
A company called 'Moqon' were demonstrating their physics engine, and were kind enough to give me a demo CD. It's certainly quite fun to play with some of the demos, and this product might make a
useful, cheaper alternative to better known systems such as Havok. Also exhibiting were the developers of the Gryps engine, a complete game engine package with highly flexible licensing tailored to
the needs of each client.
And now for the bit everyone's been waiting for – the booth babes. Unfortunately, there was a distinct lack of booth babes at ECTS this year. I hear there were a couple of girls at the VIA
booth, but they managed to elude my camera. So by way of an alternative, here's a picture of a kitten with a box on its head.