Storage Informer
Storage Informer

Highlights and challenges during the Ghostbusters development, Part 1

by on Jun.15, 2009, under Storage

Highlights and challenges during the Ghostbusters development, Part 1

Ghostbusters was an unusually long project for us – we started in January 2006 with a prototype. For the first nine months of development, we were working on recreating the ballroom scene where Slimer is captured from the first movie, obtaining the movie license, and getting a green light to develop the project. At the same time we were working on Ghostbusters, we knew we had something special with the Infernal Engine. A few former Terminal Reality employees wanted to use our technology to create a game for themselves, and hence our engine licensing effort began as well.

We started off knowing we would be a cross platform game. We had early PS3 hardware, early 360 hardware, and the dual core PC was the fastest money could buy. Multithreaded game programming was just a concept – we had experience on the PS2 where you could get two coprocessors running independently from the main CPU, but nobody had made a game yet with multiple cores in mind. As the lowest common denominator, we chose the PS3 multithreading model, with one main CPU controlling the game loop and multiple coprocessors performing small "job" tasks as the main game loop needed work done.

When we got final development hardware, we knew multiprocessing was the way to go. At this point, the consoles were faster then their PC counterparts, and we had to reinvent how the Infernal Engine worked. Ghostbusters was conceived and sold as a game with highly destructive enviornments, so our physics engine, Velocity, was the first part of the game to be multi-threaded.

Threading Velocity was quite a fun task and we are still making improvements to this date. Velocity consists of two main parts, collision detection and the physics solver. Collision detection is an obvious problem to thread – if you had 5000 processors and 5000 bodies, you could do 5000 collisions in one step. However, the rigid body solver was a big challenge to thread. If you have multiple "islands" of bodies touching each other, then you can perform the islands solving in parallel. However, if you have one giant island of rigid bodies, like a huge pile of library books, things get really tricky as each body&aposs accumulated forces depends slightly on its neighbors.

We also knew that for a game coming out in 2009, that the bar would be quite high for particles and special effects. We set out to write our 3rd particle engine, appropriately named, Trifecta. Trifecta would be a material driven particle system giving the artist more freedom than ever, with no code involvment. We also decided early on to make it use a new technique called "soft particles." Soft particles blur the intersections between the particles and the scenery and eliminates the billboard effects from previous efforts. For the first time, you could have realistic smoke fill up a room! Trifecta was originally written as single threaded – up to this point, our previous particle engines never took a lot of CPU time to simulate or render, but towards the end of Ghostbusters, it was clear to us that we were spending over 25% of our frame time on just special effects when the action was heavy.

We almost didn&apost ship Ghostbusters with Trifeca running in parallel – it was a highly object oriented system with layers and layers of effects that could be added to each particle system instance. During development, we could not figure out any reasonable method for making such a highly object oriented system simulate and render in parallel. Only after we thought we were originally done with the game and had a week&aposs worth of rest, we figured it out. It turned out cloning the particle instance data, rather than using traditional methods of overlapping rendering and simulation, worked extraordinarily well. What took us almost a year to figure out was coded in two days, and slipped into the game, almost doubling the frame rate on the Xbox 360 and PC versions. We could now even keep 4 cores fully busy (provided you have a very fast GPU) on your PC!!! Most review copies of Ghostbusters went out without this final improvement.

One more challenge we had was to fit Ghostbusters on a single DVD-ROM not only for the Xbox 360, but for the PC version as well. In order to fit an hour&aposs worth of HD video on the ROM where every bit counted, we would need a modern compression system. Luckily for us, the Open Video format was announced in November 2008, and we were able to quickly recode it to run in parallel on the 360 and PS3 in order to be fast enough. We now had high quality 720p HD video at 6000kbps with 10 channels of audio. (5.1 audio with 4 extra center channel languages for those of you counting…)

Ghostbusters was an expensive project to make, and it switched publishers twice. Sierra was dissolved after Vivendi Games was purchased by Activision. Atari purchased the worldwide rights, but then sold their Eurpopean distribution rights to Sony. Each publisher had their own vision for what the game was, and we had our own vision as well. After the first publisher change, our lead level designer took over the reigns of the game and did a great job keeping the team focused on finishing it.

In future posts, I will discuss more of the technical challenges in depth.


:, , , , , , , , , , , ,

Leave a Reply

Powered by WP Hashcash

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...