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, i
<%Topic="A Crash Course in Game Design & Production"%>
A Crash Course in Game Design and Production, an extensive multi-part online workshop from 1997.
Advertisement
Other Tutorials by GameDev.net
Advertisement