Lord Generic Productions
A Crash Course in Game Design and Production
Week 2 - From Vague Idea to General Description
Welcome back! This is the second installment in "A Crash Course
in Game Design and Production. The purpose of this lesson is to
introduce you to our course project, and to go through the process of
"filling in the details" between our initial GAME IDEA
to our project blueprint, the GENERAL DESCRIPTION. We cover a
lot of material this week, so I'm splitting this lesson into 4
pieces. This is part 1 of 4:
Before we begin, we need to start thinking about what we're going to
call our project:
Part 1a - Your Project Codename and You
Last week, in our ANATOMY OF A GAME DESIGN SPECIFICATION, the
first thing on the list was the PROJECT CODENAME. It is
extremely important to choose a name to designate a game project as
early as possible in the design process. When you name something, it
becomes real in your mind. It's a new being that you are commiting
yourself to creating out of thin air. It's existance completely
depends on your direct involvment. You can't give up on it now, it
won't survive without you.
It seems like a silly thing, but there is power in a name. If you
always talk about the project by name, you become attached to the
project, and you're more likely to stick with it, even when you're
knee deep in code trying to track down something really nasty.
The Project Codename is also called the "Working Title,"
meaning that it's the best name we're come up with so far, and it's
subject to change at any time. I was on a project (for
activision\infocom) that was called
"Orb Quest", "Kings Quest", "Quest to be
King", "Orb Warriors", "Rune Warriors",
"Rune Quest", and "IFGRPG" (Infocom's First
Graphical Role Playing Game" at different points in production.
I feel it is better to separate the Project Codename from the Working
Title if possible. It avoids a lot of confusion. Pick a Codename and
use it throughout production, then when you're close to release, you
can debate other names.
Also, the Project Codename doesn't have to relate to the actual game
in any way at all. Often in the software industry, Project Codenames
relate to external events, deadlines, or the designer's pets.
Example: Windows 95 was called "Chicago" because it was to
be unveiled at 1994 Summer CES in Chicago. Sometimes, Codenames are
chosen to intentionally mislead the competition in the event of a
security leak. I've worked on projects named "The Secret
Project" - ooh, big giveaway there!
Group Participation Assignment #1: The game we're producing
during this course is intended to be a GROUP project. As such, you
all have input as to what we're going to name it. As you go through
the rest of this lesson, start thinking about a Project Codename, and
post your suggestions on the listserver or e-mail them to me, Pastor@BeRighteous.com.
We'll vote on a codename later this week. My suggestion is
"Snack Attack," after my favorite Apple II Pacman clone,
where I "lifted" some of the features we'll describe later
in the lesson.
Part 1b - What the General Description IS and how we write it
The General Description is THE MOST IMPORTANT PART of the Game
Design Specification. It is the blueprint from which all the other
specifications (Screen, User Interface, Art, Paradigm, AI, etc.) are
derived. Every game idea and feature, all the things covered in the
other specifications, are first defined and described here. Its a
"Running Overview" of the project, and is open ended - you
can add, refine, or change it at any time up until you start coding.
If you have a new idea or refinment while writing one of the other
specs, you describe it in the General Description.
When you start coding your game, you will refer to the General
Description constantly. It is the gauge you use to measure how far
along you are, and what still still needs to be done.
The General Description is a complete description of the game. It describes
ALL PARTS of the game from the player's perspective:
* What he's supposed to know BEFORE he starts playing
* What he sees
* What he does
* His intended reaction to what he sees and does
Your Project Notebook
Ok, how do I get all that information? It's in your Project Notebook!
Buy a bound notbook, or folder with a pad of paper in it, and label
it with your Project Codename. This is your Project Notebook.
Your Project Notebook is your life. Take it with you everywhere you
go. You never know when a brainstorm, idea, question, or fundimental
design flaw will pop into your mind. Document everything that you
think of, especially the problems you don't know how to solve. You'll
be surprised how often an insurmountable problem is a trivial matter
to solve just a few days down the road. You'll hear or see something
that will click in your head and "Whoomp!" there it is.
Keep your Notebook nearby when you are playing competing products and
take notes. Go somewhere where you can be alone with your game for a
period of time without distractions. I sometimes go to Taco Bell and
sit there for hours with my Project Notebook and free drink refills.
The time flys.
Anatomy of a General Description
You'd think you were studying to be a doctor, all the anatomies
you're getting. (yes, there will be at least one in each of the next
few lessons) A General Description contains at least the following:
The Backstory (RPG's MUST HAVE THIS, optional for most
This sets the stage for the game, the world it takes place in, what
has happened in the past that led up to where the game starts, what
caused the player's character to get to where he is at the beginning
of the game. Before you do anything else designwise, sit down for a
week and live in the world you are going to simulate in your game.
Write down all you learn about this world.
- Introduction to the Game
This is a brief description of the game, and the cast of characters.
Name each character and describe its attributes.
- Feature list
What innovative technology is used in the game, what sets it apart
from other games in its genre? This is useful because it makes you
look for nifty new features, and referring to it reminds you of the
nifty new features when you're feeling discouraged.
BEWARE of CREAPING FEATURISM - Don't go nuts on new features,
it makes programming a nightmare and too many options makes a game
less fun. Really, Space Invaders doesn't need a Hyperspace Button!
- Definitions and Descriptions
Here we define all the terms used here and in the other specs that
make up the Game Design Spec, including objects of interest and Game
Goal objects. We describe their use and availability, and how game
characters react to them or interact with them.
- Introduction, Title Page, Attention Getter, self running demo, etc.
This is what the player sees when he first starts the program. All
games need an attention getting title sequence. This is a description
of what it's supposed to look like.
Game selection screen
What options are available to the player on game startup? This
describes what options are on the menu, how and where it appears on
what screen, how the player gets there, and how he gets out.
- Game start screen
What does the screen look like at beginning of game, what are the
startup parameters, where are the characters, etc.? What messages, if
any, are on screen, and where? Intro music? SFX?
- Game play
How is the game played? What are the controls? What is the Game Goal?
How is the player going to achieve the Game Goal? This can be the
longest section of the whole Design Spec. Spell everything out in
- Game Levels
What do they look like? How does the difficulty increase? How does a
level end? How does the player know what level he's on?
- Milestone Events in Game
Every once in awhile, the player needs to be rewarded (or PENALIZED)
somehow for reaching that point in the game. Each of these places
where something special happens is called a Milestone Event. They are
a guage to let the player know he's on the right (or WRONG)
track, and will encourage (or DISCOURAGE) him to keep going.
Here we list what those Events are, and what happens to the player
when he reaches them.
- End of the Game
What happens when the player loses? What happens when the player
wins? What happens when the player gets a high score? Where does the
player go when the game is over? How does he start a new game?
- Game exit
What does the player see when he decides to exit the game? This could
be nothing - drop to a blank screen in dos, or it could be five
screens of ordering information, or a "You are a wimp for
quitting!" message on the screen.
Pretty detailed huh? It has to be. Remember what I said in lesson
one: YOU MUST KNOW EVERY STINKING DETAIL ABOUT YOUR GAME BEFORE
YOU START CODING. By the time you get finished(?) writing the
General Description, you'll have described everything the player sees
and does, what everything looks like, what happens at every stage of
the game. You'll be ready to tackle the other parts of the Design Spec.
End of Lesson 2 - From Vague Idea to General Description - Part 1
If you have any questions for group discussion, or if you have any
questions, comments or suggestions email them to pastor@BeRighteous.com
Mail monetary donations large or small to:
Lord Generic Productions 1218 Karen Ave Santa Ana, Ca 92704
A Crash Course in Game Design and Production - Euphoria Edition
(C) Copyright 1996,2001 Michael Packard - All Rights Reserved