1. A Crash Course In Game Design and Production - Part 1

A Crash Course in Game Design and Production
           Week 1 - Part 1 - A General Introduction To The Course

Hi, and welcome to our class.  Over the course of the next several weeks,
we will cover material that applies to ALL areas of software design and
production, as well as issues peculiar to game design.  My purpose is
two fold:

1) To show the importance of planning the project BEFORE you start coding.
2) To take you though all the steps in software production, from a
   vague game idea to a completed, commercial quality game ready to market.

Along the way, we'll cover topics including:

* Human Interface Issues - Player controls and feedback systems

* Artificial Intelligence
  What will cause the actor to act, how will he know to act, what will his
  action be, and how do we make him do it

* Sprite Animation
  How to draw the right sprite when

* Using Virtual Screens
  Drawing all the sprites off screen, merging them with backgrounds and
  eachother, then redrawing only the portion of the screen you need to

* Play balancing
  Making the game challenging, but not too hard for a novice to play

* Bug Reports and Quality Assurance Testing
  The difference between an "alpha" and a "beta" Who to give betas to and how
  to report "undocumented features"

* Copyright notices and disclaimers

* Programming issues, milestones, and overcoming problems

The format for this course will be as follows: Each week I will put up
lesson text and sample code on the listserver, and an HTML version
with sample images, code and archives on http://exo.com/~lgp/euphoria
After each lesson is presented, I'll open the floor for discussion on the
topics presented, questions for more clarifications, comments, suggestions
or whatever. Send group interest messages to the listserver and other
feedback to me, lgp at exo.com.  I will also have a Q&A page on my site
documenting all questions and responses.

As with all software projects, there is no way to know for sure when we'll
have it completed, but we're gonna set a deadline anyway.  Our deadline is
January 1st.  I know it seems like a long way away now, but believe me, when
we're up at 3am on dec 30 trying to figure out by "blinky" is spinning around
and around in the middle of the screen on level 6 only after you eat your
3rd energizer (whichever one it is) it won't.

I'll tell you now, it's going to be awhile (at least 6 weeks) before we write
a single line of code. Game designers have a lot to do before programming can
begin.  By the time we start coding, we MUST know EVERY STINKING DETAIL about
our game, what will be on every screen, how they work, how we will do our
animations, how we'll program the AI, when to draw what and how, everything.
We'll be dreaming about coding before we actually do.  When we are at that
point, actually coding the game will be cake.  Conversely, when you are NOT
at that point, coding the game can be a nightmare.  I've worked on a LOT
of nightmare projects.

So strap yourself in, we're ready to rock!
                  Week 1 - Part 2 - What IS a game design?
Game Ideas Vs Game Designs
I hear people talking all the time about the games they are "going to" write
someday.  Most of these people NEVER actually write anything worthwhile.
They may START something, but soon get overwhelmed in speghetti code trying
to patch in a feature they realized they needed two weeks in.  Often they
toss the "Ultimate Game" aside in disgust and chase easier projects. It's
not because they had a bad IDEA, it's because they had NO PLANNING before
they started.  If you don't know what you need before you need it, adding it
later can be a nightmare.

That is the purpose of GAME DESIGN, you force you to think about all (as much
as you can anyway) aspects of your game in meticulous detail and document
what you decide and how you intend to accomplish it. It forces you to go step
by step through every screen, action, and reaction.  When you get done with
a game design, you should know EVERYTHING about YOUR game.

Let's say we have this great idea for a game:

 "Ok, this little yellow guy runs through a maze and eats these little dots
  while avoiding 4 cute little monsters, every level it gets faster until
  you can't play any more"

Even if you see it clearly in your mind, put it clearly on paper. Think about
the game, how it starts, how it ends, what happens at each stage.  You need
to spell it all out:

* How big are the characters?
* What do they look like?
* How big is the maze?
* What graphics mode will we be in?
* How fast will the monsters and player go at start and how will that change?
* How will we know the level is over?
* What will the monsters look like and how will they act\react to the player?
* What are the controls?
* Are there any player initiated controls that will change the monster's
  behavior? (like energizers)
* How will the monsters KNOW when this happens, and how will their behavior
* How will we score this game?

The questions go on and on.  You MUST decide these things BEFORE you write a
line of code.

Ok, you're probably saying to yourself, "wait a minute, how can you know all
the programming issues\problems before you start?" Fair question.  The answer
is, obviously, you can't.  There ARE GOING to be programming difficulties in
any project. The point is if we know the kinds of things we need to do in
the code before we write it, we can avoid as many of the difficulties as
possible.  Often during the later stages of design, I prototype routines to
get a feel for the kinds of data structures I need, and avoid any immediate
hazards in the road.  We're still going to be trouble shooting and tweaking
our code to adjust for things we missed in the initial design, especially
when we get to the AI programming.  It happens.

Anatomy of a Game Design Specification
A completed game design is called a Game Design Specification or SPEC, and
it contains at least the following:

A) Project CodeName - Every game has a codename to designate it during
   production.  This usually isn't what the game is finally named on
   release, marketing people love to change names at will.  We will
   choose our project codename next week.

B) General Description - This is a general overview of the game, what it's
   like, how it works, what happens on each level, etc.  We start with the
   original Game IDEA, then fill in the blanks enough that anyone reading
   it will know what we are talking about. We will start writing this next

C) Screen Description and User Interface Specification - What screens do we
   need for the game, what will they look like, How will they work, how will
   the player interact with them and what feedback systems will be available
   to let the player know his status.  Each screen is treated individually
   and explained, including mock up screen shots wherever possible.

D) Art Specification - What graphics elements do we need?  What Characters
   do we need, what personality traits do we need to show in the art,
   how big are they, what animations do they need, etc.?  What do the
   graphics screens look like, and how big, number of colors? What kind of
   font do we need? How big, colors, etc. What WORD graphics do we need?

E) Sound and Music Specification - What kinds of sound effects (SFX) do we
   need?  Intro and\or Intermission music? What file formats will we
   support?  How are we going to do sound?  This is the only real weakness
   in Euphoria as far as game development is concerned.  PC speaker
   is really inadaquate for most games, but we'll do what we can.  I have
   programming specs for adlib, soundblaster, etc.  If we can find an
   adventurous person to try and get soundcard support working, I think we
   will all be VERY happy.

F) Paradigm Specification - How are we going to do this project?  What
   approach will we take?  What functions and procedures do we need? What
   information will they need? In what order do we draw the sprites? How
   often do we update the feedback screens? Speed controls?  Once we answer
   these kinds of questions, we flowchart the game from the player starting,
   through all the options screens, to playing the game, what happens each
   animation frame in order, how we end the game, how we restart the game or
   leave the program.

G) Artificial Intelligence Specification - What our characters need to know,
   how they will find out, and what they will do once they know it.  This is
   kinda fun, as we have to figure out ways they will know what is happening
   around them.  It's even more fun when Blinky keeps bouncing off the same
   wall over and over because you missed something when you spec'ed him out.

G) Legal Stuff - Copyright notices, non-disclosure agreements, etc.  We
   won't worry about this too much, as this project is a public domain,
   group effort, but we'll cover the material anyway for completeness sake
   and I'm sure some of you are interested in this.

We'll be covering each of these parts in detail over the next several weeks,
applying the material toward our group project, which will be an interesting
"pacman" clone with some nifty features added.

This a good place to stop.  Tune in next week for more.
End of Part 1 - General introduction to the Course and Intro to Game Design

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

      A Crash Course in Game Design and Production - Euphoria Edition
     (C) Copyright 1996 Lord Generic Productions - All Rights Reserved

new topic     » topic index » view message » categorize


Quick Links

User menu

Not signed in.

Misc Menu