Game Programming '98 Staff Note :
These tutorials were obtained from :

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



  • 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 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, 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 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, 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 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 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 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 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 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 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 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 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 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 8/6/1999
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Game Design

© 1999-2011 All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!