|
 Features
Postmortem:
Pixelogic's The Italian Job
What Went Wrong
1. The
Chicken and the Egg. Large amount of art resources were taken up to
coincide with the development of COSS, which will allow for large free-roaming
environments to be loaded 'on-the-fly', but to test this new technology
to its limits, levels needed to be modelled to a near finished state.
This whole process involved a lot of art being reiterated and the fact
that London ended up being built before the loading technology was finalised
resulted in four 'wasted' months, the pressure was on to have a level
up and running so playable missions could be implemented, publishers wanted
to see a game, these first four months would better have been used finding
a good quality/style for the levels.
Basically, all the artwork done on the London in the first four months
was scrapped except for the general layout and the whole city had to be
modelled again, this new version of the city was done in double time and
so there was no time for quality assurance. After a couple of months of
our artists slogging away, it became clear that the almost complete new
London level just didn't reach our graphical standards so the artists
had to start building pre-fabricated buildings with textures and replacing
all the poor quality buildings with the improved ones. All this re-working
of environments also affected the mission schedule so playable missions
were no longer playable and had to be re-tweaked or even re-designed by
the designers to make them work.
This turned out to be a good learning experience in how to deal with massive
levels but if there was a little less pressure in the beginning while
COSS was being developed, we may have actually kept the first few months
of work.
Some lessons must have been learnt, the hard work at the beginning wasn't
all a waste of time as Turin was built in a similar fashion but actually
took less time to build even though the completed city was quite a lot
bigger than London.
London finally contained over 150,000 polygons and Turin consisted of
over 250,000 polygons. The layouts for each city were based on real road
maps so the authenticity of how these cities came across were as accurate
and true to life as possible.
2. Joy riding. During the final stages, just two weeks before submitting
the gold master, Robin one of our programmers had been working over the
weekend tying up some loose ends. He left the office, got into his car
and started on his way home, meanwhile some delinquent joy-riders were
screeching around a corner so fast, they had veered onto the opposite
side of the road resulting in a head-on collision with Rob.
The rest of the team found out about the accident on the following Monday
morning, Rob was in hospital, strapped down so he couldn't move. The news
from his mother was, he could have seriously damaged his spinal column
and the fear of Rob being paralysed was in the air, everyone was in anticipation
of the X-ray results.
A call was received later that day, again from his mother, the doctors
said he was in the clear but he wasn't allowed to move and had to stay
in hospital until further notice, a sigh of relief was heard from everyone
in the office.
Luckily, after a few days he soon started to recover and was sent home
to rest, we sent him cards and joked about ideas of how we considered
transporting his PC from the office to the hospital and rig it so he could
look at a screen and code while still being laid on his back -- we wouldn't
really do a thing like that.
The game still had to be finished so after a few phone conversations we
sent the PC to his house in case he got bored and he painfully continued
to finish coding his part of the game from his bed.
This delayed the completion of the game by two weeks; I don't think you
could ever prepare for such an event in a development schedule, it's definitely
one Pixelogic will always remember. Rob has now fully recovered; he only
twitches now and again.
3. Fast-loading blues. There is nothing worse than having to wait
for a game to load, especially if the mission only lasts a couple of minutes.
Our loading system before the fast loader involved having a separate executable
for each mission, which had to be loaded in and executed. Once executed,
the executable file had to initialise all of its variables and load all
of its graphic and sound data, this proved to take too long and something
had to be done to reduce the load times.
The basics of the fast loading to be developed involved taking a snapshot
of the memory contents once a stage had been loaded with the graphic and
sound data initialised, this snapshot could then be loaded at any time
and the stage would effectively be restarted. At first, this method was
thought to be too complex for a simple problem, and it did not solve the
problem of having separate executables for the front-end and every single
stage in the game.
More research into solving similar problems involved using memory overlays,
which would mean the front-end, and the basic game code would be contained
in one executable. Unfortunately this method was not compatible due to
the complexity of our current game engine and adding this sort of functionality
would have meant completely re-writing the game engine, a task we simply
didn't have time to do so it was back to the original snapshot idea.
A basic fast loading system was written within the next few days, which
worked fine on the PC but would not work when run from a CD. After days
of hair pulling, the problem was traced to a combination of bad CD's and
dodgy playstations that had been dropped one too many times on the floor.
After more testing and code optimisations, the new loading system worked
fine and the loading times began to become more reasonable. The only drawback
was that it still had not solved the problem of separate executables for
each stage and this became a real pain as we had two main cities which
were shared across over 86 stages, so if small level changes had occurred,
this meant having to recompile 40 or more stages again before re-taking
the snapshot. It got even worse than this, if there was an in-game front-end
change; all 86 stages had to be recompiled and run before a snapshot could
be taken.
Compile
times have always been long, but not as long as we anticipated. Our problems
did not stop there, we tried to get a system going where we shared the
compiling between two machines to cut the time down, this itself contained
many problems as the two sets of snapshots simply wouldn't work together
when burnt onto a CD. After many late nights and living out of the office
with frustration and another added problem of our CD burner breaking down,
the two PC's compiling problem was traced to fact the game data on each
of these machines were not totally synced. A streamlined compiling method
eventually surfaced that did not involve too many late nights and compiling
could be then left to run on one machine overnight until the last couple
of weeks of the project where game testers were brought in to help iron
out any left over bugs, so compiling became an everyday occurrence until
the game was finished. The result of all these problems encountered finally
gave us a more efficient system of compiling a whole game build successfully
and reliably.
4. SFX. The sound code and how we added sound from our previous
projects enabled any member of the team to add sound to collisions, objects,
vehicles, and levels quickly and easily, however on TIJ the code
structure of objects differed slightly so we lost some of the flexibility
that our original sound functions gave us. More of our sound playing functions
were lost as new technologies were coded such as car handling, rigid body
physics, and collision code. While implementing new sound code and adding
the actual sound effects to the game, problems began to occur due to lack
of sound resources available, because of this some of the engines sounds
ended up looping very badly. The main music tracks and basic SFX were
outsourced at the start of the project but there was never a review of
the ongoing work and this ended up with nobody really liking the results.
In the end it was considered best to re-do all the sound effects ourselves
and due to the unforeseen car accident of our programmer who was in the
process of implementing this code, it became a bit of a rush job. Eventually
with our sound functions back in place where they should be, the game
began to sound how we intended.
The amount of speech and effects to be implemented in TIJ was far
greater than any other game we had previously encountered, a lot speech
samples had to be squeezed into memory with a lot of other generic sounds
through heavy editing and compression techniques.
Our mistake of underestimating the length of time for this amount of sound
implementation has taught us a valuable hard lesson; we now take much
more consideration of sound from the outset to allow us to make proper
use of any outsourced sound resources efficiently.
5. FMV.
The inclusion FMV was discussed at the design stage of TIJ, we
planned to use our in-house scripting language known as the Mission Builder
which allows us to prototype and create game content quickly without the
need of programmers, so designers could create short scenes using the
in-game engine and blend it to the corresponding missions for a seamless
gaming experience.
However, the Mission Builder was never designed to produce complex cinematic
scenes and new functionality had to be added to achieve this. The process
of creating in game cut scenes could be quite crude since there was a
limited amount of feed-back to the designer and to create a short sequence
of five seconds could take up to two days which then would have to be
constantly tweaked. This involved creating paths for cameras and objects
within 3DS Max, then exporting these positions to the Mission Builder
where speeds and simple camera behaviors could be scripted to make the
scene work. Unfortunately, the designer could not see the total outcome
of their work until the stage/mission was compiled and ran.
The whole process took way too long to make a scene look right, with limited
camera controls and once a high standard of camera work was reached, it
was extremely difficult to leave any other camera work that wasn't up
to scratch, the time would have been better used to polish the missions.
The amount of time required to produce this type FMV would definitely
need cutting down in the future by creating better tools so our designers
can produce in-game cuts quickly and confidently.
The
main FMV to be shown at key stages of TIJ was going to be outsourced by
the Publishers, unfortunately this did not get confirmed and time was
getting on before we were told that we were not going to get any outsourced
FMV. We quickly realised the need to produce at least a minimum set of
FMV ourselves to progress the plot within the game. In-game footage had
to be created, captured and edited together to create these FMV sequences
in the three months left of the project. Some mayor story lines had to
be explained and there wasn't much time to do this in, the final results
could have been a lot better if we had known earlier that we would be
doing this stuff ourselves and time would have been scheduled for this.
However, an intro movie was outsourced but these key plot sequences would
have been a lot more polished if they had also been outsourced from the
start of the project. Production values are so important and can affect
how the general public judge any product.
______________________________________________________
 Game
Data
|
|
|
|
|
