Lord Generic Productions

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 www.BeRighteous.com/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, Pastor@BeRighteous.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 September 1st. I know it seems like a long way away now, but believe me, when we're up at 3am on August 31 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 change?
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:

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.
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 week.
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.
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?
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.
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.
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.
Legal Stuf
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, 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