1 / 38

CIS 487 - Game Design I Chapter 2 and 3

CIS 487 - Game Design I Chapter 2 and 3. Blake Farrugia 10/5/2011. Project and Framework Structure. This is a good point to go over how both projects are structured in FlashDevelop and how the downloaded sample code from Apress is structured

dant
Download Presentation

CIS 487 - Game Design I Chapter 2 and 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CIS 487 - Game Design IChapter 2 and 3 Blake Farrugia 10/5/2011

  2. Project and Framework Structure • This is a good point to go over how both projects are structured in FlashDevelop and how the downloaded sample code from Apress is structured • The archive from Apress lists a number of different chapter folders and a classes folder • Each chapter folder holds FlexSDK(FlashDevelop) and FlashIDE project folders • The classes folder culminates all of our sharable game framework code

  3. FlashDevelop Project Package • FlashDevelop stores all code, packaged or otherwise, in the src folder • With this in mind, game source classes would be stored in /src/classes/com/efg/framework • Package use will be as such: • package com.efg.framework { … }

  4. Get Project Working w/ Framework • Here we will detail the structure that the book follows on each chapter project. • source • Classes • Com • Efg • framework • Projects • Game • FlashIDE • FlexSDK

  5. Get Project Working w/ Framework • Source – main root document folder • Classes – framework package goes in here; structured as /com/efg/framework/ • Projects – Project files linking to Classes go here. Multiple game projects can use framework classes; structured as /projects/gamename/FlexSDK/

  6. Further FlashDevelop Structure • From the FlexSDK folder, FlashDevelop will branch projects into its own structure: • Bin • Lib • Obj • Src – You will add further package structure here • Com • Efg • Games • gamename

  7. Project Package • To create a project using FlashDevelop: • Set folder structure as we’ve previously discussed • Open FlashDevelop, start new Flex 3 Project • Give name, set path to source/projects/gamename/FlexSDK/ • Set package as com.efg.games.gamename • DO NOT create project folder automatically via FlashDevelop

  8. Classpaths • Now the project is created, but we need to tell FlashDevelop where our game framework is • Click Projects, then Properties. Click on Classpaths • Add the path that points to our framework, which should be: /source/classes • Done! Now you can create code in your project and reference objects/classes in the game framework.

  9. Building the Game Framework • Chapter 1 had a simple framework, and we are going to build on that. • Chief focus is on - organization and reuse. • This framework isn’t about limiting you to a specific design pattern, you should feel free to modify as needed. • This framework is to assist actual game logic, not hinder it.

  10. GameFrameWork.as • A state manager that also handles messages to all other framework classes. • Holds game loop and clock that will be used throughout the framework. • Switches states based on variables. • States can apply to different menus, game-specific conditions, or even title/gameover screens

  11. Finite State Machines • A finite state machine is a device that tracks its state • New states have defined their own controls that the machine will follow once its state changes • Our game loop is a finite state machine. • The framework that controls our loop is a function reference machine. Similar to a state machine, but reliant on function-switching instead of class-switching.

  12. // switchSystem state is called only when the state is to be changed (not every // frame like in some switch/case based simple state machines public function switchSystemState(stateval:int):void { lastSystemState = currentSystemState; currentSystemState = stateval; trace("currentSystemState=" + currentSystemState) switch(stateval) { case FrameWorkStates.STATE_SYSTEM_WAIT: systemFunction = systemWait; break; … case FrameWorkStates.STATE_SYSTEM_GAME_OVER: systemFunction = systemGameOver; break; } }

  13. FrameWorkStates.as • Class that holds all data states for use in GameFrameWork.as • To start, this class will hold 10 states • States follow the naming practice: “STATE_SYSTEM_NAMEOFSTATE”

  14. package com.efg.framework { public class FrameWorkStates { public static const STATE_SYSTEM_WAIT_FOR_CLOSE:int = 0; public static const STATE_SYSTEM_TITLE:int = 1; public static const STATE_SYSTEM_INSTRUCTIONS:int = 2; public static const STATE_SYSTEM_NEW_GAME:int = 3; public static const STATE_SYSTEM_GAME_OVER:int = 4; public static const STATE_SYSTEM_NEW_LEVEL:int = 5; public static const STATE_SYSTEM_LEVEL_IN:int = 6; public static const STATE_SYSTEM_GAME_PLAY:int = 7; public static const STATE_SYSTEM_LEVEL_OUT:int = 8; public static const STATE_SYSTEM_WAIT:int = 9; public static const STATE_SYSTEM_MOCHI_AD:int = 10; public static const STATE_SYSTEM_PRELOAD:int = 11; public static const STATE_SYSTEM_MOCHI_HIGHSCORES:int = 12; public static const STATE_SYSTEM_PAUSE:int = 99; } }

  15. BasicScreen.as • BasicScreen – very simple display class for a screen. Can center text and hold one button for advancing states • This is done as almost as an abstract class will be enhanced or extended in any real game • Creates a button that can respond to 3 mouse events • The listener functions for these events are defined here as well

  16. SimpleBlitButton.as • SimpleBlitButton – creates a clickable button class with animations states built in. • Demonstrates sprite blitting – raster operations combining several bitmaps into one • The button is created completely in code and uses a simple color change in the button for the mouse events defined in BasicScreen.AS • Defines a blitting function SimpleBlitButton, is not using any graphics card blitting support

  17. SimpleBlitButton class • Used to create UI buttons with a background color and a text label • Uses BitMapData to create the background and Bitmap instance to hold the BitMapData instance • A function changeBackGroundColor is defined to swap the button background color • Text is drawn into the BitMapData object to demonstrate its use in dynamic display object

  18. Scoreboard.as • This class which displays score metadata to screen in a formatted area • Allows Main.as to create and position as many instance of SideBySideScoreElement class as needed for the UI objects • Each game will have a customized score board by ehancing the Main.as stub • Good demonstration of passing data via events to update score properly

  19. SideBySideScoreElement.as • A helper class to simplify coding of ScoreBoard.as like CustomBlitButton.as • Can output a specific label combined with dynamic data • It simply displays a text string followed by a number

  20. Game and Custom Event classes • The Game class will be an extendable object from which most of our other framework entities will flow • This class will have basic variables to expand form to form more intricate game classes later • Custom event classes are used to pass all information between classes at specific triggers

  21. Custom Events • CustomEventButtonID.as extends event • Passes id value and an instance to an event listener. • Used when multiple buttons are assigned to one listener • Allows BasicScreen instances to share the same listener functions if they rely on SimpleBlitButton

  22. Custom Events • CustomEventLevelScreenUpdate.as- pass update text from Game.as to BasicScreen instance called levelInScreen • levelInScreen has the ability to display custom text between each level • The event listener will pass with a value passed when the event is fired off

  23. Custom Events • CustomEventScoreBoardUpdate.as – pass update data from Game.as to instances of the ScoreBoard class • The Main class will listen for the event and pass it on to the ScoreBoard class instance

  24. Creating Game Timers • Our game timer runs our loop function; without the timer, we’d be in a tough spot • Flash implements “frame-based” timers (timers that judge time passed based on frames processed) • Event.ENTER_FRAME is the standard frame event called for a timer. It tries to run update code on every frame called. • Framerate of .swf = 30 frames per second; event called 30 times a second (roughly)

  25. Timers cont. • A second timer interface is the Timer class. • Similar to frame events, the timer will call the loop function after so many seconds elapse • If a timer’s delay interval is set to 100 (registered as miliseconds), then the loop will be called 10 times a second. (1 second = 1,000 miliseconds) • The framework uses the Timer class

  26. Chapter 3 – First Full Framework Game • The rest of Chapter 2 is a Framework reference • It details source code and classes that the framework is made up of • From here on, Chapter 3’s game will be discussed • Important classes will be pointed out

  27. Project Creation • Open FlashDevelop • Create a new Flex 3 project named superclick • Make sure the path for the project is set up like the other paths we’ve discussed: • /source/projects/superclick/flexSDK/ • Do NOT have FlashDevelop automatically create the project folder. • Go to Project>Properties>Classpath • Add the pathway to your framework classes, which should be /source/classes/

  28. Game Basics – Super Click • Player : The mouse • Objective : Click all good blue circles while avoiding bad red circles • Source: ch3_superclick/flexSDK/ • This will be the first game using the book’s framework.

  29. Game Basics cont. • 4 screens for player • Title: contains OK button and text Super Click • Instructions: contains OK button and text Quickly Click Blue Circles • Game Over: contains OK button and text Game Over • Level: contains the text Level and level variable • Each will be an instance of BasicScreen class, which uses BasicBlitButton class for input

  30. Game Basics cont. • Levels parameterized and difficulty adjustments are computed using mathematics formulas • Classes that manipulate data from framework that need to customized or built for this game • Main.as, SuperClick.as, Circle.as, ScoreFieldText.as

  31. Classes – Main.as • This acts as the game state manager, switching between system functions. • This class extends and builds upon the GameFrameWork class; this class adds state management functionality. • This class uses the com.efg.games.superclick package, like the rest of your custom classes. • Package path - /source/projects/superclick/ flexSDK/src/com/efg/games/superclick/

  32. Main.as • Imports several framework classes: • FrameWorkStates, GameFrameWork, BasicScreen, ScoreBoard, SideBySideScoreElement • Init() will setup all important items on startup; this happens for all framework games • Main creates an instance of all classes used • At the end of init(), the game timer is run and the states are switched

  33. SuperClick.as • Game class. Handles content building, game logic, and updating game code • Several variables pertaining to game logic and level difficulty are defined in SuperClick.as which extends the game framework class • Manager of the game; separately communicates with Main’s ScoreBoard and BasicScreen via custom imported events • CustomEventLevelScreenUpdate.as, CustomEventScoreBoardUpdate.as

  34. SuperClick.as • Collisions, enemies, and scoring are passed to other classes through here; Main handles information accordingly • Instead of just 1 class handling everything, SuperClick only handles game logic. • Events created through the dispatchEvent() method control message passing to Main.as • Depending on the states passed, Main.as will decide what function needs to be run next in its management code

  35. Circle.as • Flash can draw a circle for us, but we need variables attached to it, ergo Circle class. • This class tracks what circles have been clicked and their scale. • The class Circle extends the Sprite class, so it can be rendered and have access to the event MouseEvent.CLICK.

  36. Circle.as • Circles are handled in an array in SuperClick.as • Each circle is cycled through so functions can check for score addition, fade out, and type • They are separated into GOOD_CIRCLE and BAD_CIRCLE, with the bad red circles clearly being ones to avoid

  37. ScoreTextField.as • Class that extends sprite and can dynamically create a TextField for use with BasicScreen.as • Data in this class represents score attained by given circle on click dependent on scale. • Field is displayed after clicking on the circle, telling the player how many points they got • Array of ScoreTextFields kept in SuperClick and displayed as long as their life allows them

  38. What Should You Do Now? • Compile and run through the game using FlashDevelop’s debug compile button! • Make note of the tracing in the debug, this displays what functions are happening at a given time! • View source code from the website and see how the Framework intertwines and assists actual game code!

More Related