Guidelines for the Functional Specification

 

 

Created by:†††††† ††††††††††† Game Designer

††††††††††††††††††††††† †††††††††††

Target audience:††††††††††† Game Development Team

 

Approval:†††††††† ††††††††††† Game Producer/Project Manager

 

The functional specification (or spec for short) outlines the features and functions of the product. The target audience is the team doing the work and those responsible for approving the game design. The functional spec is a culmination of the ideas, criticisms and discussions to this point. It fleshes out the skeleton of the vision as expressed in the game concept and game proposal. It is a springboard from which the software plan and production schedule is derived and the implementation begins.

Itís important that it is all written from the user perspective. In other words, what is seen, experienced or interacted with should be the focus of the document. Readers are really just looking to this document to visualize whatís in the game, not how it works.

The length can vary from five pages to a few hundred, depending on the complexity of the game. You really should not aim for a page count. It is just important that each section under these guidelines be addressed. The time involved in writing the functional spec is anywhere from a few days for say a puzzle game, a month for a shooter, to a few months for a complex game such as a strategy game.

It is useful to have summary level paragraphs at the start of every section, so that readers can get the gist without skipping any sections or losing any confidence in the thoroughness of the specification.

Note Ė the functional spec in not a technical document so programming terms should not be used. Use the 100-year rule where the information would be understood 100 years in the past and the future.

 

 

The functional specification can be broken down into a few major sections:

1                     Game Mechanics

2                     User Interface

3                     Art and Video

4                     Sound and Music

5                     Story (if applicable)

6                     Level Requirements

7                     Game demo Ė pass/fail

 

 

 

 

 

 

 

 

 

 

 

1 Game Mechanics

The game mechanics describe the game play in detailed terms, starting with the vision of the core game play, followed by the game flow, which traces the player activity in a typical game.

 

Avoid using actual numbers or programming terms. These will come later in the technical specification, written by the programmers who will want to do things their way (usually the right way). Just tell them what you want to accomplish. For example: "The units should slow down when going up hill and speed up when going down, unless they are a hover or flying vehicle. How much they are affected should be a factor of their climbing and acceleration statistic as well as the angle of the incline."

 

Game mechanics are broken down as follows;

 

 

 

 

 

 

 

 

 

Prioritise the key elements of the game. This is vital for the production schedule. In addition, build in flexibility to allow alternative game elements be used if the original designs cannot be used.

 

2 User Interface

 

Itís starts with a flowchart of the screen and window navigation, then breaks down the functional requirements of all the screens and windows. That done, the GUI artist is free to do what he or she feels is right as long as it meets the requirements. To get him or her started you should provide mock-ups. This often is to the designerís benefit to think everything through. Then follow up with a description of all the GUI objects that need to be programmed to make all the screens work.

 

 

 

 

 

 

3 Art and Video

 

This should be the definitive list for all the art and video in the game. If all design elements are not locked down (v common) add a couple of placeholder references for art to be named later, like mission specific art and art for marketing materials, demos, web pages, manual and packaging.

 

 

-          Game Play Elements: Player and enemy animations (sprites or models), game play structures and interactive objects, weapons, power-ups, etc. Donít forget damage states.

-          Terrain: Environment art like tiles, textures, terrain objects, backgrounds

-          GUI: Screens, windows, pointers, markers, icons, buttons, menus, shell etc

-          Special Effects: Salvo, explosions, sparks, footprints, blood spots, debris, wreckage

-          Marketing and Packaging Art: This includes web page art, sell sheet design, demo splash screens, magazine adds, press art, the box and manual

 

 

 

 

 

 

 

4 Sound and Music

 

Overall Goals: Stress the aesthetic and technical goals for the sound and music. Describe the themes or moods you want. Name existing games or films as examples to aspire to. Issue technical edicts and editing objectives, such as sampling rates, disk space, music formats, and transition methods.

 

Sound FX: List all the sound FX required in the game and where they will be used. Include the intended filenames, but be sure to consult with the sound programmer and sound technician (or composer) on the file naming convention. This makes it easier for people to find the sound FX and fold them into the game. Donít forget about all the areas that sound FX may be used. You donít want to overlook anything and throw off the schedule. Go through all the game elements and your art lists to see if there should be some sound associated with them. Here are some to consider:

GUI: Button clicks, window opening, command acknowledgments

Special Effects: Weapons fire, explosions, radar beeping

Units/Characters: Voice recordings, radio chatter, stomping, collisions

Game Play Elements: Pick-up jingle, alerts, ambient sounds

Terrain (Environment): Birds, jungle sounds, crickets, creaks

Motion: Wind, footfalls, creaking floors, wading, puddle stepping

 

 

Music: List all the music required in the game and where it will be used. Describe the mood and other subtleties. Music will often reuse the same themes and melodies. Mention where these themes should be reused. Consult the composer on this.

Event Jingles: Success/failure/death/victory/discovery etc.

Shell Screen: Mood setting for title screens, credits, end game

Level Theme: Level specific music (designers choose the theme)

Situations: Sets the mood for situations (lurking danger, combat, discovery)

Cinematic Soundtracks

 

 

5 Story (if applicable)

 

Write the synopsis of the story told by the game. Include the back-story and detailed character descriptions if it helps. Indicate the game text and dialogue requirements so they can be added to the schedule.

 

 

 

 

 

 

6 Level Requirements

 

 

 

 

7 Game Demo Ė pass/fail

 

The 1st playable demo is a crucial milestone in the project Ė it will determine whether the game concept is successful. The key features (the essence of the game) needed for this demo are to be listed. All team members must be aware of these features.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Common Mistakes

Here are some common mistakes to look out for:

         Poor layout Ė make it readable! .

         Plenty of white space

         Serif font for body text

         Bold headers

         Spaces between paragraphs

         Short lines of text

         Direct the eye towards important material