Developer Diaries

Star Wars Battlefront - Designer Diary #6

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.