Gamasutra: The Art & Business of Making Gamesspacer
A Primer for the Design Process, Part 1: Do
View All     RSS
July 31, 2014
arrowPress Releases
July 31, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
A Primer for the Design Process, Part 1: Do

June 30, 2000 Article Start Previous Page 2 of 3 Next
 

Some genre's lend themselves to certain kinds of music, often from professional named bands or individuals. Take a listen to what's good, what seems to be happening, then incorporate its style into your title. Some marketing folks will fork over a chunk of your development budget to sign bands or individuals to do the music for your title, but it's been my understanding that very seldom, if ever, will a person's decision to purchase a title be based on the fact that someone they may have heard on the radio once did the music for the game. In certain cases having a named talent do the music might add to the "cool" factor and help generate a little buzz on websites or the odd magazine, but it's not going to sway the consumer and it can also be a huge licensing hassle with no real guarantee that what gets written for the game will be delivered on time or be any good. If there's any question, a good solution is to try to get a synchronization license (Where you get the right to cover the song, but not to use the original recording by the original artist) for a piece of music you'd really like in your game.

Screen shot from Toon Struck

Some companies have been known to waste a ton of cash trying to get a particular vocal talent or talents to act in their game as, unfortunately, a major marketing aspect of the title. Did it matter that Rob Schnider was the main vocal talent in A Fork in the Tail, or Christopher Lloyd was in Toon Struck? As above, more often than not most gamers won't buy a title simply because there's some celebrity voice actor that they button past in the first 2 seconds of hearing it in order to get back to the game play.
Get something (or someone) good that fits the attitude of the game, and it will increase the gaming experience for the player. That's all you need to be worried about.

What's been done and how was it done?

I talk about this later on in the "Think" section about Critical Evaluation, but this is a very important issue when you first start your design. There's absolutely no need for you to tell a story that's already been told, or develop a game that's already been done, or rehash a genre that's on the way out. Do your research and learn from that research. You should be playing games, plain and simple. You need to know what's out there, what's already been done, and how high the bar has been set so that you can clear it.

2. The Working Design Document

Once you've focused your ideas, its time to think about the design doc. The design doc acts as a script; it should be giving every other professional involved with the product a more than firm idea of what they need to know to implement their portion of the product.

Like other parts of the entertainment business, there are some basic rules and formats for how ideas are presented, as well as a few things that people no longer want to see. Publishing has its "double spaced 12-point Courier font" from the old Smith/Corona days, and film and TV have standard script formats for either television or the silver screen. These formats are not only expected, but also demanded.

Our business is a little different. It's not quite old enough for standards and guidelines to exist, but we're moving into the "broad spectrum formalization" for industry standards and practices. Simply stated, tradition has bred expectation. Certain questions should be answered before the thing is sent to production. This is your job, O Maintainer of the Creative Vision. You need to answer these questions and more, as everyone on the project will be coming to you or your people for information and the lo-down on what needs to happen and, more importantly, how it's supposed to happen.

Design documents tend to fall into one of two formats: they either loosely describe a game concept so upper-management can sign off on the idea, then get dropped into someone's filing cabinet never to be read again OR they are the size of your local Yellow Pages, filled with every imaginable detail that no-one but the person who wrote it cares about or is willing to read.
In an effort to maintain the working lines of communication between the design staff and the production team, we came up with the idea of a "feature-oriented" document that could keep everyone on the team up to date and informed whenever a design change was made or redesigned.

If you look a production movie script, you'll see that there are different colored pages at any given point throughout the entire script. These pages represent changes that have been made to the script since the start of filming. The colors allow the cast and crew to follow the changes and thus maintain continuity and keep everybody -pardon the unintentional pun-on the same page when updates occur.

Like a script, things in a design document will change due to circumstance, talent, or innovative problem solving on the part of management or the production team. These changes should not only be noted, but also sent out to the people whom they affect.

The Feature-Oriented Design Document

Our feature-oriented design document began as a basic form that could help keep the 6 people involved with the design document up to date. It was designed not only as a fluid guide for everyone on the team, but also as a living document that could carry us through the ongoing design of 3 different games.

We put the design document on our LAN, with the design team continually adding to or updating the document at the same time. Version control is a simple matter of the software (in this case MS Word) not allowing more than one person to work on an individual sub-document at any given time.

The document itself incorporates a couple of features that help with keeping things organized, including major headings calling out important items like what the engine needs to do to, AI requirements, game modes, motion requirements, and on and on. Under these heading are the particular sub-documents explaining the features or functions that individuals on the team have been tasked with designing. Whenever a new design feature is nailed down we can send out updates to the relevant team member through E-mail with a hyperlink attached to the virtual document for easy access by team members. We can do this because the document is being written with the whole team in mind.

The sub-documents themselves take the form of a numerated template with the heading numbers tied to the table of contents. This allows us to sort these documents by feature or project when we work on layers of design for separate products. The template helps push for a more detailed design for each feature and also helps the designer answer questions up front, allowing for a more thorough design when the project hits production.

This template also allows us to design for more than one version of the game. Some design features have been layered to appear over a series of releases and as such, you're always on the same page with whatever feature you're thinking to forward.

The master plan for the design document is to have it linked with both a Technical Design Document that's arranged in the same manner and some sort of scheduling software like MS Project. This has the added function of allowing us to asses any impact to milestones or budget new design features may have.

 


Article Start Previous Page 2 of 3 Next

Related Jobs

Galxyz Inc.
Galxyz Inc. — Mountain View, California, United States
[07.31.14]

Narrative Writer for Interactive Media
Firaxis Games
Firaxis Games — Sparks, Baltimore, Maryland, United States
[07.30.14]

Senior Visual Effects Artist
Nordeus
Nordeus — Belgrade, Serbia
[07.30.14]

Senior Game Designer
2K
2K — Novato, California, United States
[07.29.14]

Level Architect






Comments



none
 
Comment: