Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
London Wasn't Built in a Day: Content Acquisition for Levels in The Getaway
If you are expecting some technical bloke from Sony to give you the inside track on optimizing your code for the Playstation 2, then you're in the wrong place. If you think that I'm going reveal novel modeling and texturing techniques that make our game look fantastic then you're in the wrong place too because we don't have any. What you see on screen in The Getaway comes from simple hard work and a direct refusal to accept the reality of our situation and be beaten by the scale of the game we've set out to make. Simply put, this artice is about managing the creation of a mass content game. In the case of The Getaway that content is the city of London, its locations and inhabitants, but the same principles apply to any title with a huge amount of graphical resources and large number of art and design staff.
43 Min Read
Abstract
This presentation focuses on the two interwoven aspects of The Getaway that have forced us to review our content production methods. Both are direct result of our ambition to build one of the worlds most famous and complex cities while establishing Team Soho as the producers of truly next generation story based, action titles. Inevitably, these concerns will become major issues for all teams as they struggle to meet increased consumer appetites and expectations for larger and more sophisticated games.
Raising the standard.
We are particularly proud of the way that The Getaway looks and the level of detail and realism that we are achieving. To get to this stage, we have had to repeatedly explore new techniques to raise the quality of our exterior streets, cars, interior locations and characters. In this discussion, rather than look at the specific techniques themselves, I will focus on the changes we have made to our production processes and tools to help reinforce and control the rapid rate of change.Managing the sheer scale of the project and the complexity of the content.
In order to re-produce such a huge play area to these high, self imposed standards, we have had to completely overhaul our tools from the original Playstation 1 set. At the same time, the specification for all new tools insisted that they could be re-used for other, as yet undecided games. The second part of this presentation looks at what we set out to create, the problems we encountered along the way and what the team have ended up working with in order to get the game out in time.
Introduction & a Little Bit of History…
I'm not going to apologize for this - if you are expecting some technical bloke from Sony to give you the inside track on optimizing your code for the Playstation 2, then you're in the wrong place. If you think that I'm going reveal novel modeling and texturing techniques that make our game look fantastic then you're in the wrong place too because we don't have any. What you see on screen comes from simple hard work and a direct refusal to accept the reality of our situation and be beaten by the scale of the game we've set out to make.
Simply put, this presentation is about managing the creation of a mass content game. In the case of The Getaway that content is the city of London, its locations and inhabitants, but the same principles apply to any title with a huge amount of graphical resources and large number of art and design staff. I will be discussing how we have gone about updating our production processes to cope with the demands of The Getaway while scaling up a European studio to produce blockbusters.
However, before we go any further, you may be wondering…
What Exactly is "The Getaway?"
For those of you who don't already know, here's the answer…
| ||
The Getaway. |
The Getaway is a crime-em-up. Set in contemporary London's criminal underworld, the story revolves around inter-gang rivalry and warfare and the efforts of the Metropolitan Police to contain the violence while fighting internal corruption.
From the player's point of view, they take the role of an east-end gangster, propelled by the events unfolding around him through a third-person action adventure and driving game.
Gangsters, cars, and guns, what more could one ask for…
The action is split roughly as follows:
60% urban driving through London's traffic filled streets
40% on-foot shootouts set in London's sleaziest locations.
The Getaway is the most ambitious title ever undertaken by Team Soho. It has the largest development team of all our internal studios (currently standing at 50) and the highest production values. The action is played out against a re-creation of the city of London, with professionally scouted interior locations and a cast of 30 professional actors.
The Getaway is under construction by people who live and work in London, it's our city and we hope that it shows. To be honest that's about as far as we take pride in the job-as far as I know, none of us are actual criminals and some us can't even drive. Admittedly we only have one genuine born and bred Londoner but who's counting anyway…
From Playstation 1 to Playstation 2
The Getaway started life as an intention to build on the work done on the studio's driving games Porsche Challenge and Rapid Racer. To produce a Playstation 1 title that would expand the racing genre. Many different ideas were explored before a crime-based theme was settled upon and a prototype developed. Proof of concept for this game came at an awkward time for the studio-just as the first Playstation 2 development kits were about to ship. After considering the progress of the Playstation 2, the interest generated by games such as Reflections's Driver and the enthusiasm of the team to continue with this genre, it was decided to seize the opportunities presented by the new platform and make The Getaway Team Soho's flagship Playstation 2 project.
To justify this re-direction, some radical changes were made to the game design -
On foot gameplay added -
Externally - the player can now get out of the car at any time and progress on foot if they wish. They can hijack any vehicle found on the streets to aid them and finding and stealing the correct car for the job has become a key game mechanism.
Internally - the most substantial change to the design, the player now not only drives between key locations but also participates in action when they arrive. Eighteen interior levels are being constructed - several designed to be re-visited during the course of the story.
A whole new story -
The leading player is now a retired bank robber, Mark Hammond, manipulated by his old rival, Charlie Jolson, into igniting confrontation between London's criminal gangs. Jolson's aim is to weaken his rivals so that he they can step in and clean up once the dust settles. More by chance than design, Hammond hitches up with the disgraced cop, Frank Carter, who is after Jolson for his own, less than pure, reasons. On completing the game as Hammond, the game can be re-played, this time as the bent cop Carter. Only then is the true picture revealed and all loose ends tied up. The story is now the focus of the game, the action being driven by the two interwoven narrative strands rather than a mission based structure.Just one massive play area: the city of London -
In the Playstation 1 version, London was one of five driving locations. For the Playstation 2 version, it has become the focus of all attention with rival gangs fighting it out for the control of their home territory. We have set out to build London as we know it, not just the standard tourist locations. Consequently, the play area has become a vastly expanded London map; ten times the size of the original Playstation 1 version. London is an incredibly complicated city and I think you get a real feel for the place you get when you play the game, the good and the bad, the new and the old, the beautiful and the ugly and the expensive and the sleazy. We are particularly proud of the lesser known areas included in the map, like the run down areas south of the river where a lot of the dodgy deals go down. I really don't think there is another game out there which really captures a place in quite the same way as The Getaway: from Buckingham Palace to Council Flats in Lambeth (what you call "projects" in the US, I believe), from Hyde Park to derelict waste land off Old Street, the whole city is represented.
So just how much work is there in recreating London?
Getting across the size of the exterior play area isn't easy unless you know London well. I'm going to assume that most of the audience have never been to London, let alone explored it in the detail The Getaway team has. In an attempt to get the scale of the task across, I'll describe the volume of work in several different ways.
| ||
A map of the area covered in The Getaway. |
Graphically - the above map shows all of the roads included in the game, each square is a development grid cell and measures 250m x 250m.
By Distance - over 110Km (70 miles) of drivable roads have been accurately recreated from Ordinance Survey map data.
By Area - the free roaming map is spread over 50 square kilometers (20 square miles) or 5000 hectares (12350 acres) of central London.
By Time - breaking all speed limits and running every red light it takes over 15minutes to travel between the furthest points east and west.
By Resource - the cityscape alone will take 10 full time artists over 2 years to build, 50% more than the total number of artists on the whole Playstation 1 version.
By Geography - from the far edge of Hyde Park in the west to Shoreditch & Bethnal Green in the east. From the Angel in the north to Lambeth Bridge in the South.
For the locals - and finally, for any Londoners out there, the map covers an area close to what you get when you buy a "Zone 1" travel card.
I hope that one of the above mindless statistics will convince you of the ambitious scale of The Getaway.
The Team
Perhaps the best way to understand the growth of the project is to look at the way the team makeup has changed:
| PROGRAMMING | ART | DESIGN |
Prototype | William Burdon - lead | Ravinder Ruprai - lead | Stuart Harvey - mapper |
Playstation 1 | (same) | Rob Jones - (artist interiors) | Chun Wah Kong - lead |
Playstation 2 | Joe Kilner - animation | Sam Coates - lead (production) | Simon Wood - production designer |
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?
New hardware - same for everyone I guess, a time to stop and double check what you are doing (if you're lucky).
We are Sony after all - as internal development our remit is not just to create profitable games but to produce flagship titles that push the chosen genre, demonstrate what Playstation hardware is capable of and expand the market.
New tools - moving The Getaway to Playstation 2 gave us the perfect opportunity to review our entire tool set, make a break from the past and move forwards. In addition, and due to the scale of the game, we knew that we could bring a whole new generation of artists and programmers into the studio with fresh new ideas and expectations.
A new studio manager and a new way of doing things - if nothing else, a new climate of openness has allowed us to promote our own titles from a long way out, giving us direct access to the consumer rather than keeping things under wraps until the very last minute. The Getaway is the first title that Team Soho has been able to promote throughout its development and expose to the world's development communities and press.
Internal politics and a new studio identity - I think everyone is well aware of the rationalization of the Pygnosis studios and their integration into Internal Development proper. As part of this, a distinctive Team Soho identity has come to the fore with a desire to make distinctly London based product, The Getaway is the first product we have that taps directly into that new identity.
European Pride - This could be the deciding factor - for the senior members of the studio The Getaway is our bid to get to make blockbuster titles. Internally it is viewed very much our passport project, the one which will allow us to set our own agenda and prove that we can compete with the largest teams in the world making distinctly European games with world wide appeal.
The above are all general; probably more interesting are the art-specific issues that came up:
Fast Track development - because of its unusual birth, The Getaway already had a substantial team on day one. Not surprisingly, this caused some teething problems.
The Domino effect - raising the quality of the exterior was relatively easy, dealing with the consequences wasn't.
Art Education - well, without wanting to sound too disappointed with our new staff, (because I'm not) what a surprise was waiting here…
The Craft of The Getaway - "So you just map photographs onto buildings and that's it, isn't it?" Put simply - don't be stupid.
Fast Track Development (or "Sink or Swim," if You Prefer…)
Because of the way The Getaway Playstation 2 came into existence, it largely by-passed the usual R&D/design/prototype/green light/recruitment/development cycle. I think it would be true to say that having a working Playstation 1 title lured the team into a false sense of security.
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:
Don't forget your reference. When you return to the office you will not remember exactly how all those pictures fit together to make up a building so take a reference shot, or better still, some video.
Don't forget to take more than you need. Extra shots will always come in handy, even if you don't use them someone else might.
Don't worry about being laughed at. Every artist on The Getaway needs to get used to being pointed at while photographing the City. While all the rest of the tourists snap the horse-guards parade, you will be taking pictures of walls, the floor, etc.
Try to avoid getting cars, people and your own reflection in the image. However inflated the artist's ego we don't want to see the photographer in the final texture.
Stay out of trouble. The Getaway is set in some of the worst parts of the city, the more authentic and sleazy the area the more careful you need to be, especially when you get out the camera. So far, somehow we've just about managed to avoid any real trouble although we've had a few very near misses. We've been shouted at by sleazy Soho shop owners. Told off by Ferrari drivers. Chased away while photographing sex shops. Threatened by security guards and bouncers. Almost mugged for the cameras twice. Not to mention the first time a work experience kid went out to take photographs alone and was confronted by a Soho madam who offered to take the camera in exchange for three girls. I believe the sales pitch was "one white, one black and one Chinese… and they're all clean." Welcome to The Getaway.
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:
The editor must be constructed within an off the shelf 3D art package. The thinking behind this decision was:
All base functionality such as camera manipulation, polygon and spline creation and editing tools, animation and lighting would be handled and, more importantly, supported by a third party. This would free our internal tools programmers to concentrate on what we know best, game content creation and management.
The distinction between artist and designer would remain as flexible as possible allowing tasks to be transferred as required throughout development.
Only one set of data management tools and interfaces would need to be written.
We knew in advance that we would be recruiting wildly-including many new staff with no games experience. Building our editor within a recognized art package allowed us to assume pre-existing software knowledge and bring new staff into the project more quickly, while letting us concentrate their training on game creation.
All core work done on the editor must not be game specific. We must be able to extend it for use on all of our Playstation 2 products, giving it an expected life span of at least 5 years.
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:
Source control & file versioning for content & tools. Having spent the whole of our Playstation 1 development with nothing more than naming conventions, incremental saving and DAT backups to fall back on, it was generally felt that it was about time that we implemented our own system to control the content side of the project. We spent some time looking at off the shelf solutions but in the end decided to go for writing our own in house solution to allow us to embed the tools within the 3D package and have full control over the way they worked. At the very least we wanted the ability to check files in and out of an established project structure and assign ownership to versions so we could manage revisions.
A project structure that allowed for both local and global export. Hand-in-hand with source control and file versioning, the ability to view work in progress locally was seen as essential for encouraging creativity and the highest possible standards. The art team on The Getaway shares a Tool development system one between two and are encouraged to export and play the game continuously. We now run a weekly criticism session where artists present their work to their peers and learn from each other.
An Integrity & Validity Checking System. Making game content is a technically demanding discipline that takes some artists years to master. Because we knew that our new projects were inevitably going to be built by largely inexperienced staff, the level editor specification demanded that an extensive and extendible system of validity checking be built in from day one. We wanted to ensure that final source data could always be guaranteed as good for the latest build.
An automated build process. From experience, artists are not the best people to take charge of a build process. In general we found we got the best results on our Playstation 1 projects using simple, pre-defined dependency rules for the majority of builds, always keeping the option of a full re-build available for major tool changes.
A combined approach to scene building allowing for both reference files and directly built geometry. The initial specification called for a library system to be implemented so that scenes could be rapidly constructed from pre-made building blocks. It was rapidly decided that this was not flexible enough to allow us to achieve the highest graphical standards and a system that supported both custom geometry and file referencing would be preferable. It would be down to the editor to distinguish between the two and filter accordingly at export time.
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:
Library Models & Landmarks. The majority of exterior artwork would be built from re-useable models. These would be kept in a library with a simple graphical front end. As we had an art team with eight people available on day one, to make maximum use of these resources, library production started immediately. Inevitably, most of the models from this period had to be re-worked but it gave us a starting point for testing the PS2 and exploring our art production methods, especially texturing. The library files would each hold a single model and these would be referenced into the layout scenes. The decision to use file references was taken so that quality control and the process of amending and updating scenes would be simplified as much as possible.
Road Construction. While the art team were photographing the city and producing library models that captured the feel of each area, the design team were to work ahead of the artists constructing roads. Working directly from Ordinance Survey Data, The Getaway road network accurately follows the real London Streets right down to all heights being correctly matched above sea level.
Collision Modeling. Immediately after finalizing the road graphics, the designers were to convert the road mesh to simplified collision data.
Parallel Development. With the roads and collision available to the whole team as a read-only layer, the plan was that, from that point on, level development should move in parallel across the different disciplines.
Design - Having the roads and collision available gives a drivable surface as early as possible in development and game-play testing and route planning can begin.
Mapping - Building up from the roads, the road markings and traffic system are added next. Built from a series of splines and custom junction nodes the traffic system is to control the flow of cars and pedestrians around the city.
Art - Using the roads as a base, the artists should then begin the task of laying out their buildings, converting roads into recognizable streets adding street objects and furniture to bring them to life.
Level Specific Data. With the core level in place, balanced both technically and for game-play, level specific data needed to be added to complete the game.
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 -
Customization. We knew we were going to make some heavy additions to the core programs functionality and liked the flexibility that both the API and MEL scripting gave us.
Animation. Both The Getaway and the studio's other title, This Is Football, had a huge animation requirement. We needed a package with strong animation tools and felt that Maya fit the bill here, too.
Recruitment. One of our major sources of new graduate staff is the National Center for Computer Animation, part of Bournemouth University. Their experienced Maya students were just starting to graduate and we felt it was an appropriate time to tap into their skills.
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. |
Art - just that - the buildings
Design - control objects, dynamic objects etc
Traffic - splines and junction
Collision
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:
We have a Check In and Out source control system implemented within Maya for both the exterior and interior scenes, including incremental backups.
We now interrupt all file operations and construct and deconstruct a single working scene from multiple source files.
We have full validity and integrity checking attached to all file operations so that bad data cannot be added to the project.
The system is flexible enough to handle both interior and exterior artwork and the database systems are also used to manage animation and dynamic object data, as well.
We have complete separation between the organization of the data and the interface to it, allowing the interface to be upgraded separately from the core tools and the system to be re-used on future projects
Dealing with the Consequences of Our Decisions (or, What Went Wrong)
Loads of Maya trouble. Not surprisingly we were asking Maya to do many things that its creators had never considered. Despite hours on training courses, long exchanges of e-mail, having Alias staff in the office, etc, we were left out in the cold to find our own way most of the time.
The Grid Cells were simply too large. Now, this might seem trivial at first glance, but it actually caused substantial project slow down for several months. The amount of data inside the original 500mx500m cells was excessive for the following reasons:
The art package/PC set-up was not powerful enough to allow the artist to manipulate the required density of geometry in real-time.
Too much map area was checked out to a single artist at any time. Not only was it too much for them to work with, but it also restricted the management of development as no one else could get access to the data. The result was that artists were working largely in geographical isolation. This had two undesirable effects on the project: first, quality suffered, as individuals were not comparing their work with that of other frequently; second, there was little or no sense of progress as units of work were too large. Project momentum suffered alongside quality of work.
Junctions between cells became impossible to complete as up to four cells at a time were needed by a single artist.
As a result, the decision was made to drop to 250mx250m as soon as practical, quartering the amount of data per cell but increasing the number of edges and the possibility for continuity problems. Unfortunately, there was always a milestone getting in the way of disrupting the project and making the change to a smaller cell size and I would say, in hindsight, that we left it too long.
New way of working for the artists and especially designers. Even the experienced artists took a while to appreciate the value of the source control we introduced. Having never been asked to check their work in or out, it was a real educational process to get them to work that way. Generally, the reluctance soon disappeared around the time they either lost a file or had their hard work overwritten by someone else.
Unreported Problems. Although we went to great lengths to catch as many problems as we could think of, inevitably we didn't get them all. The level of inexperience in the team showed at this point as many of the new art and design staff simply didn't call out when they hit trouble. In general, we found we lacked a quick and responsive way to complain and a knowledge base of potential problems and, more importantly, solutions. In addition, we found new tools staff were prone to not appreciating the importance of a clear and consistent error messages. For too long, I found myself telling people to ignore certain error messages as irrelevant which had the overall effect of undermining the genuine problem ones. To get over this we ended up upgrading to particularly harsh error checking and validity checks on all scenes unfortunately slowing down the workflow.
The Read-Only layer control wasn't implemented quickly or smoothly enough. As we started using the source control system before this feature was finalized, several members of the team became quite creative and came up with there own unexpected methods of adding read-only data. This caused some confusion and a step back and re-education was necessary before we could continue.
Local Export was implemented too slowly. We got our priorities wrong, pure and simple.
Textures are not integrated well. This was the draw back of choosing to integrate our source control tools so closely with our 3D package, when we came to look at handling our textures in the same way we found that the customization we took for granted simply wasn't available in Photoshop.
What was added along the way?
Logging & responsibility tracking was expanded considerably. Our own oversight perhaps, but initially we only tracked the main map layout scenes, this was upgraded to handle library models as well.
Ability to export selection (sub-cell) only. To speed up development, the ability to export part of a scene from any level of the hierarchy.
Extended integrity & validity checking. Even though we knew we would need them, I still can't quite believe the number of additional checks we've added as we've gone along, to both library models and layout scenes. We now exist in a totalitarian state where you cannot check in bad data; in fact, it's hard to even export it without getting caught.
Search and query utilities by the bucket load. Well, if you have a database you might as well query it. All sorts of different utilities have been written as the game has progressed—perhaps next time we will role them up into a single interface.
Integration of packer & databases for de-bugging. Largely a double-check but necessary all the same. Although we had already placed as many checks as possible inside the model creation and export process, on packing the data for the game, we still found that errors were sneaking into the game. A double check that cross-referenced the database to find the source of each problem was necessary.
Source locking. Never part of the original specification we quickly added the facility to lock completed files and mark them as final, securing the source.
And, finally, what would we do differently next time?
Grid cells. Maps being square may be a convenient way of working for the Ordinance Survey but it isn't great for development. Unfortunately for us, European cities are not built on nice, neat regular grids, so cutting the map using one creates all sorts of strange fragments of streets that break the flow and require the artists to double check the edges too often. Although it would have required a lot more pre-production to get the Check In & Out interface up and running, a model that allowed the level data to be organized by streets and junctions would have been more suitable. This is particularly frustrating as, by separating the database and the interface to it, the design of the tools already allowed for arbitrary shaped collections of data to be grouped into work units with a mind to future projects. Something for the sequel perhaps?
Progress monitoring & feedback. As we quickly discovered, very large titles feel slow to progress and moral and momentum are closely inter-related. Given that we have already developed a map based interface we already have a graphical representation of the workload. In the future, I would like to improve on it so that it can be used to display progress too. Another minor change, but if you saw the number of paper copies of the map pinned up on walls around the studio you would see my point.
Debugging. Complete integration of on-box debugging information and the databases, if we'd had a bit more time in pre-production we could have handled this side of the project far more effectively. A more simple and effective interface to all the de-bugging information will be the first thing on the tools list for the next title.
Streamline the tools. Unfortunately, we can't store changes that have been made internally to a scene. This means that, in order to guarantee the whole project is up-to-date, exports need to be done on a whole layer at a time, potentially slowing the process down.
Errors & Warnings. We now wish we had implemented a more flexible system of categorizing errors and warnings to allow us to do the following:
Easily migrate checks between the errors & warnings as required, based on the status of the project and improvements to the tools.
Have specific user configurations that allow us to vary the level of feedback on an artist-by-artist basis.
Add automatic reporting so that recurring problems could be isolated and dealt with.
The Getaway is scheduled for world wide simultaneous release in the last quarter of 2001.
Thanks to Alan Dann, Mark Collins and Naz Hirani for help in putting both this presentation and the game together.
Read more about:
FeaturesAbout the Author(s)
You May Also Like
