GameSpot may receive revenue from affiliate and advertising partnerships for sharing this content and from purchases through links.

Pursuit Force Designer Diary #4 - A Day in the Life

Members of Bigbig Studios' Pursuit Force team talk to us about their roles during the game's development.

Comments

The North American release of Pursuit Force is now less than a month away, and we recently had an opportunity to check out some of the improvements that have been made to the game since its European release last year. In our previous Pursuit Force designer diaries, Jonathan Webb and Simon Bursey of Bigbig Studios have talked in some detail about the game's beginnings, its innovative gameplay mechanics, and its art style and environments. In this, our final designer diary, four other members of the Bigbig team talk about their roles during the development of Pursuit Force. Have you ever wondered what a typical day might be like if you were employed as a...

Game Designer?

By Chris Whiteside
Lead Game Designer, Bigbig Studios

We are fortunate at Bigbig to have a team of very passionate and hard-working designers, each with strengths and weaknesses and a strong ability to communicate. It is hard to quantify a designer's job on a day-to-day basis, as this role changes throughout the development cycle of a project, so here are some examples.

No idea, no matter how stupid it may sound, is a bad idea.
No idea, no matter how stupid it may sound, is a bad idea.

During the conceptual phase the designers spent a great deal of time researching media, such as games, magazines, and films. A number of iterations of the Pursuit Force concept were then written up and discussed, key features were expanded upon, and then the concept was refined. The design focus was not to create a long-winded document full of the game feature sets, but rather to create a document that quickly communicated what the key elements of the game were.

Once we had the high-level concept nailed down, it was time to turn our attention to the creativity of the rest of the team. We invited them to join us in a number of brainstorm meetings. Our rule was "No idea, no matter how stupid it may sound, is a bad idea." An example of this was raised by one of our artists, who insisted that having a gang of crazed lunatics breaking out of a prison would be a great idea for the game. Prior to this idea, the design team's focus on the gangs was to create a set of "no nonsense" gangs with a threatening edge to them. This simple idea put into question a large part of the overall communication of the gameworld and, more importantly, the medium that we were so heavily influenced by, such as films like Lethal Weapon. While we wanted to retain a serious theme, we also wanted to break up the story by injecting humor. So from this single idea in a brainstorm meeting we decided it would be wise to inject some humor into the entire product.

Following this phase we began work on design. Every day for three weeks the game designers would arrive for work in the morning and march straight into the meeting room. We sat down and worked out the focus and agenda for the day, and then design discussions began. Every idea that was put forward was utterly dissected and was worked through each section of game design that we thought it would impact. Once agreement had been reached on a mechanic or system, we would then recap from our diagrams and notes. At the end of the day a core design document was written up as bullet points on our respective computers. Once all design elements were worked out, we began to write up the game design document.

We made a decision very early on that we wanted the document to be bite-size and as digestible as possible without compromising the product. The core elements of the game were therefore separated and worked on as individual documents. Each section of design laid out how each mechanic, feature, or system should work. Areas that the design team was not strong on were noted in each document and left to the discretion of team members working on that particular area. Once we had finished creating the documentation, it was put into HTML format, placed on an internal intranet site, and separated into discipline sections for the team to work on.

In conjunction with the art team we designed the gang and characters, and from there we began to design Pursuit Force's environments. The game design team researched real-world locations, created environmental design template documents, and then critiqued the environments as they were passed on through each phase of creation from the art team. During this time we also created the mission documents, which we would build the game's missions from. This was a very enjoyable and rewarding period, because every day we would see the game coming to life as each discipline completed separate stages of the Pursuit Force construction.

Level designers initially had roughly five days to work on each mission.
Level designers initially had roughly five days to work on each mission.

In the next stage, the designers began their tasks in level design. The designers were given a set of missions to set up by a specific date as per the schedule--roughly five days per mission. The process initially involved tweaking the drivable geometry, then laying down AI splines and traffic systems, which culminated in the placing of vehicles and characters and the assignation of weapons and their respective attack patterns. This was a highly enjoyable section of the project, mainly because the results of our work were instantaneous. Once the missions were complete, we tweaked and polished on a day-to-day basis until the project was finished.

Throughout the project a key role was for designers to represent the individual element of the core design that had been assigned to them. Simply, we would be on hand to discuss, fix, and play-test any element of the game design that a team member wished us to. The role would also extend beyond the boundaries of the studio, where a designer would travel to another part of the world to represent the gameplay and design vision of the project as part of the marketing process. These were always highly enjoyable excursions (it is always fun to show the game to fresh eyes and get their feedback), a lot of hard work, and also a lot of hard play, but those stories are best saved for another day.

Environment Artist?

By Piers Coe
Environment Artist, Bigbig Studios

Being part of the relatively small environment team that worked on Pursuit Force, I was fortunate to have a good deal of autonomy in creating the environments that I was scheduled to do. I was responsible for two of the environments in Pursuit Force, and apart from regularly liaising with the design team about gameplay-related issues, I had a great deal of creative freedom when it came to environment decisions, which made working on the environments very fulfilling. There's a very cooperative atmosphere among the environment team, and we're always bouncing ideas and suggestions off each other to come up with new ideas or ways of doing things. Being responsible for a whole environment meant that I would be creating everything in it--from roads and terrain, to buildings, vegetation, street furniture, distant scenery, and skydomes--as well as creating collision geometry for our physics engine.

Artists were responsible for creating every single object in their assigned environments .
Artists were responsible for creating every single object in their assigned environments .

My day would usually consist of one or more of three main tasks: reference gathering, object modeling, and environment modeling. If object modeling was on the schedule, then I'd usually start by gathering as much reference together as possible, both from our internal database and via the Internet. Then I'd start the actual modeling, blocking things out in rough shapes before going into more detail where necessary, and finishing up with the texturing, which is usually based on the most appropriate photos from our reference library and a global-illumination bake from the model.

For environment creation, I spend most of my time working with our proprietary patch-based modeling tools that allow me to quickly flesh out complex road layouts and early stages of terrain, in order to give the design team a solid visual representation of how any given environment is going to look. Once each route has been gameplay-tested, I can go back to detailing the terrain and finalizing textures. The objects are usually built before routes are created, so once a route has been signed off for gameplay purposes, I'm free to start laying down objects from the previously built library, adjusting and tweaking where necessary to make them fit their particular surroundings.

The atmosphere is generally really good among the team, and artists, animators, and programmers. All are intermixed around the office, meaning we're always involved in what's going on in various parts of the project, and communication flows pretty freely. Things get pressured at or near milestones, but everyone works to the same goals, so outbursts are rare, providing we're all stocked up with supplies from the local corner shop (thanks Chun!!). Providing they're not completely snowed under, everyone's keen to help out and resolve issues as they arise, be it an internal tool issue, some code that's needed for a particular environment effect, or an art asset that's needed from another part of the team. Just about everybody's really enthusiastic about the game and loves to see new stuff going in day by day. It's really encouraging to get good reactions from the other team members as a new environment or route goes in to the game for the first time. Likewise, it's also a nice surprise when testing a particular environment to see new vehicles, characters, or special effects appear.

Programmer?

By Tony Marshall
Programmer, Bigbig Studios

The coding for Pursuit Force was split into numerous sections, and I was responsible for the mission code. Basically, I worked closely with the design team helping them put their cool mission ideas into the game. There was always an element of give and take involved. Some of the design ideas were just not possible. Or more specifically, they were possible but just not in the time frame. I would then build a new version of the game to give to the designers to test out the missions.

Working on this area of the game was always a challenge since it interfaces with almost every other element. Sometimes we'd be looking at a mission, and the vehicles would disappear or not appear in the first place. In others, the characters would run around like headless chickens. Often this was due to bugs within other areas of code, but since I was dealing with the mission code, I tended to be the first programmer the designers called on. Also, missions were split into different grades. You have your standard missions, the special missions, and your boss missions. Standard missions required the minimum amount of work, whereas at the other end of the scale, the boss missions usually required us to write special code due to their unique structure. In one mission we have a character jumping from vehicle to vehicle as you're trying to take him down with the chopper cannon. This is an example of a mission that required special coding. All components already existed within the code to get the character to jump from vehicle to vehicle. It was the mission code's job to piece all of this together.

The US version of Pursuit Force will feature checkpoints not present in the European game.
The US version of Pursuit Force will feature checkpoints not present in the European game.

Once the European version of the game was complete, we started to concentrate on the US version. One area needing improvement was difficulty, and it was decided, due to the length of some of the missions, to include checkpoints. This was my responsibility. Missions were already split into different sections, and so it was decided to place the checkpoints at these parts of the missions. It made it logical for the player and easier for us. Once these were in place it was clear that they really helped the game.

Now that the game has finally been completed--missions done and bugs ironed out--it's good to finally sit back and look at the game as a whole. We had some pretty busy periods--although no all-nighters, which for me is a first. And although there were times of panic--usually around specific milestones--working on the game was never anything but fun. The whole team pulled together and made the entire experience worthwhile.

Q&A?

By Alan Stock
Game Designer, Bigbig Studios

During the development of Pursuit Force we used the design team to perform our internal testing at Bigbig. Sony and Evolution QA were also on the case full time, sending bugs daily to the team to fix. Toward the end of development, QA spent lots of time testing the game--playing Pursuit Force from start to finish again and again to ensure that there were no problems and that the learning curve was OK. Sometimes we'd just need to check that levels were loading throughout the game with no problems--quite a repetitive task. Other times we'd be checking that high scores could be beaten on every level, which was much more fun. We'd also check that specific bugs had been fixed by the team before sending the latest version of Pursuit Force off to Sony QA to verify they'd been fixed.

Bugs can be fun, but you shouldn't find any in the finished game.
Bugs can be fun, but you shouldn't find any in the finished game.

We'd find some interesting bugs, and Sony QA would send us some good ones too. One time after going off to do something else, leaving a boat idle on a river, one of us came back to find the waves of the river had grown to tsunami proportions! Another tester swore he found a bug where all the Killer 66 gang had become pygmy-sized in a level. No one else ever did see this bug, so it's become the mysterious legend of the pygmies...

Another fun bug was when you crashed your car into other moving objects at a certain angle. Your car would be catapulted into the air in a frenzy of crazy spins and ejected out of the level at an insane speed into the void. At least, it was fun until you realized you couldn't get back in the level and had to restart. One of my favorite bugs was a stream of cars raining down from a bridge onto the freeway below. It looked great; you'd see the shadow of the car get bigger and bigger, then BAM!!, the car hit the ground in a shower of sparks, then another car and another and another, until it just turned into a big pileup down there with all the cars smashing into each other. Great to watch!

Most of the time when testing you're deliberately trying to break the game, so you do strange and unexpected things to check whether the game can handle them. Sometimes it's fun, and sometimes it's repetitive and boring, but you always get a satisfaction in knowing the game's constantly improving as a result. There's also a strange pleasure in finding an obscure bug no one else has picked up.

Got a news tip or want to contact us directly? Email news@gamespot.com

Join the conversation
There are no comments about this story