Raising the Standard

Well, I suppose this is an issue that all developers deal with continually. Even if the hardware was locked down, competition, consumer expectation and developer ambition would be constantly pushing us to improve standards.

However, on The Getaway, I really think we've have felt this pressure more than most, why?

The above are all general; probably more interesting are the art-specific issues that came up:

As a result we have been constantly re-working and playing catch-up with ourselves. The artists particularly have been working ahead of the tool set and have found themselves needing to re-work and retrofit technologies to their scenes.

The Domino Effect…

When you raise the standard in one area the domino effect is amazing. We quickly got up to speed in making and texturing realistic buildings and cars but this just made our characters stand out as cheap polygonal models. It took us three attempts to find the right process and technology to create characters that sit in the scene well, but it was worth it and we're very pleased with the results. Ultimately, we ended up using a white light scanner to capture our actors. But, of course, you then have some great looking character models that have to animate equally convincingly with all the range and variety of real people and we had to develop a set of in-house tools to add our full facial animation system. This, in turn, puts extra demands on the AI to control all the behavior and systems programming to manage and control all the data, etc, etc…

However, I think it's a mistake to point the finger exclusively at the photo-realistic look of The Getaway. Like all game artists, our job is to create a believable living world. Consumer demand and developer ambition is pushing this towards bigger and more complex interactive environments. I think that this applies equally to real world locations like those in The Getaway and the cartoon and fantasy locations you find in other titles. In my mind, it's more a question of scale and quality and controlling the development process than graphical style.

Looking at Team Soho's other project This Is Football reinforces this point. A simple thing like adding realism by adding a referee had the several consequences. First, it pointed out the fact that there were no linesmen, so they were included. This change made the touchline seem unconvincing and empty. So then police, camera crews and photographers were added, plus a dugout which required a population of substitutes and a manager. They, of course, required animation and AI to control their behavior and make them react to events on the pitch.

Art Education

This was a bit of a surprise. I expected to teach new starters team working, game making skills and technologies specific to The Getaway but never the amount of basic artistic training that was required. Our universities seem to be producing many artists with good software skills but little or no art education. Their technical skills are far better than those of my generation, but their basic observation skills fall way short. People seem surprised that bright dots of color catch the eye. They forget to include doorways and entrances. They forget to check the scale of one model against the next. They forget to take into account the slope of hills and complain when their models don't meet the ground. Since so much of the creativity in The Getaway comes from trying to re-create a real city, these shortfalls became strikingly obvious. What would I do about it in the future? Well, now we operate weekly criticisms of all new artwork, and we have seen standards soar as a result. Additionally, we will be organizing life-drawing classes for all artists from now on.

The Craft of The Getaway

I think I speak for the whole art team when I say we are sick of the assumption that what we do isn't real art and that it's just a simple case of photography…

As far as the leads are concerned, we've had to spend more time dealing with maintaining graphical quality because of this attitude than anything else. It's surprising just how different two artist's work can be, even from pictures taken on the same day with the same camera. Most of the work for The Getaway is in the texture maps, the models are, by-and-large incredibly simple. The real issue is knowing when to stop overworking things, staying focused on which details improve the game overall and which make it look worse.

It takes a new artist a while to get their eye in on The Getaway… it's too easy to assume that you just point the camera and off comes the perfect texture (Hence my gripe about art education). A lot of the art on The Getaway is learning how the eye reads a street scene - what's important and what's not (especially when your traveling at 100mph+). Once they understand that they have to learn to bend reality to fit technical constraints and, most importantly, play as well as possible. The street furniture in The Getaway is a good example--to be honest, none of it is that accurate. In real life, crash barriers, lampposts, traffic lights etc are all found on the best driving line - not much good for game-play. We've had to spend a lot of time teaching people to learn what plays well and how to move all the stuff around to make the driving more fun and challenging without breaking the illusion of reality. The same goes for the game-play. Lets face it, if we modeled London's traffic system exactly all those traffic jams wouldn't exactly make for a good high-speed chase.

In theory, building the sets for The Getaway is incredibly straightforward. We go out in teams of two and shoot the pictures one street at a time. The order of development follows game-play, level order closely so the map grows with the game. Our main enemy is the weather. We can't shoot if it has been raining as all the buildings are wet and stained, we can't shoot in the sunshine because the artists then have to spend forever removing shadows from their textures. Luckily for us, London is a particularly gray and miserable place so the opportunity for a drab overcast day, ideal for photography, is always around the corner. We have only once come close to running out of source pictures and that was a very scary few days as the drive started to run dry. So now, with so many artists requiring material all the time, we now make sure that we always have at least 2 weeks of photography taken in advance.

The essential thing is that each artist learn how to take a good picture, this isn't just a case of getting aligned straight on, there are other useful skills:

We employ the same photography techniques for the interiors as well as exteriors except, of course, we had to gain access to the premises. To do this we used another first for us: a professional location scout from the TV and video business. With their help, we've sought out some truly authentic sleaze and grime. Early in the morning the team descended with cameras, video equipment and lights to shoot every little detail, so (hopefully) we never have to go back, and believe me some of them you really never want to go back to. From that point on it's all down to the artists to make the best of what they have… plus add a bit of style.

So far, we've shot over 8GB of source photographs for texture maps (that's 20,000 separate images), 1GB of reference photos (5,000 pictures), 1.5GB of character scans and 30 hours of digital video. We've worn out two digital cameras with at least 1/3rd of the map left to go. I dread to think how many miles the art team have walked, driven and covered by bus and tube.

Managing the Scale of the Project and Complexity of the Content

Level editor specification

Before even looking at The Getaway design document, studio policy set two key objectives for the level editor:

In addition, experience on Playstation 1 projects had given us a short list of plans and intentions that we wanted to implement in our new level editor:

With the above specification in mind, we then sat down and added the elements that The Getaway design called for. The new Playstation 2 version of the game design called for a single free-roaming cityscape with integration of interior and exterior game-play and environments and seamless movement between the two. There had to be no discernible loading and no breaks or joins in the game-play other than those called for by the story line. Obviously for the programming team, this forced them to design then implement a completely streamed solution for the entire game world (a solution that they are rightly proud of). For content creation this presented a new challenge, without any natural breaks in the play area, there was no easy way to segment the work and keep control over level production.

Active entities such as the cars and characters were quickly and easily extracted out and the work-load scheduled but, for the game to be produced on time, we had to create a working environment where up to 20 artists and 6 designers could work side-by-side on a single level. The design staff had to have access to the artwork for reference purposes and the artists needed the design data. Later in development, it became clear that certain types of data, such as the roads, required joint access and ownership.

The problem was not how to create all the art resources required but how to manage them and build an actual game from all that data without the project spiraling out of control. I believe this issue is already the single most important one that must be confronted as we try and build progressively larger, more complex and involving games.

Finally, we roughed out a workflow plan, one that has held true for the most part:

Choosing an Art Package

After considering our options, we decided to use Alias Wavefront's Maya as our 3D package for Playstation 2 development. This was largely because of the following reasons -

Organizing Our Data

Our first decision felt pretty much made for us - we were going to be handling so much artwork we knew we needed a central database to store all the inter-related information about our content. A suit of tools was specified to allow Maya, the project build process and debugging tools to communicate with the database.

As we were working with a real world location and live maps provided by the Ordinance Survey (the national British surveying body) it seemed natural to divide the work up into units set by those maps. This gave us our starting point, cutting the map up 500mx500m squares - the grid cells (a mistake as it turned out).

Taking our workflow plan as our base, we decided to break our content down into types, grouped by task, each was assigned to a layer and saved in a separate Maya scene. Initially the categories were:

	An exploded view of the various layers.

The layering system was always left open ended so that new layers could easily be added as the project progressed. As it turned out, we moved roads into a separate layer and a new lightweight layer was added for simple, frequently edited objects such as replay cameras. Mission specific layers were finally added once a large playable area was available.

Checking In & Out

The first database to be implemented was the one that controlled the creation of content. This handled the status of all the grids cells in the game. A suit of Maya tools replaces file open and file save commands and communicates with the grid control database to maintain source control.

The more difficult part of the problem came from the specification that we needed to work with many layers while maintaining their individual integrity. Maya itself has a single scene model in direct contradiction to what we required. Not only that, but we wanted a dynamic workspace where grid cells and layer could be added and subtracted as required, either active data or as read-only.

I am very pleased to say that, by-and-large, we have what we set out to create:

________________________________________________________