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

Bill Langley

Plan of attack for your projectOr (more specifically)

A detailed description of all the classes and implementations that will be used to create your game

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

CGame : public CBaseDescription:

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.

Name Type Description

m_hWnd HWND Handle to the main window that shows the program.

pInstance CGame * Pointer to the main instance of the game.

m_Messages CSGD_MessageSystem This will hold and handle the messages that the class will handle in a priority. This

will be built and managed every frame.bool m_bFullScreen This will be true if we are rendering the

game in fullscreen. It will be false to render windowed.

m_pState CBaseState* 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_vObjects CSGD_ObjectManager This 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_pOF CSGD_ObjectFactory<string, CBase> 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 initialisationm_pSound CSoundManager* Pointer to the Sound Manager class that

will handle sound effects in the game

m_pInput CDXInput* Pointer to the Input Manager for the game

Members

…

Return Name Type/Parameters Description

static Cgame* GetInstance void Get the instance of the Game Class. This should only be

called in the file that contains the creation of the window.

void DeleteInstance void Deletes the instance. Should be called at the closing of the

primary windownvoid GAME_INIT HWND 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.

void GAME_MAIN void This function handles the various states of the game.

Based on what state the game is in, different functions will be

called here. void GAME_SHUTDOWN void This function cleans all the

memory that was used in the Game class. It should be called before the main window closes.

Methods

…

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.

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

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

First draft (first draft != half done)

This is a lot of workThis will take a long timeThis will end up being 50 pages or

moreThis is normal

Every class before you in recent memory has done this

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

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.