Game Programming '98 Staff Note :
These tutorials were obtained from :
http://server.exo.com/~lgp/euphoria/crash.htm.
The author has done a wonderful job and should be commended. In hopes that
these articles don't mysteriously find the same fate many programming articles
do (stored away and long forgotten on someones hard drive), I have posted
them here.
If you like them and they are useful to you, it would be really appreciated
if you'd send a donation large or small (even $10 would be be nice) to
Lord Generic Productions
1218 Karen Ave
Santa Ana, Ca 92704
Enjoy!
TABLE OF CONTENTS :
- Week 1 -
A general Introduction to the Course and
Anatomy of a Game Design Specification
- Week 2 -
From Vague Idea to General Description -
Part 1 - Project Codename and Anatomy of
the General Description
- Week 3 -
Screen Design and User Interface Specification -
Part 1 - The Basics of Screen Design and User
interface Issues
- Week 4 -
The Basics of Computer Art and Art Specification -
Part 1 - The Basics of of Computer Art
- Week 5 -
The Sound and Music Specification -
Part 1 - The Basics of Sound Reproduction on
the Computer
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@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
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:
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
week.
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@exo.com
A Crash Course in Game Design and Production - Euphoria Edition
(C) Copyright 1996 Lord Generic Productions - All Rights Reserved
============================================================================
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@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@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
============================================================================
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 2 of 4:
---------------------------------------------------------------------------
Part 2 - Our Course Project - General Description
BackStory, Introduction, Characters, Features, Definitions, and Descriptions
============================================================================
Ok, here's what the General Description Looks like for our course project:
[NOTE needs no BackStory. It's pretty self explanitory. If ]
[a member of the class wants to write something humorous that would tie ]
[into the theme of the game, and we vote to include it, I will put it here ]
Introduction
is a "PacMan" style game, where the player runs through
maze after maze eating "dots" while avoiding four "Ghosts" who are intent
on "killing" the player's character. When a "Ghost" "catches" the player,
He is "killed" and loses one of his "lives." When the player eats all the
"dots" on a level, he advances to the next level and continues playing until
he loses his last "life." Between mazes two and three, and every three mazes
thereafter a short animated "Intermission" sequences play as reward
milestones. When the player reaches a score of 10,000 and 50,000 points, he
receives an extra "life" as a bonus milestone.
Cast of Characters
Player - "Packy" - He's round and yellow and eats dots
As he moves, he faces the direction he's moving and
his mouth opens and closes in a simulate chomping
Ghost 1 - "Inky" - He's baby blue
Ghost 2 - "Blinky" - He's red
Ghost 3 - "Pinky" - She's bright pink with red lips
Ghost 4 - "Clyde" - He's orange
Ghosts are cute and have big eyes that "look" the direction they are moving.
As they move, their "feet" animate in a shuffling motion. Ghosts don't rotate
when they change direction like Packy does. When under the influence of an
"Energizer" the ghosts turn a "distressed" blue color and are vulnerable for
a limited time.
[ NOTE I was thinking seriously of making them turn pastel pink and grow ]
[ Bunny ears, but the sprite size is too small. ]
Game Features
* Energizers - Allow Packy to "eat" ghosts, removing them temporarily from
his area and giving the player bonus points for each Ghost "eaten."
An Energizer's effect is of limited duration and is evidenced by changing
the appearance of the Ghosts while they are vulnerable.
* Sugar Rush - A limited duration burst of speed allowing Packy to escape
the Ghosts, or catch them if they are under the influence of an Energizer.
* Safe Zones - Areas where Packy can enter, but the Ghosts can't!
* Trap Doors - Doors that Ghosts can go through that Packy can't, in order
to trap him!
* Bonus Objects - Objects that wander through the maze that will give the
player bonus points if Packy "eats" them.
* PowerUps - Objects that appear that will give the player bonus points and
give Packy a tactical advantage against the Ghosts.
* PowerDowns - Objects that appear at "bad times", taking points AWAY from
the player and giving Packy a tactical disadvantage against the Ghosts.
[NOTE This is funny]
* Pull Down Menus with easy keyboard or mouse controls
* Game control via keyboard or joystick
Definitions
===========
"Penalty Box" - At the beginning of each level, all four Ghosts are in
a box shaped area called the Penalty Box. They exit the Box in single file,
then wander the maze in search of Packy. Whenever a Ghost is "Killed"
in the game, his eyes wander from where he was killed, back to the Penalty
Box and he is reincarnated.
"Energized Ghost" "Non-Energized Ghost" - Whenever packy "eats" an
"energizer" (see above), the Ghosts turn blue and become vulnerable for
a limited duration. During that time, they are "Energized Ghosts." After
a level related time interval, the Ghosts return to their normal,
invulnerable, hostile state. Then they are "Non-Energized Ghosts"
"Eat" "Eating" "Being Eaten" - As Packy moves around the maze, his mouth
opens and closes. Whenever he moves over a screen object, dot, bonus object,
energizer or "Energized" Ghost, they disappear from the screen. They have
been "eaten" by Packy.
"Dot" - At the beginning of each level, there are small, round objects
distributed evenly across the play area. These are "dots." Packy must
eat all the dots on a level to complete it.
"Life" "Lives" - One "life" is one chance to complete the maze and continue
playing the game. The player begins the game with three lives, and gets
a bonus life at 10,000 and 50,000 points. The player loses a life when he
is "Killed" by a Ghost.
"Kill" "Killed" "Killing" - Whenever a non-energized Ghost and Packy occupy
thedame space at the same time, Packy is "Killed" by the Ghost. Whenever
Packy is Killed, he loses one Life, and if he has any lifes left, the level
begins again with the Ghosts and Packy in their Level Start positions.
If Packy EATS an energized Ghost, it is Killed, its eyes wander back to the
Penalty Box and he is reincarnated.
Object Descriptions
===================
Bonus Objects
Pumpkin - Its orange and looks like a Jack o Lantern. Player gets 200
points for eating a Pumpkin.
[Group Assignment #2 - I want suggestions from the group as to other Bonus ]
[ objects, and point values. We'll vote on them later this week. ]
Powerup Objects - Garlic and Towel are of limited duration.
Candy Bar - Recharges Packys "Sugar Rush" capability to full strength.
Garlic - Makes Ghosts run away from Packy.
Towel - Covers Packys eyes, so Ghosts can't see him.
PowerDown Objects - These are all limited duration.
Steak - Makes Packy slow and sluggish.
BreathMint- Makes Packy Irresistable. Ghosts take the most direct route to
him at 1 1/2 times normal speed.
Popsicle - Gives Packy "brain-freeze," making him hesitate between actions.
Mushroom - Magic Mushroom, makes Packy "stoned" and causes him to wander
aimlessly for awhile, changing direction at random.
============================================================================
End of Lesson 2 - From Vague Idea to General Description - Part 2 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@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
============================================================================
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 3 of 4:
----------------------------------------------------------------------------
Part 3 - Our Course Project - General Description B
Title screen, Demo, Game Selection Screen, Game Start, Game play
============================================================================
Title Screen and Attention Getter
When the player starts the program from Dos, the screen is cleared to BLACK.
Then the Game Title appears in color cycling 3D letters on a big sign with
"chaser lights" animating around it. Under the sign the words "Presented
by:", "Lord Generic Productions","And","Euphoria Game Design Team"
"Starring:" "Inky", "Blinky", "Pinky", "Clyde" ,"and Packy" appear in
sequence. While each character's name is presented, (s)he appears on
alternating sides of the screen and move toward the sign and stop. Packy
appears under the sign, between it and his name. All characters are
animating, and continue to animate throughout the entire sequence.
During this initial sequence, Program "About" information, including
Game Title, Designer, Artist,...,begin scrolling across the bottom of the
screen in a one-line high animated "strip sign" and continue scrolling until
Play Game is selected.
After all the characters are introduced, the Game Selection Box appears in
the lower 1/3 of the screen, and the player can select "New Game" "Options"
or "About this Game." Also if at anytime during the intro animation the
player presses a key, the screen is redrawn with all characters in their
final position, and the Game selection screen appears.
----------------------------------------------------------------------------
Self-Running Demo
If the player doesn't hit a key within 30 seconds after the Game Selection
Box appears, the game goes into demo mode. The Game Screen draws and one of
three "pre-recorded" games is replayed until packy is killed by a ghost or
until the player hits a key. If the player hit a key, the screen switches
back to the title page\game selection screen and he can continue. Otherwise
the "About" screen animations play, then the "Attention Getter" Title
sequence starts over.
----------------------------------------------------------------------------
"About This Game" Screen
If this is called from the Title Screen, the screen is cleared to medium
blue and the sequence starts. If this is called during a game or after the
Self-Running Demo, the "Game Window" is cleared to medium blue and this
sequence plays there.
The "About this game" credits split into three pages of text, the first
page has design, art, LGP, and EGDT credits on it. The second page has
Contributing Authors and Course Information. Page three has "For more
information" info on Euphoria, the Course, and LGP. At the bottom of each
page is a "Press a Key to Continue" message, and the player hits a key to
step through them. If the player does nothing the screen advances after
thirty seconds or so. After the last screen, the program goes back to
wherever called it.
While the player is reading the text, Packy is chased around the screen VERY
fast by the four Ghosts.
---------------------------------------------------------------------------
Game Options screen
The Player can choose the following configuration options:
Number of players - This can be one or two.
Sound - This can be ON or OFF.
Controls - The can be Keyboard or Joystick (maybe mouse)
Skill Level - This can be Easy, Medium, Hard, or Nuts
Starting Maze # - This can be 1-4
Exit - Takes you back to where you came from
---------------------------------------------------------------------------
Beginning a new game
When New Game is Selected, the screen is cleared, the Game Screen is Drawn.
The Game Screen has 3 parts they are:
1) Pull-Down Menu Bar - It is invisible until the player hits the ALT key.
It has options such as New Game, Resume Game, Quit, Options, and About
which take the player to the appropriate screen.
2) Game Window - This is where the Game is played, and where the About This
Game sequence plays. At Game Start, it is cleared, and the Maze and dots
are drawn. Inky, Blinky, Pinky, and Clyde are placed in the penalty box,
and Packy is placed in one of 4(?) starting positions in the Maze. The
Energizers are placed in the corners of the Maze, and begin animating.
3) Game Status Window - This is next to the Game window and is where the
player's Score and Number of Lives left is displayed. At Game Start,
the appropriate player's score is set to 000000 and his lives is set to
three. Packy's "Sugar Rush" level is set to 100%
After the Game Screen in drawn, "Level 1" appears in a chaser-lighted sign
momentarily in the middle of the Game Window, then disappears. The Level
Number is also drawn inside the Penalty Box, (behind the Ghosts) so the
player can always see what level he's on. As the Level sign is onscreen,
the "get ready" music plays. When the music is over, the Sign disappears
too. And the game begins.
---------------------------------------------------------------------------
Game play
When the game begins, the Ghosts leave the Penalty Box one at a time,
Blinky first, followed by Pinky, Inky, and Clyde. They wander the maze
in dogged persuit of Packy. Player controls Packy with the Joystick,
Arrow keys, or "Snack Attack Keys", AZ,. [SPACE] stops Packy wherever
he is. He continues to "Chomp in place" until he is moved again. Pressing
[ENTER] Gives Packy a "Sugar Rush," which allows him to move at twice(?)
normal speed for a limited duration, up to 10 seconds per level, unless
recharged by a Candy Bar. Pressing the [ENTER] key again returns Packy to
normal speed. The Sugar Rush can be used again until Packy's Sugar Rush
Level is 0%
The Player's Primary Game Goal is to eat all the dots in the maze. When he
has eaten all the dots, the level is over.
The Player's Secondary Game Goal is to eat as many Ghosts as he can by
strategic use of the Energizers. When Packy eats an Energizer, the Ghosts
become "edible" for a short period of time and will give the player a bonus
that increases with the number of Ghosts eaten in rapid succession, as:
First Ghost - 200 points
Second Ghost - 400 points
Third Ghost - 800 points
Fourth Ghost - 1600 points
When a Ghost is eaten, he disappears, and his "eyes" appear. They wander
back to the penalty box very fast and once inside, the Ghost "reincarnates"
inside the Penalty Box. The Ghost stays inside, pacing back and forth until
his "Penalty Time" is completed, then he emerges from the box and continues
his persuit. If there are Ghosts inside the Penalty Box when Packy eats an
Energizer, they also are affected, but no Ghosts reincarnated while that
Energizer is active is affected. It is possible for the player to time his
moves so that Packy can eat an Energizer, eat one or more Ghosts, then eat
another Energizer and get to the Penalty Box in time to catch the newly
reincarnated Ghosts as they try to leave.
After a period of time, the effect of the energizer wears off and the Ghosts
become lethal again. This change is evidenced by the Ghosts "Flashing"
five times between their normal and Energized images. During this
transition period, the Ghosts are still edible, but chasing down a flashing
Ghost is a High Risk activity. If the player's timing is off, and he catches
up to the ghost too late, he's killed. The duration of an Energizer's
effect decreases by the level the Player is on:
Level 1 - 10 seconds
Level 2 - 8 seconds
Level 3 - 6 seconds
Level 4 - 4 seconds
Level 5 - 2 seconds
The last two seconds of each duration are transition periods where the
Ghosts are "Flashing." From level 5 on the Ghosts begin flashing right away.
If Packy eats another Energizer while the last one is active, the Ghosts
that were affected by the first one will continue to be affected for the
entire duration of the second Energizer.
The Player's Tertiary Game Goal is to eat Bonus Objects which appear in the
Maze from time to time, giving the player bonus points. Each Level has a
different Bonus Object associated with it, with the Bonus Point Value
increasing with each level. The Bonus Objects are animated.
Level Object Point Value Animation
Level 1 Pumpkin 50 Blinks its eyes
Level 2 100
:
:
============================================================================
End of Lesson 2 - From Vague Idea to General Description - Part 3 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@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
============================================================================
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 4 of 4:
----------------------------------------------------------------------------
Part 4 - Our Course Project - General Description C
PowerUps PowerDowns Game Levels, Milestone Events, End of Game, Game Exit
============================================================================
PowerUps
Every once in awhile, a PowerUp object will appear in the maze. If Packy
eats it, he will have a tactical advantage over the Ghosts for a limited
duration. The duration of effect decreases as the level increases, just
like the Energizers.
PowerDowns
Every once in awhile, a PowerDown object will appear in the maze. If Packy
eats it, he will have a tactical disadvantage over the Ghosts for a limited
duration. The duration of effect decreases as the level increases to keep
the game from becoming too hard. The duration follows the same chart as
Energizers and PowerUps.
Game Levels
Each "Level" is one maze that the Player guides Packy through. When he
eats the last dot in that maze, the Player has "Completed" the Level and
advances in the game, either to the next maze or to a Milestone Event
Animation and then to the next maze.
There will be five different maze layouts the player must navigate in the
game, each requiring its own strategies to complete. Packy can start any
maze in any of four locations.
The Maze changes after level 2 then every 3 mazes after that. The starting
Maze is chosen at random from the 5 designs. Once a Maze is used we
don't see it again until all the other Mazes have cycled through.
Inside the Penalty Box of each maze, "Level X" is displayed, where X is
the current Level number, so the player knows what level he's on.
As the game progresses from level to level, the difficulty increases. This
is achieved by increasing the speed of Packy and the Ghosts, and Decreasing
the duration of Energizers and PowerUps. PowerDowns also decrease in
duration to keep the game fair.
Character Speed by Level
Level 1 1 pixel per animation frame
Level 2 1.5 pixels
Level 3 2 pixels
Level 4 2.5 pixels
Level 5 3 pixels
Each additional Level add .5 pixels to the character speed.
Milestone Event Animations
After Level 2 and every 3 Levels thereafter, there is an "Intermission"
animation. Each is about 10 seconds long and is humorous. There will
be 10 animated sequences, one of these will be selected at random and
played at each milestone event. After an animation is played, it cannot
be selected again until all the other animations have cycled through
See Milestone Animation Specification for details on each animation.
=====================================================================
Group Participation Assignment #3
We need 10 animations, start brainstorming ideas.
=====================================================================
End of the Game
The Game ends when the player loses all of his Lives. At that point,
Words "Game Over" appear in a Marquee Sign. If the player doesn't have a
hi-score on the list, the sign changes to "You Suck, try again!"
[Note: I just wanted to see if you are paying attention]
If the player made the High-Score list, the Sign says "You made High-Score
# ___! Enter your Name:" Then the player can enter his name. When he hits
[ENTER] His name and score are drawn in the High-Score Box in the Status
Window, and the Sign changes to "Play Again YES NO." If the player
chooses to play again, everything is reset and a New Game begins.
If the player chooses NOT to play another game, the screen clears and we
go back to the Title\Game Select Screen and the program waits for input
and goes through the demo cycle.
Game Exit
If the player chooses to exit to Dos, the program goes to the "About this
Game" sequence, then switches screen to text mode, displays an ansi "Thank
you for playing this Game" message and drops the player back in Dos
=========================End of General Description=========================
ok that's it. By now you know just about as much about our course project
as I do. If you have any questions, or if I've left out anything we need
to have spelled out, post them to the listserver or e-mail them to me.
Do you see the method behind the madness here? Now if we ever have a
question about the game, we know where to look to get the answer. If there
is NO answer, we DECIDE the answer and add it to the General Description.
Next week we Spec out the Screens and User-Interface. It will probably be
a two parter. It seems like a good idea to separate theory from practice
in these. The first part will tell you about what we're doing and what
kinds of information we need to put in the Spec, then parts 2-N will be
the actual Spec for our project. As we add new parts and update old ones,
I will revise the files on the Web site, so the current verion is always
there.
By the way, this game looks like its going to be a LOT of fun to play. I've
always enjoyed PacMan Variants. This should top anything I've seen.
I'm toying with the idea of having a Maze Editor available. I'm Specing
that out now. It won't be part of the course, but would be pretty handy
to have when we get to the mazes. If any of you want to work on a side
project and build it for us, let me know.
============================================================================
End of Lesson 2 - From Vague Idea to General Description - Part 4 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@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
============================================================================
A Crash Course in Game Design and Production
========================================================
Week 3 - Screen Design and User Interface Specification
========================================================
Welcome back! This is the third installment in "A Crash Course in Game Design
and Production. Like last time, this lesson is in two parts. In PART ONE,
we'll discuss Screen Layout and User Interface issues. In PART TWO We'll
write the third part of the Design Spec for our Course Project, the Screen
Design and User Interface Specification.
------------------------------------------------------------------------------
Part 1 - The Basics of Screen Design and User Interface Issues
------------------------------------------------------------------------------
What is a "Screen Design?"
===================================
A Screen Design is just a plan for how and where you intend to put things on
the screen. There are usually many things you need to put on the screen, such
as the player's score, number of lives left, Game Logo, level number,
information messages, or whatever. It's your job as the Game Designer to
determine what items need to be on the game screen, what they will look like,
and where they need to go. Good Screen Design takes practice, and you will
usually go through four or five designs before you get it "right."
How do you DO Screen Design?
============================
The first step in screen design is referring back to the General Description
to see what screens we NEED to design, what NEEDS to be on each screen, and if
elements need to move around, what are they doing?
[Note: Often I do this backwards, I do a rough screen design\layout to see
WHAT I NEED TO INCLUDE IN THE GENERAL DESCRIPTION. Most of the time when I
get to the Screen Design Spec, I already have all the screens drawn up and
then just have to describe what's there in the Screen Design Spec.]
Make a detailed list for each screen, go over it in your mind and elaborate
and expand on what was in the General Description. The General Description is
a starting point, a quickie overview of what you will include in the Screen
Design Spec. Now it's time to fill in the details.
User Interface items
====================
Parts of the User Interface include Pull Down Menus, screen "windows," player
information - scores, number of lives, etc, system messages, about box, etc.
you need to figure out what these should look like and where they need to go.
We'll discuss HOW these work below in the User Interface Specification
section, but its CRITICAL to place these items where they can be easily seen
by the player. The player should NEVER have to look for something, and should
NEVER have to "figure out" your interface works. "Standard" places for player
information are on the right side of the screen or at the top of the "play
screen" Pull Down menus are ALWAYS at the top left of the screen, with
New\resume game options on the left and Help\about on the right of the menu
bar.
The next step is to go into your paint program and figure out how big things
need to be and lay up a Mock Screen Shot of each screen.
[NOTE: I prefer using Autodesk Animator Pro for this. It handles all 256
color screen resolutions, allows you to set your image size, or clip a portion
of the screen and save it as an image, shows you screen coordinates when you
move things around, lets you scale and rotate pieces arbitrarily, has GREAT
color palette handling, will let you have multiple versions of the screen at
the same time, and will let you save in BMP format so you can load your images
into Euphoria. (it's native file format is GIF, which I prefer.) Find a
program you like using that has these features. Avoid Windows(tm) paint
programs, they will give you more trouble than they are worth. I'll tell you
why when we get to the Art Specification lesson.]
Draw mockup pieces in various sizes and try different screen layouts, go
through each animation in your head and try to see what each piece would be
and where it will end up on the screen. Move the pieces around until you get
a layout you like. Then write down how big everything is, and where it's
located on the screen.
Once you have all your mock up screens and notes, its time to write up the
Screen Design Spec.
Anatomy of a Screen Design Specification
========================================
Here's ANOTHER anatomy for you.
The first part of the Screen Design Specification is called the General
Design and Layout. It basically lists parts and features common to all
screens, including color scheme, border width, etc., followed by the General
Interface Specification (see below)
It also lists all the screens to follow with one-line descriptions condensed
from the General Description.
Then for EACH screen, the Screen Design Specification contains AT LEAST the
following:
* Screen Title
* Screen Description
Write in EVERYTHING you can think of about this screen, what information
needs to be on it, go step by step through any animation sequences, spell
everything out. Include player interaction and controls to exit the screen.
* Screen Layout
What goes where, and how big it is in pixels. Use coordinates for where
each piece resides, section by section through the layout. You will
need this information for the ART SPEC and when it comes time to write
the code to put it on the screen, you'll know what numbers to plug in to
the drawing routines.
* Screen exit
What happens when we exit this screen, where do we go?
* User Interface Specification
Since you need to define and explain your User Interface issues for EACH
SCREEN, it makes sense to make the User Interface Specification part of
the Screen Design Specification.
In Part Two of this lesson we'll show you the completed Screen Design spec
for each screen of our course project.
-----------------------------------------------------------------------------
What is a User Interface?
=========================
Your User Interface is the mechanism your game uses to get information to and
from the player. It consists generally of two parts: User Controls and
Feedback Systems.
* User Controls
Collectively, this is the set of controls the player used to affect the
program, including character movement\actions, pull down menu choices,
options screen controls, etc.
* Feedback Systems - These are anything that conveys information to the
player, such as his Score display, Number of Lives, Level Number,
Sound Effects (SFX), Visual Effects (FX), sound volume, text messages,
about box, etc.
The Key to intelligent User Interface Design is simplicity. Your feedback
systems must be crystal clear, and your User Controls must be easy for an
idiot to navigate without checking the manuals. If he has to think about how
to find the information he needs you've lost him. The idea is to get him
hooked and thinking about THE GAME and not THE INTERFACE.
MICHAEL'S RULES OF THUMB FOR USER INTERFACE DESIGN
==================================================
DON'T GET FANCY WITH YOUR USER CONTROLS OR FEEDBACK SYSTEMS JUST TO SEEM MORE
INTELLIGENT OR SOPHISTICATED. It seems pretentious. I once saw game that had
"Sound Attenuation" instead of a "Volume" control. It did the same thing only
backwards. When you turned UP the Attenuation, the volume went DOWN. That's
what "Attenuate" means, to reduce. The author was trying to make people think
the program was more sophisticated than it was.
DON'T DO THINGS JUST FOR THE SAKE OF DOING THEM. Just because you CAN do
something doesn't mean you SHOULD do something. Some programs have menus that
have sub-menus that have sub-menus that have sub-menus. While it's nifty to
have an interface engine capable of handling complex menu structures, it
wastes the player's time to have to wade through five levels of menus to
change something. It's also very frustrating for the player searching for
information he needs.
HAVE AS FEW MENUS AS POSSIBLE. It's better to have 5 menus with 10 items each
than 10 menus with five items each. Break down your controls into reasonable
categories, like game, options, sound, etc. then use those category names for
your pull down menus.
HAVE HOT-KEYS FOR EVERY COMMONLY-USED MENU CHOICE. A Hot-Key is a keyboard
shortcut to activate a menu item. Every option that will be regularly used
should have a Hot-Key. Examples: Q to Quit, N for New Game, S for Sound, A
for About, O for Options, etc.. It's better to have EVERY option Hot-Keyed,
but you don't see that often. You must at least have the Menu Names Hot-
Keyed, pressing the key bringing up the menu for you to choose an option from.
ALWAYS USE THE CONTROLS PEOPLE EXPECT YOU TO USE, AND PUT MENU OPTIONS WHERE
PEOPLE EXPECT TO FIND THEM. There are "standard" menu layouts and keyboard
commands that people EXPECT your game to use. For example, for most character
movement and actions, you WILL use the Arrow Cursor Keys, Ctrl, Alt, and Space
Bar. Text pages scroll with the up\down arrows and PGUP\PGDN. DON'T RE-INVENT
THE WHEEL, EVEN IF YOU DON'T LIKE IT. People hate having to learn new player
controls. It's easy to check your biggest competitor's game and use the same
controls they use for the same functions, and organize your menus roughly the
same way they do. More than likely, your audience is already playing THEIR
game, so the switch to YOUR game should be as painless as possible. If you
have a LOT of player control options, say for a fighting game, put them in a
logical keyboard layout, and let the player be able to customize the character
controls if possible.
IF YOUR PROGRAM IS MOUSE DRIVEN, MAKE ALL YOUR MENUS MOUSE CLICKABLE. Don't
EVER make your players use the mouse for some things and not other things.
EITHER YOUR PROGRAM IS MOUSE DRIVEN OR IT ISN'T. Nothing frustrates players
more than not being able to click on the item they want to select, when
they can click on other buttons on the SAME SCREEN. If you don't know how
to make EVERYTHING mousable, don't make ANYTHING mousable.
DON'T CLUTTER THE SCREEN WITH USELESS INFORMATION. You are probably keeping
track of more information than the player needs to know at any given time.
Only display what he NEEDS to know all the time, and make any information he
needs only once in a while a hot-key away. You can have a status box that has
multiple pages of information. Order the information on the pages by relevance
to the player let the player call up the page he needs, rather than having
everything on the screen at once. Instead of making him scan all over the
screen to find what he needs to know, he knows it's in the box, on page 3, so
he hits "3" on the keyboard and it pops up in the box.
-----------------------------------------------------------------------------
Anatomy of a User Interface Specification
=========================================
At the end of the General Screen Design and Layout is the General Interface
Specification, which describes the Interface issues common to all screens.
Then for each screen we need:
* Player Controls
Whatever the player can do on this screen, and how he does it. how he calls
up any menus, how he can select something, Character controls, What he does
to interact with the game.
* Menus, choices, and functions
If this screen has special menu options, what they are, how the player
changes those options, and how the game will let him know of those changes.
Example: When the player clicks the VOLUME + button, the sound volume
increases, the VOLUME BAR GRAPH gets longer and the SAMPLE TONE is
played at the NEW volume level.
* Feedback Systems
What player information is displayed on the screen, where it is, how will
how will the player access it? Also what FX, SFX are needed to alert the
player of his status when he reaches a Milestone Event in the game. Anything
from a printed score to a minute long cinematic animation is listed here in
gross detail.
In Part Two, I'll show you how the Screen Design and User Interface
Specification looks for our Course Project.
============================================================================
End of Week 3 - Screen Design and User Interface Specification
Part 1 - The Basics of Screen Design and User Interface Issues.
If you have any questions for group discussion post them to the list server.
E-mail any other questions, comments or suggestions to lgp@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
============================================================================
Week 3 part 2 is still pending. It should be available by Jan 25,1997
sorry for the delay.
============================================================================
A Crash Course in Game Design and Production
========================================================
Week 4 - Basics of Computer Art and Art Specification
========================================================
Welcome back! This is the fourth installment in "A Crash Course in Game
Design and Production. Like last time, this lesson is in multiple parts.
In PART ONE, we'll discuss computer graphics in general, and what we need to
know before we can talk about ART. In PART TWO We'll discuss the ART
Specification, what it is and what we need to put in it. In PART THREE we
will write the fourth section of the Design Spec for our Course Project, the
Art Specification.
----------------------------------------------------------------------------
Part 1 - The Basics of Computer Art.
----------------------------------------------------------------------------
Before we can have any meaningful discussion of computer game art, we need
to get some terms defined and some concepts explained. In this section we'll
talk briefly about Computer Graphics, Video Modes, Resolution, Aspect Ratio,
Pixels, Palettes, Masking, Sprites, Backgrounds, and Anti-aliasing, then
briefly about what to look for in a graphics\animation editing program from
a game design standpoint.
Video Modes
The computer is capable of displaying information in many formats: It could
be text, a picture, animation, or sound. For our purposes, we are working
with images. The Video Mode you use determines what kind of images you can
display, how big they can be, and how many colors the image may contain.
Video modes can be classified into two groups, Text or Graphics modes.
In Text modes, all you can display are letters and words. Not real useful
for most games. Language Wars is an example of a game written in Text mode.
Graphics modes allow you to display images and animations as well as text in
16 or 256 colors. There are multiple Graphics Modes to choose from, each
will allow you to display different amounts of data on the screen. Each
datum (singular of data, the smallest displayable chunk of information)is
shown on your monitor as a PIXEL (Picture Element - part of a Picture, an
image displayed on your screen.) A Full-Screen image in different video
modes contains more or less Pixels, and may contain more or less colors than
in other video modes.
Example:
Video Mode 18 can display an image that is 640 pixels wide and 480 pixels
high in up to 16 colors. Video Mode 19 can display an image that is 320
pixels wide and 200 pixels high, but in 256 colors. Video Mode 256 can
display an image that is 640 pixels wide and 480 pixels high in 256 colors.
Note: If you draw a Full-Screen picture in Mode 19 and display it in mode
256, say, the image will be about 1/4 the screen size now! Since the Video
Mode can display more Pixels, the Pixels themselves are smaller.
Resolution
When we discuss Video Modes, it is useful to refer to them by the number of
Pixels they can display Width x Height. Instead of saying "Mode 256" or
"Mode 18", we'll say "640x480 mode" with the number of colors implied. This
is called RESOLUTION. Similarly, Mode 19 is "320x200" and Mode 260 is
"1024x768." See graphics.e for a list of valid video mode for Euphoria.
When we talk about the Resolution of an IMAGE, we are referring to how wide
and how tall it is, not necessarily what Video Mode it was created in or
should be displayed in. For instance, in our class project, our characters
will be 15 pixels wide and 15 pixels high, so we'll call it a "15x15" image.
Aspect Ratio
The Aspect Ratio is the ratio of the Pixel Width to Pixel Height for a
particular video mode. In 640x480, 800x600, and 1024x768 modes, the aspect
ratio is 1:1 or 1, meaning the pixels are square. In 320x200, the aspect
ratio is 1.21:1 or .82, meaning the pixels are higher than they are wide.
If you create an image in 320x200 mode and display it in 640x480, it will
appear slightly squashed, since the pixels are 21% shorter in this mode
relative to their height than in 320x200 mode.
Pixels and Palettes
A picture on the screen is made up of different colored Pixels. The number
of colors available to the image is determined by the current Video Mode.
For 256 color Modes, there are 256 colors available. These colors are
stored in a table called the Color Palette. These 256 colors are chosen from
the VGA Palette of 262,144 colors.
Each Pixel can have a value from 0-255, which tells the video screen which
of the 256 colors in the Color Palette to display at that Pixel location.
The pixels themselves have NO COLOR INFORMATION, they just tell where to
look in the Color Palette to get the color you want. If you change the
colors in the Color Palette, any pixels that were assigned to those colors
also change. If you load an image created with one Color Palette and
display it using a different Color Palette, the colors will be wrong.
All art for your game MUST BE DRAWN USING THE SAME COLOR PALETTE. It's not
enough to have the same colors, they MUST be in the same color position in
the Color Palette. If you have two images, one with Blue, say in palette
position 5 and the other with the EXACT SAME SHADE OF BLUE in color position
18, if you display them together, the second Blue may appear GREEN,ORANGE,or
AVOCADO, depending on what is in color position 18 in the current Color
Palette.
Images and Animation Frames
An Image is a rectangular collection of pixels which contains something
visually recognizable, like a picture of your mom. An Animation Sequence is
a collection of images, which when viewed sequentially expresses an action
of the visually recognizable thing, like your mom sticking her tongue out at
you for digitizing her. Each individual image in the Animation Sequence is
an Animation Frame. When we want to make our Ghosts, say, roll their eyes,
or move their feet, we need to draw multiple images of the Ghost, each one
making a portion of the whole action. If we want him to roll his eyes in 10
frames, in each frame his eyes roll 1/10 of the way around from the previous
frame. Again, all 10 frames MUST use the same Color Palette.
Color Cycling
Sometimes it is very handy to change a few colors in the Palette over the
course of an animation. For many of the display messages in OidZone, I have
the letter colors animating from the top to the bottom of the letters then
back around. To accomplish this, I made all the moving colors consecutively
in the Palette and shifted them to the left for each frame. The last color
in the sequence gets shifted to the first color, then moves left on the next
frame. This is called Color Cycling, and is a neat effect. Normally this
is a programming thing that you do in the game, but you can't do this
effectively in Euphoria, so I created an animation of the effect. After I
got all the frames with the colors moving, I remapped the palettes to the
Game Palette, and went on.
Choosing an Art Program
When choosing an art program to create game images, you need to make
absolutely sure that you have control over what colors appear where in the
palette. You need to be able to convert images with different palettes to
use your "Game Palette" and\or create an "Optimal Palette" by picking the
256 most representative colors out of your list of images and
remapping\adjusting the colors of each image to fit it. I use Autodesk
Animator Pro(TM) for doing 256 color images and animations for games. It
handles color Palettes very well and I can work with as many animation
frames as I want in any resolution Euphoria supports. It also can save
sequential images in BMP for easy loading.
For these requirements I DO NOT RECOMMEND ANY WINDOWS application. So far,
none I've seen handles color palettes consistently or gives you any control
on the final color palette. This is ABSOLUTELY ESSENTIAL FOR GAME ART. You
must be able to load in a standard palette for your game and save all images
in that palette.
----------------------------------------------------------------------------
Masking and Sprite Basics
Computer Game Art falls into one of two categories, Backgrounds or Sprites.
Backgrounds are things that don't move on the screen, like the Maze in our
course project, or the Feedback Window where scores and stuff are drawn
during the course of the game.
Sprites are things that move around, like Packy and the Ghosts. Sprites can
move in front of or behind background objects or each other.
Remember that Images and Animation frames are RECTANGULAR, but usually what
you want to display is NOT. There is usually a big black (or whatever) box
around what you want to display. If we just draw all our sprites on the
screen, the big black boxes will screw up our background, and worse, obscure
sprites that are moving next to us in the same direction. How do we get
around that? It's called MASKING
Masking and Key Colors
Masking is a programming technique where only the pixels you want to see of
your sprite are drawn and the others are disregarded. Generally you pick
one color in the Color Palette and use that color for everything you DON'T
WANT TO DRAW. This color is called the Masking Color or Key Color. For our
course project, we'll write special sprite draw routines that will look at
each sprite, skip all Key Colored Pixels and draw the rest of the Sprite.
Instead of a big black box around our object, its a big Key Colored Box that
isn't drawn when we draw the Sprite.
When you draw your sprites, start with the Key Color and draw a box a little
bigger than your object. Then draw your object INSIDE the box. Usually I
use color 0 as my key color and make it BRIGHT RED or GREEN. Make sure it's
a bright color you are not using in the object. The purpose of the bright
weird color is so you can see all the edges of your object and how they will
look against a high contrast, ugly background. It doesn't matter anyway,
since this color is masked out when the sprite is drawn.
Aliasing and Anti-Aliasing
Aliasing is also called the "jaggies". Because we only have so many pixels
to work with in our images and because they are rectangular, all the images
we draw will have jagged edges around them when seen against a high contrast
background. Get used to it.
Anti-Aliasing is a technique of smoothing out the appearance of the Jaggies
by picking colors between the object color and the background and making a
smoother transition along those edges by putting those colors at each jagged
edge (alias).
IF YOUR IMAGE EDITING PROGRAM HAS ANTI-ALIASING, TURN IT OFF!!! If you
Anti-Alias an object with a bright green background, you get a weird,
erratic, ugly line around your Sprite that isn't masked out by your drawing
program. If you anti-alias against a black background, you get ugly brown
lines that look horrible against any other background. If your objects
overlap, the results are usually horrible.
If you are rendering 3D animations for your game art (like OidZone, I used
Autodesk 3D studio, by far the most useful program on the planet for doing
3D work) Set your background to an ugly color you aren't using (3DS always
makes this color 0) and turn Anti-Aliasing OFF.
Every once in awhile, (the ship in OidZone, for example) you will want that
ugly outline around the object, say if your intended background is of
similar colors to your object. In those cases, turn anti-aliasing ON, use a
BLACK background, and render the animation. Then load the animation into
your image editor, fill the background with an ugly bright color, then edit
the ugly brown outline to suit your needs. When you are done REMEMBER TO
REMAP YOUR ANIMATION TO YOUR GAME PALETTE, and MAKE SURE THE UGLY BACKGROUND
COLOR IS YOUR KEY COLOR.
============================================================================
End of Week 4 - Basics of Computer Art and Art Specification
Part 1 - The Basics of Computer Art.
If you have any questions for group discussion post them to the list server.
E-mail any other questions, comments or suggestions to lgp@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,7 Lord Generic Productions - All Rights Reserved
============================================================================
A Crash Course in Game Design and Production
========================================================
Week 4 - Basics of Computer Art and Art Specification
========================================================
Welcome back! This is the fourth installment in "A Crash Course in Game
Design and Production. Like last time, this lesson is in multiple parts. In
PART ONE, we'll discuss computer graphics in general, and what we need to know
before we can talk about ART. In PART TWO We'll discuss the ART Specification,
what it is and what we need to put in it. In PART THREE we will write the
fourth section of the Design Spec for our Course Project, the Art
Specification. This is part 2 of 3
------------------------------------------------------------------------------
Part 1 Addendum
------------------------------------------------------------------------------
I left out something REALLY important from part one.
Colors
As I said previously, in VGA modes, the color palette is 16 or 256 colors
chosen from 262,144 colors in the VGA master Palette. I didn't tell you how
they are chosen, or how they are stored in the Palette. D'oh!
RGB Values
Remember when you were in school and they gave you only 3 crayons and told you
could make any color by mixing varying amounts of the 3 "primary" colors, and
you tried all day and it didn't look very good? It's true. On paper, if you
mix Cyan(blue), Magenta(red), and Yellow(yellow) in varying amounts you can
get any color you can see. Determining the right amounts of each is called
creating a CYM Color Separation. On your Monitor(and light in general) it
works exactly the same way, only with different colors. Every color you can
see on your monitor is made up of varying amounts of Red, Green, and Blue
"light." In your art program, when you change a color, you do so by changing
the RGB (Red, Green, Blue) values for that color. For VGA video modes, you
have effectively 64 levels each of Red, Green, and Blue to play with, for a
total of 64x64x64= 262,144 possible colors, of which you can choose any 16 or
256, depending on your video mode. EGA modes give you 4x4x4=64 total colors
of which you can choose 4 or 16 for your palette, depending on your video
mode.
4-bit, 8-bit, 16-bit, 24-bit Color Modes
You hear this phrase thrown around a lot, "I only have an 24-bit video card"
or "I'm writing my game in 8-bit video." This just tells you how many colors
can be displayed on the screen at one time, i.e. how big the color palette is.
8 bits is 2^8 or 256 colors. 16 bits is 2^16 or 32768 colors, 4 bits is 2^4
or 16 colors.
How Palettes are stored
While VGA only has 64 values each for R,G,B, some image formats, most notably
BMP, store them as whole bytes, as if the values were from 0-256. They are
stored as 4 times bigger than they really are, consequently, in Euphoria, you
have to divide the palette sequence by 4 before you can do a all-palette().
Many art programs also edit the colors as if you have 8 bits or 256 levels of
R,G,B to stay consistent with 16 and 24 bit video modes where you have 16.8
million colors to choose from. Just make a mental note that the real values
for those colors are 1/4 what you tell the program they are.
-----------------------------------------------------------------------------
Part 2 - The Art Specification
------------------------------------------------------------------------------
Our Screen Design and User Interface Specification describes in detail what
each screen and control of our game will look like and what will happen on the
screen. The Art Specification details what graphic images and animations we
need to MAKE each screen look and work as described. Think of it as a PARTS
LIST for your game. The SD&UI Spec is like the picture on the side of the
box. You see what it's supposed to look like when you get done and the Art
Spec is what we need to build it.
Anatomy of The Art Specification
================================
It's been 3 months, I guess you're ready for another anatomy.
The first part of the Art Spec is called the Screen and Image Parameters. This
is a list of art guidelines your artist needs to follow to make his art work
with your screens. In this section you MUST HAVE:
* Video Mode the GAME WILL BE RUNNING IN. 320x200x256, 640x480x16 or whatever.
* Normal game screen size(s). Generally this is the same as the video mode,
but it doesn't have to be. In JetFighter III for example, the video mode
was 640x480, but they wanted all of our animation sequences letterboxed in
320x160.
* Aspect Ratio. Generally this is the same as the video mode closest to the
image size, but sometimes it isn't. For the above mentioned animation
sequences, you would usually use an aspect ratio of .82 for 320x200 mode,
but since they decided to double the pixels and play the animations in
640x480 mode they needed to have an aspect ratio of 1. If you draw all your
art using the video mode the game will be in you will have no trouble with
this usually.
* Color Palette allocation. How will you split up the 256 colors you have to
work with? Are some colors reserved for certain use and unavailable for any
other? Say you have a windowing user interface with pull down menus and
stuff like that. You want to set aside the interface colors so you don't
screw them up if you need to change palettes or colors in your game. For
OidZone, I set aside 128 colors for the background (so I could change it at
will without having to remap all my sprites), 10 colors for my color cycling
logo and explosions, 64 colors for my asteroids and 54 colors for my ship.
Also list how many Color Palettes you need (if you want to change them
during the game) and common colors between them.
* Masking color. What color position is it in the Color Palette, and what
color to make it. The COLOR is VERY IMPORTANT. If you choose to make it
bright red (see part one on Masking) Write down the exact RGB (RED GREEN
BLUE) values for this color (64,0,0 or 255,0,0 in this case depending on
your art program) and use these exact values for EVERY IMAGE. If you have
to remap your color palettes, the red in some images may not remap to the
right RED in your masking position and the art won't mask correctly (at all)
* Naming Convention. This is EXTREMELY IMPORTANT!! You need to have some
standard filename system for your game art, as well as for any other data
files, so you know what is what. Take some time and plan out your
filenames.
The second part of the Art Spec is Background Art. Remember last time I made
two categories for Game Art, Backgrounds and Sprites? Backgrounds are
anything that doesn't move AND is NOT drawn on top of something else during
the game. If it moves or if it appears in front of something else it's
considered a Sprite, because it needs to be Masked with whatever else is drawn
on the screen.
For the Background Art Section, you need to go through every page of the
Screen Design Spec and detail all the background pieces. For each of these
you MUST put in the following:
* Object Name
* FILENAME of Object. Everything has been abstract up to this point. This is
reality time. What is the filename.ext you need for this object. It REALLY
HELPS to have the first thing in your parts list be the part name so you can
find it.
* Description of object - What is it? What does it look like, color scheme,
etc. If the object has multiple parts, what are they? How big?
* Size of object in pixels, width x height. For example, the Feedback window
for OidZone is 90x192 pixels
* Location on screen in X,Y coordinates. As the art is completed, you need to
place it on screen and check it with the other art to see if it "fits."
* What other art pieces (if any) need to fit into the background object? How
many?. Where do they need to go? For our Course Project, we need to put 3
spare Packys in the Feedback Window for each player, along with his score,
and the logo art.
The third and fourth sections of the Art Spec detail Sprites. Sprites can be
split into two categories as well, Characters and Foreground Objects. A
Character is anything that moves and\or animates on screen, like Packy or the
Ghosts. A foreground object is anything that DOESN'T MOVE (much) that is
drawn ON TOP of EVERYTHING ELSE. Characters can move BEHIND Foreground
objects or run into them. In OidZone, for instance, asteroids move behind
many of my game messages (prepare to enter, game over, title image, etc.) The
asteroids are Characters, and the messages are Foreground Objects.
Part three is Characters. Again you need to go through every page of the
Screen description and write down EVERYTHING YOU FIND ABOUT EACH CHARACTER.
You must include:
* Character Name
* FILENAME (convention if you have multiple frames)
* Description - General Characteristics, color...
* Size of Character width x height
* Personality traits we need to show, and how many images we need to show
them. If the Ghosts need to roll their eyes or look frightened, spell it
out here. Describe in gross detail EVERYTHING this Character needs to
do in the Game. List each thing and what is required to show it
* Total number of images required for this character
Part four is Foreground Objects. For our Course Project, Foreground objects
include the lighted marquee sign in the title sequence, Get ready image, Game
Over Image, and animated logo in the FeedBack Window.
* Object Name
* Filename
* Description
* Size width x height
* X,Y position on screen
* Total Number of Animation Frames
Part five is the last part, this is FONT(S) You spell out the game's font
requirements here. Some games do not require ANY fonts at all, they have word
sprites for whatever messages they need, or use the normal bios print routine.
(which sucks in 320x200)
* Font Name
* Description: Characteristics needed, what characters needed, etc.
* Point Size: How many pixels high, wide is it?
* MISC font parameters:Leading(line spacing), Kerning(letter spacing), Bold,
Italics, Underline, etc.
By the end of the Art Specification, you should now every piece of art you
need for the game. Make sure you go back through the Screen Design Spec and
check that everything is accounted for. When the Art Spec is finished, you
can give a copy to your art staff and they can draw while you go on to the
Sound and Music Specification. See you next week.
============================================================================
End of Week 4 - Basics of Computer Art and Art Specification
Part 2 - The Art Specification.
If you have any questions for group discussion post them to the list server.
E-mail any other questions, comments or suggestions to lgp@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,7 Lord Generic Productions - All Rights Reserved
============================================================================
A Crash Course in Game Design and Production
===========================================================================
Week 5 - Sound and Music Specification
===========================================================================
Welcome back! This is the fifth installment in "A Crash Course in Game
Design and Production. Like last time, this lesson is in multiple parts.
In PART ONE, we'll talk about the basics of sound reproduction on the
computer. In Part TWO, we'll discuss computer music and sound effects, and
what we need to write the Sound and Music Specification. In PART THREE we
will write the fifth section of the Design Spec for our Course Project, the
Sound and Music Specification. This is part 1 of 3
---------------------------------------------------------------------------
Part 1 - Basics of Sound Reproduction on the Computer
---------------------------------------------------------------------------
Before we can talk about the Sound and Music Specification, we need to get
up to speed on how sound works, at least as far as we're concerned, and
what we need to know to be able to talk about Music and Sound later on.
Sound terminology
=================
Sound - Anything we can hear. When you drop something and it hits a table,
say, it and the table vibrate, they shake a little. This vibration moves
the air around them in all directions. As the objects vibrate back and
forth, the air around the objects are pushed away or drawn to them in
"pulses" like the ripples in a pond when you drop a rock in it. The air
pulses eventually reach your ear, and move the hairs inside back and forth
at about the same speed (it decreases with distance from the objects).
These vibrations in your ear are converted to electric signals which go to
your brain and you "hear" a sound.
If the vibrations are too fast or too slow, the hairs in your ear won't
respond to them. They either can't go back and forth fast enough to match
the vibrations, or the vibrations are so slow that their force isn't enough
to move the hairs. You can't hear these vibrations. They are not sound.
If you can't hear it, it isn't sound, I don't care what the speaker
propaganda says. Physicists and philosophers argue that. If I didn't
hear it, it didn't make a sound for me.
Amplitude - How far the hairs in your ear move as they vibrate back and
forth. The Amplitude is the total distance from back to forth. The farther
the hairs move back and forth, the louder the sound. If a garbage truck
falls off the Empire State Building and hits the ground, the vibrations
that it causes will stronger than those caused by a Yugo. The sound may be
similar, but it will be MUCH louder. There is no standard measurement for
this as far as I know. When you're trying to reproduce a sound, the
amplitude is relative to the hardware, amplifier and speakers, you are
using.
Frequency - How many times the hairs in our ears are vibrating per second.
The measure for this is Cycles (back and forth) Per Second, or Hertz, named
after the guy who figured this stuff out. The Human ear can "hear" sounds
ranging typically from 100 Hertz (1hz) to 16000 Hertz (16khz - 16 Kilo-
Hertz, 16000 cycles per second)
Tone, Musical Tone, Pure Tone, or Note - A continuous "sound" at a certain
frequency for a certain duration. If your ear hairs are vibrating at 440hz
(440 times back and forth per second) for awhile, you are "hearing" an
"A Note"
A guitar or piano string vibrating at 440hz will make a similar tone.
The won't sound exactly the SAME probably, because in the real world things
can't continuously vibrate at set rate over ANY length of time. There are
a lot of technical reasons why, which are way beyond the scope of this
work. Things that effect the sound you hear include, material that is
vibrating, density of that material, how it started vibrating, artificial
damping of the sound, the transit medium (things sound different underwater
than they do in the air), etc. On an instrument, when you play a "note"
the actual frequency you hear fluctuates many times a second, but they
average pretty close to the "standard" frequency of the note. An "A" on a
guitar will be on average about 440 hz, although at any time the frequency
may be between 437-444hz.
Synthesis vs Digital Sampling
=============================
There are 2 ways to create a sound for the computer to play, Syntheses, and
Digital Sampling.
Synthesis - The computer program itself "creates" the sound by sending
frequency and\or amplitude parameters to an electronic Sound generator. On
the PC, this is generally either to a sound card or PC speaker. On the
Adlib(tm) or SoundBlaster(tm) cards, the frequency determines the musical
tone, and the amplitude determines the volume. This is called FM synthesis
(frequency modulation) and is great for producing pure musical tones.
Music, for the most part, is a sequence of distinct musical tones, played
in some sequence with varying rhythms. Unfortunately, FM synthesis is
awful for trying to recreate "real life" sounds, like the human voice.
"Real" sounds are NEVER pure tones. The frequency and amplitude fluctuates
thousands of times a second. They may average at around a standard
frequency, but the parameters of how they vary with time are too
complicated to approximate with any accuracy. Musical instruments are
easier to synthesize, since they are designed to play "notes." You at
least have a starting point. Where do you start trying to synthesize a
cough?
Digital Sampling - The computer "listens" to a real world sound, and
"records" the frequency and amplitude changes over time. The process is
called "sampling" or "digitizing." On the PC, the SoundBlaster(tm)
compatible cards convert the electrical signals from their microphone or
line inputs into digital information. It actually only records the
amplitude many thousands of times a second. When it "plays" the "sampled"
sounds, it converts the data back to an electrical signal which drives the
speaker back and forth.
Digital Sampling is the best way to reproduce real world sounds. Pretty
much anything you can hear can be sampled into the computer. You can sample
your voice saying "Level Completed" and play it in your game. For short
duration sound effects and musical tags for your game, digital samples are
ideal.
The real drawback is that sampled sounds take up a TON of memory and hard
drive space. To accurately reproduce a sound, the computer needs to sample
the sound many thousands of times a second, with a very fine amplitude
scale. Example: If you sample a five second sound 44,000 times per
second, with 2 bytes of amplitude information per sample, the sound will
take about 214.5k of ram. If you want to sample in stereo, that's 429k for
five seconds! Digital sampling is awkward for long musical pieces, they
sound great, but the storage requirements aren't usually worth it.
For long musical pieces, FM synthesis is generally better than digital
sampling, but you are creative, and your hardware supports it, you can
merge the two forms. You can, for example, sample every note on a piano,
then tell the computer to play the individual notes in some order, and it
will sound exactly like a piano playing a tune. This is a hybrid between
pure synthesis and pure sampling, and is called "wavetable synthesis"
Good News and Bad News
======================
For Euphoria programmers, there is good news and bad news. The good news
is at long last we have the ability to use digital samples in our games,
thanx to Jacques Deschenes and his sound blaster drivers. The bad news is
* His drivers can only handle small <64k samples without considerable
computing time dedicated to moving memory around
* We can only play mono sounds
* We can only play one sound at a time
* We have no ability yet to do FM synthesis.
Since we can't actually DO FM synthesis in Euphoria (yet), the rest of this
discussion will be geared toward the Hows and Whats of Digital Sampling
More Terms and Definitions
==========================
Sampling Rate or Sampling Frequency - This is how many samples we are going
to record per second. This is how frequently we are looking at signal
coming in. Since its called a "frequency," the sampling rate is denoted in
Hertz or KiloHertz. If you sample a sound 44,000 times a second, it's
called a 44khz sample. This has NOTHING to do with the frequency of the
SOUND being sampled. You can, for example sample a 440hz sample 44,000
times a second, making a 44khz sample of a 440hz sound. I know it's
confusing. Read this about 20 times and you'll get it.
There is a relationship between sampling rate and the kinds of sounds you
can sample. A 22khz SOUND vibrates the speaker in and out 22,000 times a
second, meaning it moves it IN 22,000 times a second, and OUT 22,000 times
a second. In order to sample this sound adequately, you need a high enough
sampling rate that you can record all the IN's and OUT's. You must be able
to sample at least 44,000 times a second to do this. So the maximum SOUND
FREQUENCY you can record is half of your SAMPLING RATE. A 22khz sample can
reproduce any sound up to 11khz. An 8khz sample can reproduce any sound up
to 4khz.
Sound Quality - How close to the actual sound is your sample? As we've
just seen, the higher the sampling rate, the higher the sound frequency we
can reproduce, therefore the closer to the actual sound we get. CD players
sample at 44khz, and they sound great. Your telephone "samples" at about
8khz, and it sounds sucky in comparison. If you have fiber optic phone
cable, the sampling rate is about 15khz so it's better.
Amplitude Resolution - This is how many discrete amplitude levels your
sound hardware is capable of reproducing. Early Sound Blasters could
reproduce 128 amplitude levels for each direction of the speaker vibration
in and out, giving 256 total steps. This entire range can be represented
by 8 bits or one byte of information. The resolution is called 8bit. When
you hear the term "8-bit sound card" or "8-bit sample" it means that the
sound you hear from it will have at most 256 different amplitude
variations. Newer sound cards, like the SoundBlaster Pro(tm) have 16 bits
of amplitude resolution or 32768 different amplitude levels. They drive
the speaker back and forth more accurately, so the sound they can produce
is closer to what you sampled than 8-bit cards. 16-bit samples have better
sound quality than 8 bit samples, because the speaker moves closer to the
way the original sound would have moved it, but they take up twice as much
hard drive space and memory at the same sample rate.
I'm guessing most telephones today have 8 bit resolution. Anyone know?
===========================================================================
End of Week 5 - Sound and Music Specification
Part 1 - The Basics of Sound Reproduction on the Computer
If you have any questions for group discussion post them to the list server.
E-mail any other questions, comments or suggestions to lgp@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,7 Lord Generic Productions - All Rights Reserved
===========================================================================
A Crash Course in Game Design and Production
===========================================================================
Week 5 - Sound and Music Specification
===========================================================================
Welcome back! This is the fifth installment in "A Crash Course in Game
Design and Production. Like last time, this lesson is in multiple parts.
In PART ONE, we'll talk about the basics of sound reproduction on the
computer. In Part TWO, we'll discuss computer music and sound effects, and
what we need to write the Sound and Music Specification. In PART THREE we
will write the fifth section of the Design Spec for our Course Project, the
Sound and Music Specification. This is part 2 of 3
--------------------------------------------------------------------------
Part 2a - Sound and Program-Related Terms We Need.
---------------------------------------------------------------------------
Ok, now that we know all about sound, we'll move on to the kinds of things
we need to specify in our Sound and Music Specification. For this
discussion we need to clarify some terms:
Event - An event in this context is anything that causes us to want to play
one of our digital samples. Things such as the beginning of the game,
eating a dot, energizer or ghost, losing a life, getting a high score, or
beginning an intermission sequence are all events. We will categorize the
sounds we play based on the events that trigger them. In the discussion
that follows, I will sometimes give sample event names. In these I will
use the nomenclature EventName, like GameOver, HighScore, ClearLevel. From
the names I give, I will assume you can figure out what I mean.
Milestone Events - We talked about this earlier. These are game goal
related. When the player has done something appropriately productive or
inappropriately counterproductive in his quest for the game goal, you want
to play some sound sample. Beginning the game is productive, so it is a
Milestone Event. Other Milestone Events are GameOver, Intermission,
HighScore, ClearLevel, KillBoss, Death, etc.. Milestone Events are either
Major (KillBoss) or Minor(BonusObject).
Game-Related Events - These are anything else that would make you want to
play one of your sound samples. For Snack Attack, this would be eating a
dot, energizer, bonus object or ghost.
Priority - Since we have a limitation that only one sample can be played at
a time, we need to plan our sounds by priority. While we can always stop a
sound during playback and start another one playing, you don't always want
to do it! Some events are more important than other events, soundwise. For
example, Packy getting "eaten" is more important than the bonus score
sound, so that sound should have priority. You don't want to cut off
important sounds by trivial ones.
"Getting Stepped On" - This is when a lower priority sound sample is
playing, and another sample of same or higher priority is required to start
NOW. The previous sample is "stepped on," it stops playing, the sound card
is reset, and another sample is played in its place.
"The Good Part" - The whole point to the sample. Something about the
sample made you choose it as "the sound" for a particular event. That
something is the good part. For OidZone, one sample I'm fond of is
"You SUCK!!! Try Again..." with a nice echo. The "you SUCK!!" with the
echo is the "good part" for me. I laugh EVERY time I hear it. The good part
should NEVER "get stepped on" if you can avoid it.
Length - The duration of the sample in seconds. If my intermission
animation event lasts ten seconds and I want some background music for it,
the sound sample I need to play must be "ten seconds long," It's over ten
seconds after it starts.
Music vs SFX
============
I've used the term "sound sample" until now, because I wanted to make an
important distinction between different "types of sounds" we use for our
games. These distinctions also apply to FM and Wavetable synthesized sounds
too, so if and when we have those capabilities in Euphoria, this material
will also apply to them as well. From here on out I will use the terms
"Music" and "SFX."
Music
-----
Generally only plays at milestone events, and is not affected by any other
game-related events. "Music" is kind of a misnomer, as not everything that
falls into this category needs to be "musical" in any way. This
distinction goes back to the 1980's arcades, before we had digital samples.
Most of these things were signaled with music, because music synthesis is
easy, and voice synthesis is hard. Music falls into Three categories,
based on the type of milestone event that triggers them. They are:
Theme Music - These are sounds that set the tone of the game. They are
generally five to ten or more seconds in length, and they play at and
during major milestone events. Theme Music events are TitleSequence,
StartNewGame,NewLevel, YouDie, YouSuckTryAgain, etc. Note that these don't
have to be musical at all. You can sample yourself saying "The
Force will be with you...always" and call it Theme Music. It sets the tone
as to how the player feels about the game and his play. Theme music
generally has the highest priority. You don't want to cut off "you are
really a great player" with a farting sound. It sends the wrong message.
Any player alert message, like "Green Elf is about to die..." is Theme
Music. It sounds weird, and it is, really, but that's how it is.
Background Music or Ambience Tracks - These generally begin at Milestone
Events, like StartGame, or Intermission, and continue to play throughout
the event. In our course project we will be experimenting with playing
background sounds "around" the game-related event sounds. While we can
only play one sound at a time, we can create some alternate versions of the
sound effects to sound "like" we're mixing them with the background. It's
tricky to do right, but we'll give it a go. These ARE usually musical
samples, but you can have your background music be obscenities shouted at
the player all through the game if you want to. That would be an "ambience
track" Background music has the absolutely lowest priority, as it's played
constantly. All other sounds must be able to play over it.
Musical Tag - These are VERY short samples, usually 2 seconds or less.
They occur at Minor Milestone events, like EatingBonusObject, HitHighScore,
etc. These could be a short fanfare or Ding-Ding-Ding-Ding, or "WOW!" It
doesn't matter.
SFX
---
This is an acronym (sorta) for Sound Effects, and describes pretty much any
other sound you want to play. SFX are game-event related - something
happens in the course of your game that isn't really milestone related, but
is important enough that you want to play a sound effect for it. Things
like shooting, htperspacing to another location, eating a dot, an oid
breaking, ghosts bumping heads, etc. are all things you may want to play a
sampled sound for. Aural feedback is as important as visual feedback in
games. Things that make noise are more interesting than things that are
silent.
BE CAREFUL NOT TO OVERDO SFX!!! Like Creeping Featurism, SFXitis should be
avoided at all costs. Just because you CAN make each key pressed sound
like a different dog barking, doesn't mean you SHOULD. Try and keep your
SFX to less than 20 unless absolutely necessary. Only things that affect
how you are doing should have sound effects, like thrusting your ship or
shooting. Some don't need SFX, specifically, things you do a LOT, like
maneuvering packy around the maze, or rotating your ship. These things get
annoying VERY QUICKLY.
KEEP YOUR SFX AS SHORT AS POSSIBLE!! When sampling sounds, often you have
some quiet time at the beginning and end of your sample. You should edit
this out, and trim your sound effect so it's as short as you can make it,
especially if it is something that will be heard frequently, or will be
"stepped on" by another (or the same) sound effect. Too long effects sound
bad if they are cut off before "the good part." If you trim your SFX to
bare minimum, you hear more of the good part before it's stepped on.
---------------------------------------------------------------------- -----
Part 2b - The Sound and Music Specification
---------------------------------------------------------------------------
Finally, we're to the point where we can talk about what we need to specify
for the Sound and Music Specification. This part of the Design Spec is very
similar to the Art Spec we talked about last week, in that for each Sample
we describe what it is, what we're calling it, how big it is, and where it
goes.
Anatomy of the Sound and Music Specification
--------------------------------------------
Here we go, into another anatomy. The Sound and Music Specification
consists of:
Sound Requirements List
This is the system requirements for our game, and the sound parameters we
need to adhere to. According to Jacques' sbcard.e, his drivers have the
following requirements and limitations:
* This first version doesn't use interrupt service routine, so can't
play in background, except for file small enough to be loaded
completely in DMA buffer all at once (max size 64KB)
* It only play 8 bits files, mono or stereo.
* It has been written for sound blaster pro with dsp version 3.
But it can be used to play mono file on prior dsp version card.
All sound samples we intend to use MUST meet these requirements. The
maximum disk size of any sample is 64k, which is about 5.96 seconds long
assuming a sampling rate of 11khz, 8 bit amplitude resolution, mono. If we
need a longer sample, we need to decrease the sample rate for that sample.
We aren't locked to any sampling rate, each sample we have can have a
different one if we want. In general use the highest sampling rate you can
and still be under the 64k.
Music Specification
Here we describe each Music sample for each of the three categories:
Theme Music
Background Music
Tag Music
You need to comb through the General Description and Screen Design Spec to
find EVERY "Music" piece you need for your game. For each of these you
need:
Name: What you call the effect
Filename: What you want the Sound file to be called
Length: How long should the sample be in seconds
Sample Rate: What rate should you sample it in?
Event That Triggers it: What will cause this sound to be played?
Priority: What priority is this sample? What should\should NOT step on it?
SFX Specification
This is pretty much EXACTLY like the Music Spec. Go VERY CAREFULLY through
your other SPECS and make a list of EVERY SOUND EFFECT you NEED to have for
your game, then go through and specify them one by one as you did for the
Music samples.
We're on a roll now. Next week we'll look at the AI specification.
===========================================================================
End of Week 5 - Sound and Music Specification
Part 2 - The Sound and Music Specification
If you have any questions for group discussion post them to the list
server. E-mail any other questions, comments or suggestions to lgp@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,7 Lord Generic Productions - All Rights Reserved
===========================================================================
Discuss this article in the forums
Date this article was posted to GameDev.net: 8/6/1999
(Note that this date does not necessarily correspond to the date the article was written)
See Also:
Game Design
© 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!
|