Defining Organization

Balanced Work Load

In order to move forward with Option #1 (keeping the work load balanced), I really had to dig deep and find a way for us to have a clear way of defining where we are in the project. In order to do this, I'm going to exclusively use Github tickets. But, I'm going to also add some definitions to what we have already to further distinguish where we are.

Screens, States, and Helpers

In order for us to handle this as a team, we need to be able to call out different sections of the program by name. This will make it easier to pinpoint what we are talking about, and give us a firm direction of how much we've done to fulfill a certain milestone. Instead of milestones being determined by vague definitions, these areas will be a lot more concise. I'll start with the minor denominations first and build up to the major ones.

State Helper

This is the lowest denomination. State helpers are the "tools" of the engine. They help parts of the engine do their job. Examples of these types of helpers range from the important ones:

• Graphics Engine
• Game Loop Timer
• Logic Engine

To the optional ones:

• Music Engine
• Game pad controller
• Server Engine

These tools are modular, and can help multiple screens perform their jobs at once. Some tools are necessary throughout the entire game while others are optional. Tools are always interacted with "indirectly" through a state. Also, a lot of state helpers are global, which allows them to have access to many parts of the program.

State (Process)

This is the most important part of the engine. Each state is a process that the game has to go through. Each process is modular and is denoted by its overall game function. Here are a few examples of state processes:

• Loading state - The process of loading data into the system
• Menu state - The process of selecting an action
• In-game Move - The process of moving a unit
• In-game Attack - The process of attacking a unit

In order to make sure that a state process is properly defined, each state will have its own ticket. (This will also be used for making state helper tickets). The ticket will have the following items:

• Explanation - A short and sweet summary of what a state does
• Functionality - What each button (Up, Down, Left, Right, Select, Cancel) does in this state.
• Functionality Purpose (Optional) - Further explanation of what a certain item in functionality does for the engine.
• Pros and Cons (Optional) - The advantages and disadvantages of this particular state
• State Helpers - The helpers needed to make this state run

A state process is done when the all functionality of the state is ticked off. When each piece of functionality of a state and its idle action is complete, the state is considered complete. States can be used for more than one purpose in many cases, so modular design is highly highly recommended.

Screen

A screen is a group of state processes. They are used to define different sections of the game. Most of these sections will be denoted by the Main Menu as denoted below:

• Title Screen - The group of processes dedicated for getting users into a game
• In-Game Screen - A group of processes dedicated for a player to play a game
• Replay Screen - A group of processes dedicated for showing the player replays
• Server Screen - A group of processes dedicated for players to play a server game
• Campaign Screen - A group of process dedicated for players to play a campaign
• Editor Screen - A group of processes enabling map creation and saving

Screens will help us get a more broad stroke on how far we are in the project and can also tell us exactly what we need to bring the game to life.

Set up in Github

These three denominations will help better organize the program by giving us much more concise tickets which we can use to append to milestones. Tickets will consist of state helpers and screen states that need to be completed. The title for a screen state will look like this:

• Title Screen - Loading State

The title for a state helper will look like this

• State Helper - JSlix Graphic Engine

Each will include a list of functionality needed to complete a certain ticket, and each ticket will be appended to Milestones so we can get a clear view of when a section of a project is complete.

Conclusion

With this, the motion has been set forward. I am working on combining, condensing, and organizing what we have in our older programs into tickets so we can reproduce what we started. A good mix of screen states and state helpers should be more than enough to strictly define what is needed within the project.