1. A Crash Course In Game Design And Production Week 2 - Part 1
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, lgp at exo.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 other games)
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 gross detail.
* 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 of 4
If you have any questions for group discussion post them to the list server.
E-mail any other questions, comments or suggestions to lgp at exo.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 Lord Generic Productions - All Rights Reserved
===========================================================================
