<%Topic="A Crash Course in Game Design & Production"%>

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

http://server.exo.com/~lgp/euphoria/crash.htm.

The author has done a wonderful job and should be commended.  In hopes that
these articles don't mysteriously find the same fate many programming articles
do (stored away and long forgotten on someones hard drive), I have posted
them here.

If you like them and they are useful to you, it would be really appreciated
if you'd send a donation large or small (even $10 would be be nice) to

               Lord Generic Productions
                   1218 Karen Ave
                 Santa Ana, Ca 92704


Enjoy!



TABLE OF CONTENTS :

                                   
Week 1 -
                     A general Introduction to the Course and
                     Anatomy of a Game Design Specification
Week 2 -
                     From Vague Idea to General Description -
                     Part 1 - Project Codename and Anatomy of
                     the General Description
Week 3 -
                     Screen Design and User Interface Specification -
                     Part 1 - The Basics of Screen Design and User
                     interface Issues
Week 4 -
                     The Basics of Computer Art and Art Specification -
                     Part 1 - The Basics of of Computer Art

Week 5 - The Sound and Music Specification - Part 1 - The Basics of Sound Reproduction on the Computer

A Crash Course in Game Design and Production ======================================================== Week 1 - Part 1 - A General Introduction To The Course ======================================================== Hi, and welcome to our class. Over the course of the next several weeks, we will cover material that applies to ALL areas of software design and production, as well as issues peculiar to game design. My purpose is two fold: 1) To show the importance of planning the project BEFORE you start coding. 2) To take you though all the steps in software production, from a vague game idea to a completed, commercial quality game ready to market. Along the way, we'll cover topics including: * Human Interface Issues - Player controls and feedback systems * Artificial Intelligence What will cause the actor to act, how will he know to act, what will his action be, and how do we make him do it * Sprite Animation How to draw the right sprite when * Using Virtual Screens Drawing all the sprites off screen, merging them with backgrounds and eachother, then redrawing only the portion of the screen you need to * Play balancing Making the game challenging, but not too hard for a novice to play * Bug Reports and Quality Assurance Testing The difference between an "alpha" and a "beta" Who to give betas to and how to report "undocumented features" * Copyright notices and disclaimers * Programming issues, milestones, and overcoming problems The format for this course will be as follows: Each week I will put up lesson text and sample code on the listserver, and an HTML version with sample images, code and archives on http://exo.com/~lgp/euphoria After each lesson is presented, I'll open the floor for discussion on the topics presented, questions for more clarifications, comments, suggestions or whatever. Send group interest messages to the listserver and other feedback to me, lgp@exo.com. I will also have a Q&A page on my site documenting all questions and responses. As with all software projects, there is no way to know for sure when we'll have it completed, but we're gonna set a deadline anyway. Our deadline is January 1st. I know it seems like a long way away now, but believe me, when we're up at 3am on dec 30 trying to figure out by "blinky" is spinning around and around in the middle of the screen on level 6 only after you eat your 3rd energizer (whichever one it is) it won't. I'll tell you now, it's going to be awhile (at least 6 weeks) before we write a single line of code. Game designers have a lot to do before programming can begin. By the time we start coding, we MUST know EVERY STINKING DETAIL about our game, what will be on every screen, how they work, how we will do our animations, how we'll program the AI, when to draw what and how, everything. We'll be dreaming about coding before we actually do. When we are at that point, actually coding the game will be cake. Conversely, when you are NOT at that point, coding the game can be a nightmare. I've worked on a LOT of nightmare projects. So strap yourself in, we're ready to rock! ========================================================================== Week 1 - Part 2 - What IS a game design? ========================================================================== Game Ideas Vs Game Designs -------------------------- I hear people talking all the time about the games they are "going to" write someday. Most of these people NEVER actually write anything worthwhile. They may START something, but soon get overwhelmed in speghetti code trying to patch in a feature they realized they needed two weeks in. Often they toss the "Ultimate Game" aside in disgust and chase easier projects. It's not because they had a bad IDEA, it's because they had NO PLANNING before they started. If you don't know what you need before you need it, adding it later can be a nightmare. That is the purpose of GAME DESIGN, you force you to think about all (as much as you can anyway) aspects of your game in meticulous detail and document what you decide and how you intend to accomplish it. It forces you to go step by step through every screen, action, and reaction. When you get done with a game design, you should know EVERYTHING about YOUR game. Let's say we have this great idea for a game: "Ok, this little yellow guy runs through a maze and eats these little dots while avoiding 4 cute little monsters, every level it gets faster until you can't play any more" Even if you see it clearly in your mind, put it clearly on paper. Think about the game, how it starts, how it ends, what happens at each stage. You need to spell it all out: * How big are the characters? * What do they look like? * How big is the maze? * What graphics mode will we be in? * How fast will the monsters and player go at start and how will that change? * How will we know the level is over? * What will the monsters look like and how will they act\react to the player? * What are the controls? * Are there any player initiated controls that will change the monster's behavior? (like energizers) * How will the monsters KNOW when this happens, and how will their behavior change? * How will we score this game? The questions go on and on. You MUST decide these things BEFORE you write a line of code. Ok, you're probably saying to yourself, "wait a minute, how can you know all the programming issues\problems before you start?" Fair question. The answer is, obviously, you can't. There ARE GOING to be programming difficulties in any project. The point is if we know the kinds of things we need to do in the code before we write it, we can avoid as many of the difficulties as possible. Often during the later stages of design, I prototype routines to get a feel for the kinds of data structures I need, and avoid any immediate hazards in the road. We're still going to be trouble shooting and tweaking our code to adjust for things we missed in the initial design, especially when we get to the AI programming. It happens. Anatomy of a Game Design Specification -------------------------------------- A completed game design is called a Game Design Specification or SPEC, and it contains at least the following: A) Project CodeName - Every game has a codename to designate it during production. This usually isn't what the game is finally named on release, marketing people love to change names at will. We will choose our project codename next week. B) General Description - This is a general overview of the game, what it's like, how it works, what happens on each level, etc. We start with the original Game IDEA, then fill in the blanks enough that anyone reading it will know what we are talking about. We will start writing this next week. C) Screen Description and User Interface Specification - What screens do we need for the game, what will they look like, How will they work, how will the player interact with them and what feedback systems will be available to let the player know his status. Each screen is treated individually and explained, including mock up screen shots wherever possible. D) Art Specification - What graphics elements do we need? What Characters do we need, what personality traits do we need to show in the art, how big are they, what animations do they need, etc.? What do the graphics screens look like, and how big, number of colors? What kind of font do we need? How big, colors, etc. What WORD graphics do we need? E) Sound and Music Specification - What kinds of sound effects (SFX) do we need? Intro and\or Intermission music? What file formats will we support? How are we going to do sound? This is the only real weakness in Euphoria as far as game development is concerned. PC speaker is really inadaquate for most games, but we'll do what we can. I have programming specs for adlib, soundblaster, etc. If we can find an adventurous person to try and get soundcard support working, I think we will all be VERY happy. F) Paradigm Specification - How are we going to do this project? What approach will we take? What functions and procedures do we need? What information will they need? In what order do we draw the sprites? How often do we update the feedback screens? Speed controls? Once we answer these kinds of questions, we flowchart the game from the player starting, through all the options screens, to playing the game, what happens each animation frame in order, how we end the game, how we restart the game or leave the program. G) Artificial Intelligence Specification - What our characters need to know, how they will find out, and what they will do once they know it. This is kinda fun, as we have to figure out ways they will know what is happening around them. It's even more fun when Blinky keeps bouncing off the same wall over and over because you missed something when you spec'ed him out. G) Legal Stuff - Copyright notices, non-disclosure agreements, etc. We won't worry about this too much, as this project is a public domain, group effort, but we'll cover the material anyway for completeness sake and I'm sure some of you are interested in this. We'll be covering each of these parts in detail over the next several weeks, applying the material toward our group project, which will be an interesting "pacman" clone with some nifty features added. This a good place to stop. Tune in next week for more. ============================================================================ End of Part 1 - General introduction to the Course and Intro to Game Design If you have any questions for group discussion post them to the list server. E-mail any other questions, comments or suggestions to lgp@exo.com A Crash Course in Game Design and Production - Euphoria Edition (C) Copyright 1996 Lord Generic Productions - All Rights Reserved ============================================================================ A Crash Course in Game Design and Production ======================================================== Week 2 - From Vague Idea to General Description ======================================================== Welcome back! This is the second installment in "A Crash Course in Game Design and Production. The purpose of this lesson is to introduce you to our course project, and to go through the process of "filling in the details" between our initial GAME IDEA to our project blueprint, the GENERAL DESCRIPTION. We cover a lot of material this week, so I'm splitting this lesson into 4 pieces. This is part 1 of 4: ---------------------------------------------------------------------------- Before we begin, we need to start thinking about what we're going to call our project: Part 1a - Your Project Codename and You ======================================= Last week, in our ANATOMY OF A GAME DESIGN SPECIFICATION, the first thing on the list was the PROJECT CODENAME. It is extremely important to choose a name to designate a game project as early as possible in the design process. When you name something, it becomes real in your mind. It's a new being that you are commiting yourself to creating out of thin air. It's existance completely depends on your direct involvment. You can't give up on it now, it won't survive without you. It seems like a silly thing, but there is power in a name. If you always talk about the project by name, you become attached to the project, and you're more likely to stick with it, even when you're knee deep in code trying to track down something really nasty. The Project Codename is also called the "Working Title," meaning that it's the best name we're come up with so far, and it's subject to change at any time. I was on a project (for activision\infocom) that was called "Orb Quest", "Kings Quest", "Quest to be King", "Orb Warriors", "Rune Warriors", "Rune Quest", and "IFGRPG" (Infocom's First Graphical Role Playing Game" at different points in production. I feel it is better to separate the Project Codename from the Working Title if possible. It avoids a lot of confusion. Pick a Codename and use it throughout production, then when you're close to release, you can debate other names. Also, the Project Codename doesn't have to relate to the actual game in any way at all. Often in the software industry, Project Codenames relate to external events, deadlines, or the designer's pets. Example: Windows 95 was called "Chicago" because it was to be unveiled at 1994 Summer CES in Chicago. Sometimes, Codenames are chosen to intentionally mislead the competition in the event of a security leak. I've worked on projects named "The Secret Project" - ooh, big giveaway there! ---------------------------------------------------------------------------- Group Participation Assignment #1: The game we're producing during this course is intended to be a GROUP project. As such, you all have input as to what we're going to name it. As you go through the rest of this lesson, start thinking about a Project Codename, and post your suggestions on the listserver or e-mail them to me, lgp@exo.com. We'll vote on a codename later this week. My suggestion is "Snack Attack," after my favorite Apple II Pacman clone, where I "lifted" some of the features we'll describe later in the lesson. ---------------------------------------------------------------------------- Part 1b - What the General Description IS and how we write it ============================================================ The General Description is THE MOST IMPORTANT PART of the Game Design Specification. It is the blueprint from which all the other specifications (Screen, User Interface, Art, Paradigm, AI, etc.) are derived. Every game idea and feature, all the things covered in the other specifications, are first defined and described here. Its a "Running Overview" of the project, and is open ended - you can add, refine, or change it at any time up until you start coding. If you have a new idea or refinment while writing one of the other specs, you describe it in the General Description. When you start coding your game, you will refer to the General Description constantly. It is the gauge you use to measure how far along you are, and what still still needs to be done. The General Description is a complete description of the game. It describes ALL PARTS of the game from the player's perspective: * What he's supposed to know BEFORE he starts playing * What he sees * What he does * His intended reaction to what he sees and does Your Project Notebook ===================== Ok, how do I get all that information? It's in your Project Notebook! Buy a bound notbook, or folder with a pad of paper in it, and label it with your Project Codename. This is your Project Notebook. Your Project Notebook is your life. Take it with you everywhere you go. You never know when a brainstorm, idea, question, or fundimental design flaw will pop into your mind. Document everything that you think of, especially the problems you don't know how to solve. You'll be surprised how often an insurmountable problem is a trivial matter to solve just a few days down the road. You'll hear or see something that will click in your head and "Whoomp!" there it is. Keep your Notebook nearby when you are playing competing products and take notes. Go somewhere where you can be alone with your game for a period of time without distractions. I sometimes go to Taco Bell and sit there for hours with my Project Notebook and free drink refills. The time flys. Anatomy of a General Description ================================ You'd think you were studying to be a doctor, all the anatomies you're getting. (yes, there will be at least one in each of the next few lessons) A General Description contains at least the following: * The Backstory (RPG's MUST HAVE THIS, optional for most other games) This sets the stage for the game, the world it takes place in, what has happened in the past that led up to where the game starts, what caused the player's character to get to where he is at the beginning of the game. Before you do anything else designwise, sit down for a week and live in the world you are going to simulate in your game. Write down all you learn about this world. * Introduction to the Game This is a brief description of the game, and the cast of characters. Name each character and describe its attributes. * Feature list What innovative technology is used in the game, what sets it apart from other games in its genre? This is useful because it makes you look for nifty new features, and referring to it reminds you of the nifty new features when you're feeling discouraged. BEWARE of CREAPING FEATURISM - Don't go nuts on new features, it makes programming a nightmare and too many options makes a game less fun. Really, Space Invaders doesn't need a Hyperspace Button! * Definitions and Descriptions Here we define all the terms used here and in the other specs that make up the Game Design Spec, including objects of interest and Game Goal objects. We describe their use and availability, and how game characters react to them or interact with them. * Introduction, Title Page, Attention Getter, self running demo, etc. This is what the player sees when he first starts the program. All games need an attention getting title sequence. This is a description of what it's supposed to look like. * Game selection screen What options are available to the player on game startup? This describes what options are on the menu, how and where it appears on what screen, how the player gets there, and how he gets out. * Game start screen What does the screen look like at beginning of game, what are the startup parameters, where are the characters, etc.? What messages, if any, are on screen, and where? Intro music? SFX? * Game play How is the game played? What are the controls? What is the Game Goal? How is the player going to achieve the Game Goal? This can be the longest section of the whole Design Spec. Spell everything out in gross detail. * Game Levels What do they look like? How does the difficulty increase? How does a level end? How does the player know what level he's on? * Milestone Events in Game Every once in awhile, the player needs to be rewarded (or PENALIZED) somehow for reaching that point in the game. Each of these places where something special happens is called a Milestone Event. They are a guage to let the player know he's on the right (or WRONG) track, and will encourage (or DISCOURAGE) him to keep going. Here we list what those Events are, and what happens to the player when he reaches them. * End of the Game What happens when the player loses? What happens when the player wins? What happens when the player gets a high score? Where does the player go when the game is over? How does he start a new game? * Game exit What does the player see when he decides to exit the game? This could be nothing - drop to a blank screen in dos, or it could be five screens of ordering information, or a "You are a wimp for quitting!" message on the screen. Pretty detailed huh? It has to be. Remember what I said in lesson one: YOU MUST KNOW EVERY STINKING DETAIL ABOUT YOUR GAME BEFORE YOU START CODING. By the time you get finished(?) writing the General Description, you'll have described everything the player sees and does, what everything looks like, what happens at every stage of the game. You'll be ready to tackle the other parts of the Design Spec. ============================================================================ End of Lesson 2 - From Vague Idea to General Description - Part 1 of 4 If you have any questions for group discussion post them to the list server. E-mail any other questions, comments or suggestions to lgp@exo.com Mail monetary donations large or small to Lord Generic Productions 1218 Karen Ave Santa Ana, Ca 92704 A Crash Course in Game Design and Production - Euphoria Edition (C) Copyright 1996 Lord Generic Productions - All Rights Reserved ============================================================================ A Crash Course in Game Design and Production ======================================================== Week 2 - From Vague Idea to General Description ======================================================== Welcome back! This is the second installment in "A Crash Course in Game Design and Production. The purpose of this lesson is to introduce you to our course project, and to go through the process of "filling in the details" between our initial GAME IDEA to our project blueprint, the GENERAL DESCRIPTION. We cover a lot of material this week, so I'm splitting this lesson into 4 pieces. This is part 2 of 4: --------------------------------------------------------------------------- Part 2 - Our Course Project - General Description BackStory, Introduction, Characters, Features, Definitions, and Descriptions ============================================================================ Ok, here's what the General Description Looks like for our course project: [NOTE needs no BackStory. It's pretty self explanitory. If ] [a member of the class wants to write something humorous that would tie ] [into the theme of the game, and we vote to include it, I will put it here ] Introduction is a "PacMan" style game, where the player runs through maze after maze eating "dots" while avoiding four "Ghosts" who are intent on "killing" the player's character. When a "Ghost" "catches" the player, He is "killed" and loses one of his "lives." When the player eats all the "dots" on a level, he advances to the next level and continues playing until he loses his last "life." Between mazes two and three, and every three mazes thereafter a short animated "Intermission" sequences play as reward milestones. When the player reaches a score of 10,000 and 50,000 points, he receives an extra "life" as a bonus milestone. Cast of Characters Player - "Packy" - He's round and yellow and eats dots As he moves, he faces the direction he's moving and his mouth opens and closes in a simulate chomping Ghost 1 - "Inky" - He's baby blue Ghost 2 - "Blinky" - He's red Ghost 3 - "Pinky" - She's bright pink with red lips Ghost 4 - "Clyde" - He's orange Ghosts are cute and have big eyes that "look" the direction they are moving. As they move, their "feet" animate in a shuffling motion. Ghosts don't rotate when they change direction like Packy does. When under the influence of an "Energizer" the ghosts turn a "distressed" blue color and are vulnerable for a limited time. [ NOTE I was thinking seriously of making them turn pastel pink and grow ] [ Bunny ears, but the sprite size is too small. ] Game Features * Energizers - Allow Packy to "eat" ghosts, removing them temporarily from his area and giving the player bonus points for each Ghost "eaten." An Energizer's effect is of limited duration and is evidenced by changing the appearance of the Ghosts while they are vulnerable. * Sugar Rush - A limited duration burst of speed allowing Packy to escape the Ghosts, or catch them if they are under the influence of an Energizer. * Safe Zones - Areas where Packy can enter, but the Ghosts can't! * Trap Doors - Doors that Ghosts can go through that Packy can't, in order to trap him! * Bonus Objects - Objects that wander through the maze that will give the player bonus points if Packy "eats" them. * PowerUps - Objects that appear that will give the player bonus points and give Packy a tactical advantage against the Ghosts. * PowerDowns - Objects that appear at "bad times", taking points AWAY from the player and giving Packy a tactical disadvantage against the Ghosts. [NOTE This is funny] * Pull Down Menus with easy keyboard or mouse controls * Game control via keyboard or joystick Definitions =========== "Penalty Box" - At the beginning of each level, all four Ghosts are in a box shaped area called the Penalty Box. They exit the Box in single file, then wander the maze in search of Packy. Whenever a Ghost is "Killed" in the game, his eyes wander from where he was killed, back to the Penalty Box and he is reincarnated. "Energized Ghost" "Non-Energized Ghost" - Whenever packy "eats" an "energizer" (see above), the Ghosts turn blue and become vulnerable for a limited duration. During that time, they are "Energized Ghosts." After a level related time interval, the Ghosts return to their normal, invulnerable, hostile state. Then they are "Non-Energized Ghosts" "Eat" "Eating" "Being Eaten" - As Packy moves around the maze, his mouth opens and closes. Whenever he moves over a screen object, dot, bonus object, energizer or "Energized" Ghost, they disappear from the screen. They have been "eaten" by Packy. "Dot" - At the beginning of each level, there are small, round objects distributed evenly across the play area. These are "dots." Packy must eat all the dots on a level to complete it. "Life" "Lives" - One "life" is one chance to complete the maze and continue playing the game. The player begins the game with three lives, and gets a bonus life at 10,000 and 50,000 points. The player loses a life when he is "Killed" by a Ghost. "Kill" "Killed" "Killing" - Whenever a non-energized Ghost and Packy occupy thedame space at the same time, Packy is "Killed" by the Ghost. Whenever Packy is Killed, he loses one Life, and if he has any lifes left, the level begins again with the Ghosts and Packy in their Level Start positions. If Packy EATS an energized Ghost, it is Killed, its eyes wander back to the Penalty Box and he is reincarnated. Object Descriptions =================== Bonus Objects Pumpkin - Its orange and looks like a Jack o Lantern. Player gets 200 points for eating a Pumpkin. [Group Assignment #2 - I want suggestions from the group as to other Bonus ] [ objects, and point values. We'll vote on them later this week. ] Powerup Objects - Garlic and Towel are of limited duration. Candy Bar - Recharges Packys "Sugar Rush" capability to full strength. Garlic - Makes Ghosts run away from Packy. Towel - Covers Packys eyes, so Ghosts can't see him. PowerDown Objects - These are all limited duration. Steak - Makes Packy slow and sluggish. BreathMint- Makes Packy Irresistable. Ghosts take the most direct route to him at 1 1/2 times normal speed. Popsicle - Gives Packy "brain-freeze," making him hesitate between actions. Mushroom - Magic Mushroom, makes Packy "stoned" and causes him to wander aimlessly for awhile, changing direction at random. ============================================================================ End of Lesson 2 - From Vague Idea to General Description - Part 2 of 4 If you have any questions for group discussion post them to the list server. E-mail any other questions, comments or suggestions to lgp@exo.com Mail monetary donations large or small to Lord Generic Productions 1218 Karen Ave Santa Ana, Ca 92704 A Crash Course in Game Design and Production - Euphoria Edition (C) Copyright 1996 Lord Generic Productions - All Rights Reserved ============================================================================ A Crash Course in Game Design and Production ======================================================== Week 2 - From Vague Idea to General Description ======================================================== Welcome back! This is the second installment in "A Crash Course in Game Design and Production. The purpose of this lesson is to introduce you to our course project, and to go through the process of "filling in the details" between our initial GAME IDEA to our project blueprint, the GENERAL DESCRIPTION. We cover a lot of material this week, so I'm splitting this lesson into 4 pieces. This is part 3 of 4: ---------------------------------------------------------------------------- Part 3 - Our Course Project - General Description B Title screen, Demo, Game Selection Screen, Game Start, Game play ============================================================================ Title Screen and Attention Getter When the player starts the program from Dos, the screen is cleared to BLACK. Then the Game Title appears in color cycling 3D letters on a big sign with "chaser lights" animating around it. Under the sign the words "Presented by:", "Lord Generic Productions","And","Euphoria Game Design Team" "Starring:" "Inky", "Blinky", "Pinky", "Clyde" ,"and Packy" appear in sequence. While each character's name is presented, (s)he appears on alternating sides of the screen and move toward the sign and stop. Packy appears under the sign, between it and his name. All characters are animating, and continue to animate throughout the entire sequence. During this initial sequence, Program "About" information, including Game Title, Designer, Artist,...,begin scrolling across the bottom of the screen in a one-line high animated "strip sign" and continue scrolling until Play Game is selected. After all the characters are introduced, the Game Selection Box appears in the lower 1/3 of the screen, and the player can select "New Game" "Options" or "About this Game." Also if at anytime during the intro animation the player presses a key, the screen is redrawn with all characters in their final position, and the Game selection screen appears. ---------------------------------------------------------------------------- Self-Running Demo If the player doesn't hit a key within 30 seconds after the Game Selection Box appears, the game goes into demo mode. The Game Screen draws and one of three "pre-recorded" games is replayed until packy is killed by a ghost or until the player hits a key. If the player hit a key, the screen switches back to the title page\game selection screen and he can continue. Otherwise the "About" screen animations play, then the "Attention Getter" Title sequence starts over. ---------------------------------------------------------------------------- "About This Game" Screen If this is called from the Title Screen, the screen is cleared to medium blue and the sequence starts. If this is called during a game or after the Self-Running Demo, the "Game Window" is cleared to medium blue and this sequence plays there. The "About this game" credits split into three pages of text, the first page has design, art, LGP, and EGDT credits on it. The second page has Contributing Authors and Course Information. Page three has "For more information" info on Euphoria, the Course, and LGP. At the bottom of each page is a "Press a Key to Continue" message, and the player hits a key to step through them. If the player does nothing the screen advances after thirty seconds or so. After the last screen, the program goes back to wherever called it. While the player is reading the text, Packy is chased around the screen VERY fast by the four Ghosts. --------------------------------------------------------------------------- Game Options screen The Player can choose the following configuration options: Number of players - This can be one or two. Sound - This can be ON or OFF. Controls - The can be Keyboard or Joystick (maybe mouse) Skill Level - This can be Easy, Medium, Hard, or Nuts Starting Maze # - This can be 1-4 Exit - Takes you back to where you came from --------------------------------------------------------------------------- Beginning a new game When New Game is Selected, the screen is cleared, the Game Screen is Drawn. The Game Screen has 3 parts they are: 1) Pull-Down Menu Bar - It is invisible until the player hits the ALT key. It has options such as New Game, Resume Game, Quit, Options, and About which take the player to the appropriate screen. 2) Game Window - This is where the Game is played, and where the About This Game sequence plays. At Game Start, it is cleared, and the Maze and dots are drawn. Inky, Blinky, Pinky, and Clyde are placed in the penalty box, and Packy is placed in one of 4(?) starting positions in the Maze. The Energizers are placed in the corners of the Maze, and begin animating. 3) Game Status Window - This is next to the Game window and is where the player's Score and Number of Lives left is displayed. At Game Start, the appropriate player's score is set to 000000 and his lives is set to three. Packy's "Sugar Rush" level is set to 100% After the Game Screen in drawn, "Level 1" appears in a chaser-lighted sign momentarily in the middle of the Game Window, then disappears. The Level Number is also drawn inside the Penalty Box, (behind the Ghosts) so the player can always see what level he's on. As the Level sign is onscreen, the "get ready" music plays. When the music is over, the Sign disappears too. And the game begins. --------------------------------------------------------------------------- Game play When the game begins, the Ghosts leave the Penalty Box one at a time, Blinky first, followed by Pinky, Inky, and Clyde. They wander the maze in dogged persuit of Packy. Player controls Packy with the Joystick, Arrow keys, or "Snack Attack Keys", AZ,. [SPACE] stops Packy wherever he is. He continues to "Chomp in place" until he is moved again. Pressing [ENTER] Gives Packy a "Sugar Rush," which allows him to move at twice(?) normal speed for a limited duration, up to 10 seconds per level, unless recharged by a Candy Bar. Pressing the [ENTER] key again returns Packy to normal speed. The Sugar Rush can be used again until Packy's Sugar Rush Level is 0% The Player's Primary Game Goal is to eat all the dots in the maze. When he has eaten all the dots, the level is over. The Player's Secondary Game Goal is to eat as many Ghosts as he can by strategic use of the Energizers. When Packy eats an Energizer, the Ghosts become "edible" for a short period of time and will give the player a bonus that increases with the number of Ghosts eaten in rapid succession, as: First Ghost - 200 points Second Ghost - 400 points Third Ghost - 800 points Fourth Ghost - 1600 points When a Ghost is eaten, he disappears, and his "eyes" appear. They wander back to the penalty box very fast and once inside, the Ghost "reincarnates" inside the Penalty Box. The Ghost stays inside, pacing back and forth until his "Penalty Time" is completed, then he emerges from the box and continues his persuit. If there are Ghosts inside the Penalty Box when Packy eats an Energizer, they also are affected, but no Ghosts reincarnated while that Energizer is active is affected. It is possible for the player to time his moves so that Packy can eat an Energizer, eat one or more Ghosts, then eat another Energizer and get to the Penalty Box in time to catch the newly reincarnated Ghosts as they try to leave. After a period of time, the effect of the energizer wears off and the Ghosts become lethal again. This change is evidenced by the Ghosts "Flashing" five times between their normal and Energized images. During this transition period, the Ghosts are still edible, but chasing down a flashing Ghost is a High Risk activity. If the player's timing is off, and he catches up to the ghost too late, he's killed. The duration of an Energizer's effect decreases by the level the Player is on: Level 1 - 10 seconds Level 2 - 8 seconds Level 3 - 6 seconds Level 4 - 4 seconds Level 5 - 2 seconds The last two seconds of each duration are transition periods where the Ghosts are "Flashing." From level 5 on the Ghosts begin flashing right away. If Packy eats another Energizer while the last one is active, the Ghosts that were affected by the first one will continue to be affected for the entire duration of the second Energizer. The Player's Tertiary Game Goal is to eat Bonus Objects which appear in the Maze from time to time, giving the player bonus points. Each Level has a different Bonus Object associated with it, with the Bonus Point Value increasing with each level. The Bonus Objects are animated. Level Object Point Value Animation Level 1 Pumpkin 50 Blinks its eyes Level 2 100 : : ============================================================================ End of Lesson 2 - From Vague Idea to General Description - Part 3 of 4 If you have any questions for group discussion post them to the list server. E-mail any other questions, comments or suggestions to lgp@exo.com Mail monetary donations large or small to Lord Generic Productions 1218 Karen Ave Santa Ana, Ca 92704 A Crash Course in Game Design and Production - Euphoria Edition (C) Copyright 1996 Lord Generic Productions - All Rights Reserved ============================================================================ A Crash Course in Game Design and Production ======================================================== Week 2 - From Vague Idea to General Description ======================================================== Welcome back! This is the second installment in "A Crash Course in Game Design and Production. The purpose of this lesson is to introduce you to our course project, and to go through the process of "filling in the details" between our initial GAME IDEA to our project blueprint, the GENERAL DESCRIPTION. We cover a lot of material this week, so I'm splitting this lesson into 4 pieces. This is part 4 of 4: ---------------------------------------------------------------------------- Part 4 - Our Course Project - General Description C PowerUps PowerDowns Game Levels, Milestone Events, End of Game, Game Exit ============================================================================ PowerUps Every once in awhile, a PowerUp object will appear in the maze. If Packy eats it, he will have a tactical advantage over the Ghosts for a limited duration. The duration of effect decreases as the level increases, just like the Energizers. PowerDowns Every once in awhile, a PowerDown object will appear in the maze. If Packy eats it, he will have a tactical disadvantage over the Ghosts for a limited duration. The duration of effect decreases as the level increases to keep the game from becoming too hard. The duration follows the same chart as Energizers and PowerUps. Game Levels Each "Level" is one maze that the Player guides Packy through. When he eats the last dot in that maze, the Player has "Completed" the Level and advances in the game, either to the next maze or to a Milestone Event Animation and then to the next maze. There will be five different maze layouts the player must navigate in the game, each requiring its own strategies to complete. Packy can start any maze in any of four locations. The Maze changes after level 2 then every 3 mazes after that. The starting Maze is chosen at random from the 5 designs. Once a Maze is used we don't see it again until all the other Mazes have cycled through. Inside the Penalty Box of each maze, "Level X" is displayed, where X is the current Level number, so the player knows what level he's on. As the game progresses from level to level, the difficulty increases. This is achieved by increasing the speed of Packy and the Ghosts, and Decreasing the duration of Energizers and PowerUps. PowerDowns also decrease in duration to keep the game fair. Character Speed by Level Level 1 1 pixel per animation frame Level 2 1.5 pixels Level 3 2 pixels Level 4 2.5 pixels Level 5 3 pixels Each additional Level add .5 pixels to the character speed. Milestone Event Animations After Level 2 and every 3 Levels thereafter, there is an "Intermission" animation. Each is about 10 seconds long and is humorous. There will be 10 animated sequences, one of these will be selected at random and played at each milestone event. After an animation is played, it cannot be selected again until all the other animations have cycled through See Milestone Animation Specification for details on each animation. ===================================================================== Group Participation Assignment #3 We need 10 animations, start brainstorming ideas. ===================================================================== End of the Game The Game ends when the player loses all of his Lives. At that point, Words "Game Over" appear in a Marquee Sign. If the player doesn't have a hi-score on the list, the sign changes to "You Suck, try again!" [Note: I just wanted to see if you are paying attention] If the player made the High-Score list, the Sign says "You made High-Score # ___! Enter your Name:" Then the player can enter his name. When he hits [ENTER] His name and score are drawn in the High-Score Box in the Status Window, and the Sign changes to "Play Again YES NO." If the player chooses to play again, everything is reset and a New Game begins. If the player chooses NOT to play another game, the screen clears and we go back to the Title\Game Select Screen and the program waits for input and goes through the demo cycle. Game Exit If the player chooses to exit to Dos, the program goes to the "About this Game" sequence, then switches screen to text mode, displays an ansi "Thank you for playing this Game" message and drops the player back in Dos =========================End of General Description========================= ok that's it. By now you know just about as much about our course project as I do. If you have any questions, or if I've left out anything we need to have spelled out, post them to the listserver or e-mail them to me. Do you see the method behind the madness here? Now if we ever have a question about the game, we know where to look to get the answer. If there is NO answer, we DECIDE the answer and add it to the General Description. Next week we Spec out the Screens and User-Interface. It will probably be a two parter. It seems like a good idea to separate theory from practice in these. The first part will tell you about what we're doing and what kinds of information we need to put in the Spec, then parts 2-N will be the actual Spec for our project. As we add new parts and update old ones, I will revise the files on the Web site, so the current verion is always there. By the way, this game looks like its going to be a LOT of fun to play. I've always enjoyed PacMan Variants. This should top anything I've seen. I'm toying with the idea of having a Maze Editor available. I'm Specing that out now. It won't be part of the course, but would be pretty handy to have when we get to the mazes. If any of you want to work on a side project and build it for us, let me know. ============================================================================ End of Lesson 2 - From Vague Idea to General Description - Part 4 of 4 If you have any questions for group discussion post them to the list server. E-mail any other questions, comments or suggestions to lgp@exo.com Mail monetary donations large or small to Lord Generic Productions 1218 Karen Ave Santa Ana, Ca 92704 A Crash Course in Game Design and Production - Euphoria Edition (C) Copyright 1996 Lord Generic Productions - All Rights Reserved ============================================================================ A Crash Course in Game Design and Production ======================================================== Week 3 - Screen Design and User Interface Specification ======================================================== Welcome back! This is the third installment in "A Crash Course in Game Design and Production. Like last time, this lesson is in two parts. In PART ONE, we'll discuss Screen Layout and User Interface issues. In PART TWO We'll write the third part of the Design Spec for our Course Project, the Screen Design and User Interface Specification. ------------------------------------------------------------------------------ Part 1 - The Basics of Screen Design and User Interface Issues ------------------------------------------------------------------------------ What is a "Screen Design?" =================================== A Screen Design is just a plan for how and where you intend to put things on the screen. There are usually many things you need to put on the screen, such as the player's score, number of lives left, Game Logo, level number, information messages, or whatever. It's your job as the Game Designer to determine what items need to be on the game screen, what they will look like, and where they need to go. Good Screen Design takes practice, and you will usually go through four or five designs before you get it "right." How do you DO Screen Design? ============================ The first step in screen design is referring back to the General Description to see what screens we NEED to design, what NEEDS to be on each screen, and if elements need to move around, what are they doing? [Note: Often I do this backwards, I do a rough screen design\layout to see WHAT I NEED TO INCLUDE IN THE GENERAL DESCRIPTION. Most of the time when I get to the Screen Design Spec, I already have all the screens drawn up and then just have to describe what's there in the Screen Design Spec.] Make a detailed list for each screen, go over it in your mind and elaborate and expand on what was in the General Description. The General Description is a starting point, a quickie overview of what you will include in the Screen Design Spec. Now it's time to fill in the details. User Interface items ==================== Parts of the User Interface include Pull Down Menus, screen "windows," player information - scores, number of lives, etc, system messages, about box, etc. you need to figure out what these should look like and where they need to go. We'll discuss HOW these work below in the User Interface Specification section, but its CRITICAL to place these items where they can be easily seen by the player. The player should NEVER have to look for something, and should NEVER have to "figure out" your interface works. "Standard" places for player information are on the right side of the screen or at the top of the "play screen" Pull Down menus are ALWAYS at the top left of the screen, with New\resume game options on the left and Help\about on the right of the menu bar. The next step is to go into your paint program and figure out how big things need to be and lay up a Mock Screen Shot of each screen. [NOTE: I prefer using Autodesk Animator Pro for this. It handles all 256 color screen resolutions, allows you to set your image size, or clip a portion of the screen and save it as an image, shows you screen coordinates when you move things around, lets you scale and rotate pieces arbitrarily, has GREAT color palette handling, will let you have multiple versions of the screen at the same time, and will let you save in BMP format so you can load your images into Euphoria. (it's native file format is GIF, which I prefer.) Find a program you like using that has these features. Avoid Windows(tm) paint programs, they will give you more trouble than they are worth. I'll tell you why when we get to the Art Specification lesson.] Draw mockup pieces in various sizes and try different screen layouts, go through each animation in your head and try to see what each piece would be and where it will end up on the screen. Move the pieces around until you get a layout you like. Then write down how big everything is, and where it's located on the screen. Once you have all your mock up screens and notes, its time to write up the Screen Design Spec. Anatomy of a Screen Design Specification ======================================== Here's ANOTHER anatomy for you. The first part of the Screen Design Specification is called the General Design and Layout. It basically lists parts and features common to all screens, including color scheme, border width, etc., followed by the General Interface Specification (see below) It also lists all the screens to follow with one-line descriptions condensed from the General Description. Then for EACH screen, the Screen Design Specification contains AT LEAST the following: * Screen Title * Screen Description Write in EVERYTHING you can think of about this screen, what information needs to be on it, go step by step through any animation sequences, spell everything out. Include player interaction and controls to exit the screen. * Screen Layout What goes where, and how big it is in pixels. Use coordinates for where each piece resides, section by section through the layout. You will need this information for the ART SPEC and when it comes time to write the code to put it on the screen, you'll know what numbers to plug in to the drawing routines. * Screen exit What happens when we exit this screen, where do we go? * User Interface Specification Since you need to define and explain your User Interface issues for EACH SCREEN, it makes sense to make the User Interface Specification part of the Screen Design Specification. In Part Two of this lesson we'll show you the completed Screen Design spec for each screen of our course project. ----------------------------------------------------------------------------- What is a User Interface? ========================= Your User Interface is the mechanism your game uses to get information to and from the player. It consists generally of two parts: User Controls and Feedback Systems. * User Controls Collectively, this is the set of controls the player used to affect the program, including character movement\actions, pull down menu choices, options screen controls, etc. * Feedback Systems - These are anything that conveys information to the player, such as his Score display, Number of Lives, Level Number, Sound Effects (SFX), Visual Effects (FX), sound volume, text messages, about box, etc. The Key to intelligent User Interface Design is simplicity. Your feedback systems must be crystal clear, and your User Controls must be easy for an idiot to navigate without checking the manuals. If he has to think about how to find the information he needs you've lost him. The idea is to get him hooked and thinking about THE GAME and not THE INTERFACE. MICHAEL'S RULES OF THUMB FOR USER INTERFACE DESIGN ================================================== DON'T GET FANCY WITH YOUR USER CONTROLS OR FEEDBACK SYSTEMS JUST TO SEEM MORE INTELLIGENT OR SOPHISTICATED. It seems pretentious. I once saw game that had "Sound Attenuation" instead of a "Volume" control. It did the same thing only backwards. When you turned UP the Attenuation, the volume went DOWN. That's what "Attenuate" means, to reduce. The author was trying to make people think the program was more sophisticated than it was. DON'T DO THINGS JUST FOR THE SAKE OF DOING THEM. Just because you CAN do something doesn't mean you SHOULD do something. Some programs have menus that have sub-menus that have sub-menus that have sub-menus. While it's nifty to have an interface engine capable of handling complex menu structures, it wastes the player's time to have to wade through five levels of menus to change something. It's also very frustrating for the player searching for information he needs. HAVE AS FEW MENUS AS POSSIBLE. It's better to have 5 menus with 10 items each than 10 menus with five items each. Break down your controls into reasonable categories, like game, options, sound, etc. then use those category names for your pull down menus. HAVE HOT-KEYS FOR EVERY COMMONLY-USED MENU CHOICE. A Hot-Key is a keyboard shortcut to activate a menu item. Every option that will be regularly used should have a Hot-Key. Examples: Q to Quit, N for New Game, S for Sound, A for About, O for Options, etc.. It's better to have EVERY option Hot-Keyed, but you don't see that often. You must at least have the Menu Names Hot- Keyed, pressing the key bringing up the menu for you to choose an option from. ALWAYS USE THE CONTROLS PEOPLE EXPECT YOU TO USE, AND PUT MENU OPTIONS WHERE PEOPLE EXPECT TO FIND THEM. There are "standard" menu layouts and keyboard commands that people EXPECT your game to use. For example, for most character movement and actions, you WILL use the Arrow Cursor Keys, Ctrl, Alt, and Space Bar. Text pages scroll with the up\down arrows and PGUP\PGDN. DON'T RE-INVENT THE WHEEL, EVEN IF YOU DON'T LIKE IT. People hate having to learn new player controls. It's easy to check your biggest competitor's game and use the same controls they use for the same functions, and organize your menus roughly the same way they do. More than likely, your audience is already playing THEIR game, so the switch to YOUR game should be as painless as possible. If you have a LOT of player control options, say for a fighting game, put them in a logical keyboard layout, and let the player be able to customize the character controls if possible. IF YOUR PROGRAM IS MOUSE DRIVEN, MAKE ALL YOUR MENUS MOUSE CLICKABLE. Don't EVER make your players use the mouse for some things and not other things. EITHER YOUR PROGRAM IS MOUSE DRIVEN OR IT ISN'T. Nothing frustrates players more than not being able to click on the item they want to select, when they can click on other buttons on the SAME SCREEN. If you don't know how to make EVERYTHING mousable, don't make ANYTHING mousable. DON'T CLUTTER THE SCREEN WITH USELESS INFORMATION. You are probably keeping track of more information than the player needs to know at any given time. Only display what he NEEDS to know all the time, and make any information he needs only once in a while a hot-key away. You can have a status box that has multiple pages of information. Order the information on the pages by relevance to the player let the player call up the page he needs, rather than having everything on the screen at once. Instead of making him scan all over the screen to find what he needs to know, he knows it's in the box, on page 3, so he hits "3" on the keyboard and it pops up in the box. ----------------------------------------------------------------------------- Anatomy of a User Interface Specification ========================================= At the end of the General Screen Design and Layout is the General Interface Specification, which describes the Interface issues common to all screens. Then for each screen we need: * Player Controls Whatever the player can do on this screen, and how he does it. how he calls up any menus, how he can select something, Character controls, What he does to interact with the game. * Menus, choices, and functions If this screen has special menu options, what they are, how the player changes those options, and how the game will let him know of those changes. Example: When the player clicks the VOLUME + button, the sound volume increases, the VOLUME BAR GRAPH gets longer and the SAMPLE TONE is played at the NEW volume level. * Feedback Systems What player information is displayed on the screen, where it is, how will how will the player access it? Also what FX, SFX are needed to alert the player of his status when he reaches a Milestone Event in the game. Anything from a printed score to a minute long cinematic animation is listed here in gross detail. In Part Two, I'll show you how the Screen Design and User Interface Specification looks for our Course Project. ============================================================================ End of Week 3 - Screen Design and User Interface Specification Part 1 - The Basics of Screen Design and User Interface Issues. If you have any questions for group discussion post them to the list server. E-mail any other questions, comments or suggestions to lgp@exo.com Mail monetary donations large or small to Lord Generic Productions 1218 Karen Ave Santa Ana, Ca 92704 A Crash Course in Game Design and Production - Euphoria Edition (C) Copyright 1996 Lord Generic Productions - All Rights Reserved ============================================================================ Week 3 part 2 is still pending. It should be available by Jan 25,1997 sorry for the delay. ============================================================================ A Crash Course in Game Design and Production ======================================================== Week 4 - Basics of Computer Art and Art Specification ======================================================== Welcome back! This is the fourth installment in "A Crash Course in Game Design and Production. Like last time, this lesson is in multiple parts. In PART ONE, we'll discuss computer graphics in general, and what we need to know before we can talk about ART. In PART TWO We'll discuss the ART Specification, what it is and what we need to put in it. In PART THREE we will write the fourth section of the Design Spec for our Course Project, the Art Specification. ---------------------------------------------------------------------------- Part 1 - The Basics of Computer Art. ---------------------------------------------------------------------------- Before we can have any meaningful discussion of computer game art, we need to get some terms defined and some concepts explained. In this section we'll talk briefly about Computer Graphics, Video Modes, Resolution, Aspect Ratio, Pixels, Palettes, Masking, Sprites, Backgrounds, and Anti-aliasing, then briefly about what to look for in a graphics\animation editing program from a game design standpoint. Video Modes The computer is capable of displaying information in many formats: It could be text, a picture, animation, or sound. For our purposes, we are working with images. The Video Mode you use determines what kind of images you can display, how big they can be, and how many colors the image may contain. Video modes can be classified into two groups, Text or Graphics modes. In Text modes, all you can display are letters and words. Not real useful for most games. Language Wars is an example of a game written in Text mode. Graphics modes allow you to display images and animations as well as text in 16 or 256 colors. There are multiple Graphics Modes to choose from, each will allow you to display different amounts of data on the screen. Each datum (singular of data, the smallest displayable chunk of information)is shown on your monitor as a PIXEL (Picture Element - part of a Picture, an image displayed on your screen.) A Full-Screen image in different video modes contains more or less Pixels, and may contain more or less colors than in other video modes. Example: Video Mode 18 can display an image that is 640 pixels wide and 480 pixels high in up to 16 colors. Video Mode 19 can display an image that is 320 pixels wide and 200 pixels high, but in 256 colors. Video Mode 256 can display an image that is 640 pixels wide and 480 pixels high in 256 colors. Note: If you draw a Full-Screen picture in Mode 19 and display it in mode 256, say, the image will be about 1/4 the screen size now! Since the Video Mode can display more Pixels, the Pixels themselves are smaller. Resolution When we discuss Video Modes, it is useful to refer to them by the number of Pixels they can display Width x Height. Instead of saying "Mode 256" or "Mode 18", we'll say "640x480 mode" with the number of colors implied. This is called RESOLUTION. Similarly, Mode 19 is "320x200" and Mode 260 is "1024x768." See graphics.e for a list of valid video mode for Euphoria. When we talk about the Resolution of an IMAGE, we are referring to how wide and how tall it is, not necessarily what Video Mode it was created in or should be displayed in. For instance, in our class project, our characters will be 15 pixels wide and 15 pixels high, so we'll call it a "15x15" image. Aspect Ratio The Aspect Ratio is the ratio of the Pixel Width to Pixel Height for a particular video mode. In 640x480, 800x600, and 1024x768 modes, the aspect ratio is 1:1 or 1, meaning the pixels are square. In 320x200, the aspect ratio is 1.21:1 or .82, meaning the pixels are higher than they are wide. If you create an image in 320x200 mode and display it in 640x480, it will appear slightly squashed, since the pixels are 21% shorter in this mode relative to their height than in 320x200 mode. Pixels and Palettes A picture on the screen is made up of different colored Pixels. The number of colors available to the image is determined by the current Video Mode. For 256 color Modes, there are 256 colors available. These colors are stored in a table called the Color Palette. These 256 colors are chosen from the VGA Palette of 262,144 colors. Each Pixel can have a value from 0-255, which tells the video screen which of the 256 colors in the Color Palette to display at that Pixel location. The pixels themselves have NO COLOR INFORMATION, they just tell where to look in the Color Palette to get the color you want. If you change the colors in the Color Palette, any pixels that were assigned to those colors also change. If you load an image created with one Color Palette and display it using a different Color Palette, the colors will be wrong. All art for your game MUST BE DRAWN USING THE SAME COLOR PALETTE. It's not enough to have the same colors, they MUST be in the same color position in the Color Palette. If you have two images, one with Blue, say in palette position 5 and the other with the EXACT SAME SHADE OF BLUE in color position 18, if you display them together, the second Blue may appear GREEN,ORANGE,or AVOCADO, depending on what is in color position 18 in the current Color Palette. Images and Animation Frames An Image is a rectangular collection of pixels which contains something visually recognizable, like a picture of your mom. An Animation Sequence is a collection of images, which when viewed sequentially expresses an action of the visually recognizable thing, like your mom sticking her tongue out at you for digitizing her. Each individual image in the Animation Sequence is an Animation Frame. When we want to make our Ghosts, say, roll their eyes, or move their feet, we need to draw multiple images of the Ghost, each one making a portion of the whole action. If we want him to roll his eyes in 10 frames, i