2. “The perfect project plan is possible if one first documents a list of all the unknowns.” Bill Langley

3.  Plan of attack for your project Or (more specifically)  A detailed description of all the classes and implementations that will be used to create your game

4.  List out all of the known and unknowns  Collaborate as a team to solve the unknowns  Organize your code base before make it  Inform everyone on the team how their teammates code will work

5. CGame : public CBase Description: This module runs the main game loop allowing Object Manager to updating all objects in the game. It will contain a messaging system that will simplify switching between various game states and executing multiple commands during each computer cycle. This class is a singleton because we would never want multiple versions of the game running. When we initialize the window you must get the instance of the main game class and initialize it as well. The game requires the window for the application and the width and height of the window. The Main Game function will be called every time the window updates. This function will add messages to the messaging system based on what state the game is in. Stipulations: There can only ever be one instance of the game class. The Window file that creates the main game window is the only file that can own a game. You must use the messaging system as much as possible. All main game functionality of the game must be handled in functions called through the message system. The instance needs to be deleted when the window closes. Interface: This module will access most game modules. It will need to have control of the rendering system, 2d animation system, menu system, and input system.

6. NameTypeDescription m_hWndHWNDHandle to the main window that shows the program. pInstanceCGame *Pointer to the main instance of the game. m_MessagesCSGD_MessageSystemThis will hold and handle the messages that the class will handle in a priority. This will be built and managed every frame. boolm_bFullScreenThis will be true if we are rendering the game in fullscreen. It will be false to render windowed. m_pStateCBaseState*This is a pointer to the current state of the game. Every frame the main game loop will call this classes update and render. m_vObjectsCSGD_ObjectManagerThis data structure of pointers to update and drawn objects on the screen. This will hold the player character, any enemies on screen, and level data. m_pOFCSGD_ObjectFactory This data structure will be used to create objects though out the game. All object types will have to register with the object factory during initialisation m_pSoundCSoundManager*Pointer to the Sound Manager class that will handle sound effects in the game m_pInputCDXInput*Pointer to the Input Manager for the game Members …

7. ReturnNameType/ParametersDescription static Cgame*GetInstancevoidGet the instance of the Game Class. This should only be called in the file that contains the creation of the window. voidDeleteInstancevoidDeletes the instance. Should be called at the closing of the primary windown voidGAME_INITHWND hwnd - handle to the main rendering window. Bool Fullscreen - whether or not to initially be in fullscreen mode. Int height - height of the window. Int width - the width of the window. This function initializes the game with information pertinent to help initialize other key modules. This function handles most initialization in the game. voidGAME_MAINvoidThis function handles the various states of the game. Based on what state the game is in, different functions will be called here. voidGAME_SHUTDOWNvoidThis function cleans all the memory that was used in the Game class. It should be called before the main window closes. Methods …

8.  We need to see a UML document for your project  (class interactions, members, methods)  Don’t bother with assessors or mutators.  Do this first. Then export it to a doc file and modify the doc. (delete all the stuff you don’t need like Static, Leaf, Ordered, Unique, Query…, then add the stuff you do, like descriptions)  We need to see this for every game component  Not for wrapper that we have given to you (SGD wrappers)  You may not use the systems built in previous classes (ObjectMannager, Dispatcher…), you should be making new ones that fit YOUR game.

9.  Format the document  If using one note you should have a page for each class  Spell check and grammar check the document.  Add page numbers  Add a table of contents  Order it appropriately  Keep associated classes near each other  Never say you are using something until after it is defined  If something contains a CTile* on page 2 CTile shouldn’t be defined on page 39

10.  This is a waste of time doing this if you don’t do it as a team

11. First draft (first draft != half done)

12.  This is a lot of work  This will take a long time  This will end up being 50 pages or more  This is normal  Every class before you in recent memory has done this

13.  You will be wrong  That is a major reason to do this. If you are wrong now, we can correct it while there is still time  This will be immensely helpful

14.  Particles, tiles, animations all are going to be semi complex classes with managers  Particle manager manages emitters. Emitters manage the flyweight and particles. The flyweight and particles hold information.  Tile manager manages layers. Layers manage tiles. Tiles hold information.  Animation manager manages animations. Animations manage frames. Frames hold information. (think SGD texture manager)  If you think you are done read over your feature list and make sure everything on there has been covered.