Playstation update @ GameSpy

[ZinC°hda]

In this installment of our Star Wars Battlefront series, Jens Andersen (lead designer) discusses his philosophy on creating the design document for the game. Andersen is disappointed with the process in general and wanted to do something very different for Battlefront.

 

It has been a long road for us here at Pandemic … and we're almost at the end of it. The journey has been as challenging as it has been rewarding, and I look forward to the day when it finally gets in your hands. And, if you are anything like me, you've been waiting for a game like this for a long time.

 

The Star Wars universe is so rich and vast that you can really get lost in the possibilities. If you aren't disciplined enough to know what your goals are and how to achieve them, then you can't give yourself the freedom to get creative without endangering the core of your game. LucasArts definitely understands the power of its license and the passion of their fans, and it was important for us to realize this as we moved forward during pre-production so that we could clearly show them what our intentions were with the game.

 

After being in the business for some time, I have seen how design docs have been used and put together, and I have always found it rather disappointing. The docs were either too vague, more like extended pitch docs, or they were simply left by the wayside once the first set of changes to the game were made. It was my hope to change this. To me, the design document represents the creative vision of the game presented in a technical format. It was quite a challenge to maintain creativity while trying to be as methodical and thorough as possible. This is the balance I alluded to earlier.

 

A colleague of mine had turned me on to engineering specs which are documents used by engineers to map out their intentions before working on a project. I took a look and eventually decided to adopt something similar … something that would allow anyone who had a question about a feature to have access to the large concept of said feature, but also the various nuances I had imagined when conceptualizing it.

 

This method leads to a lot of label making, defining terms, and making sure that each concept is clearly stated and not crossing streams with other features. In the end, this worked out wonderfully and the design document received a lot of praise from LucasArts and it brought an incredible amount of focus to the initial implementation of the game.

 

This was no easy challenge, however. Technical writing is very different from creative writing and requires careful reasoning and planning. The first thing to remember is to never assume anyone knows what you are talking about. Even if it is the most basic and ancient of game mechanics, don't assume you don't need to define it for the purpose of your document. Define everything.

 

Advertisement

The first step is coming up with the goals you have for a given feature. Each section of the DD starts with a goals breakdown. For example, the character selection process whereby a player selects their unit type and spawns into the world had the following goals:

 

Concise - To provide a clear and easy way to choose a character type; to make the unit selection as fast and streamlined as it can be for the player to get in game.

Consistent - To maintain cohesion between the four armies on each screen of the character selection.

Informative - To make available all necessary information about each unit without becoming officious.

Efficient - To leverage as much existing game art as possible; to have minimal requirements on memory resources.

Beautiful - To be cutting edge in appearance and keeping pace with the latest graphical innovations; to maintain a consistent feel with any in-game counterparts.

 

Now these are some pretty broad statements, which is good because they are meant to be the overall guiding factors as you write up the more detailed section of the feature. They are meant to be touchstones or sounding boards. And every aspect of the feature should be able to relate back to these statements. If it doesn't, then it most likely isn't helping you achieve your goal and should be more closely scrutinized or abandoned.

 

After the goals were defined, I moved into what I called the "requirements" for the feature. These were the nuts and bolts and what was going to be needed to achieve these goals. So, for example, if you are writing up your unit A.I. section you'll want to define what the various layers of A.I. are. You'll start with the overall layers for every unit in the game down to the specifics for each individual's role. Each is defined in turn so that you build the system from the foundation up.

 

Once the requirements are all defined, I provide a series of test cases or benchmarks. Test cases and benchmarks are things that the programmers, artists, and designers can use to make sure they have met the requirements listed for the feature. If the test case fails or the benchmark is not met, then they need to go back and try again.

 

Having this kind of structure did two things: it sent a clear and precise message to anyone who read it what we were trying to build, and, more importantly, it lets you change and augment features with confidence because you could account for all of the ripples that change would cause.

 

Game development has changed a lot since I entered the field. The size of the teams, scope of the features, and expectations of consumers has greatly increased. The amount of information that has to be conveyed across the teams to get a game completed is staggering. It is essential that people have a central cache of information that represents the direction of the game.

 

So the point is to be thorough in your designs. The more specific and clear you can be during the planning stages, the easier it will be for your team to see what's coming down the road. Sounds kind of obvious, but it's surprising how little this is practiced. I found it to be an incredibly useful tool for me on Star Wars Battlefront, and I look forward to working on perfecting the technique on my next project. I know you'll enjoy the game when it comes out in September … it truly has a lot to offer.

 

To read it and check out the couple of new screenshots goto the link below :-

 

http://ps2.gamespy.com/playstation-2/star-wars-battlefront/536304p1.html

[Alegis]

IMO not really that informative..what you think

[Virtuosis]

It's more or like a generic "How I develop games," Instead of "How I develop Star Wars Battlefield." Which of course is what we all wanted..

[joesdomain]

Yeah, I think it didn't help me with any new information. I already know how they make a video game.