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 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, or if you have any other
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