CIS 487 - Game Design I Chapter 2 and 3

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!