Before listing all the risks our project might face, we are going to give a brief explanation in how they're going to be organised, taking in account their probability to occur and their impact to the game. First, we will see the meaning of each level acording to the cost of the project,the time it will take to develop and the quality of the final product.

Impact	Cost	Time	Quality
Very Low	Can be met with current funding	Slight slippage of internal targets	Slight reduction in quality with no overall impact on usability/standards
Low	Requires some additional funding	Slight slippage against key milestones or published targets	Failure to include fancy elements promised to stakeholders
Medium	Requires additional funding	Delay affects key stake-holders	Significant elements of scope or functionality will be unavailable
High	Requires significant additional funding	Failure to meet key deadlines	Failure to meet the needs of a large proportion of stakeholders
Very High	Requires substantial additional funding	Delay jeopardises viability of project	Project outcomes effectively unusable

Now, we will give each level of impact/probability a numerical number.

	Scale	Probability	Impact
1	Very Low	Unlikely to occur	Negligible Impact
2	Low	May occur occasionally	Minor impact on time, cost or quality
3	Medium	Is as likely as not to occur	Notable impact on time, cost or quality
4	High	Is likely to occur	Substantial impact on time, cost or quality
5	Very High	Is almost certain to occur	Threatens the success of the project

The attribution of numerical scales to risks at this point can be helpful in order to prioritise more precisely their relative seriousness. One way of achieving this is by multiplying a risks probability score by its impact score. However, the drawback to this approach is that it does not take into account the relative potential seriousness of probability and impact. A risk with a high probability of occurring but that has a low impact on the project could obtain the same severity score as a risk that is unlikely to occur but if it did could ultimately threaten the success of the project.

One way of removing the 'averaging out' effect is to increase the relative weight afforded to high impact risks. The numeric value assigned to a risk doubles as you move higher up the impact scale. Let's check this on a table:

					Impact
			Very Low	Low	Medium	High	Very High
			1	2	3	4	5
	Very Low	1	1	2	4	8	16
	Low	2	2	4	8	16	32
Probability	Medium	3	3	6	12	24	48
	High	4	4	8	16	32	64
	Very High	5	5	10	20	40	80

So, from here on, we will evaluate each of the risks found and organise them according to the numeric value they have on this table. The most critical ones will have priority over the minor ones.

Risk	Probability	Impact	Numerical Value
Enemies AI doesn't work properly	High	High	32
Being unable to properly create an optimal pathfinding	Low	Very High	32
Loss of key data	Low	Very High	32
Memory Leaks	Medium	High	24
Fog of war doesn't work properly	Medium	High	24
UI not accurately responsive	Medium	High	24
Implementing Units more troublesome than expected	Medium	Medium	12
Balancing the game gets harder than expected	High	Low	8
Map Logic messed up	Low	Medium	8
Malfunctioning of equipment (a.k.a. my PC is broken)	Low	Medium	8
Illnes of a member team	Very High	Very Low	5

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

Contingency Plan

So, how are we going to deal with all of this risks to minimize or even get rid of them? The answer is planning risks responses for the most important ones if not all of them.

First, i am going to describe the basic nomenclature and a brief description of the different ways we are going to face the risks.

Risk avoidance: also known as risk removal or risk prevention, risk avoidance involves altering the original plans for the project so that particularly risky elements are removed. Less drastically it could involve altering the activity in such a way that the risk is removed.
Risk reduction: risk reduction or risk mitigation involves the employment of methods that reduce the probability of a risk occurring.
Risk deferral: the impact a risk can have on a project is not constant throughout the life of a project. Risk deferral entails deferring aspects of the project to a date when a risk is less likely to happen.
Risk retention: inevitably certain risks have to be accepted as a necessary part of the project.

Having defined these four general categories, let's proceed to organise our risks and detail a contingency plan for each one of them.

Risk	Type of Coningency	Explanation
Enemies AI doesn't work properly	Risk Retention and Reduction	If, by some means, our AI ends working different from what we intended, the best idea would be to hide those differences from the player so they are unnoticed and so the damage is rendered to the minimum.
Being unable to properly create an optimal pathfinding	Risk Reduction and Deferral	By avording this risk since the beginning of the project we reduce the probability of being unable to properly create an optimized pathfinding.
Loss of key data	Risk Reduction and Deferral.	By saving copies of the original since the beginning of the project we can prevent major disaters.
Memory Leaks	Risk Reduction	By regularly using the tool Doctor Memory we can reduce this risk to the minimum.
Fog of war doesn't work properly	Risk Retention and Reduction	Again, if the fog of war ends up working different to what we expected, the best solution would be to hide those differences from the player so they are unnoticed and so the damage is rendered to the minimum.
UI not accurately responsive	Risk reduction and Avoidance	If there are some elements that are not working properly getting rid of them might be the best idea for the viability of the project.
Implementing Units more troublesome than expected	Risk Avoidance	If there are some units that are causing too much trouble to implement or to make them work properly not implementing them might be the best idea.
Balancing the game gets harder than expected	Risk Retention	If we are unable to properly balance the game to provide the best experience possible, the best we could do is present the most balanced version we have made.
Map Logic messed up	Risk Deferral and Reduction	If we start working on the map logic since the beginning the chances of it being messed up will be way lower.
Malfunctioning of equipment (a.k.a. my PC is broken)	Risk Reduction and Retention	If some of us is unable to work with his own PC has plenty of options to still work on the project. He can do the work at CITM or even work together with another member.
Illnes of a member team	Risk Reduction and Retention	There's nothing we can do about this, but we are eight, so if someone is unable to work beacuse of an illnes, the others can cover him.

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

User Stories and Definition of Done

User Stories

As a player I can move the camera through the map so i can spot enemies and allies.
As a player I can move the camera using the minimap and spot enemies and allies on it.
As a player I can move units using the mouse and order them to attack or build.
As a player I can build my constructions to defend myself and buff my units.
As a player I can win or lose the game.

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

Definition of Done

######0.1.0.0

The map is painted with its specific layers.
The camera moves when you approach the cursor to the borders.
The camera slows at the beginning and the end of its movement.

######0.2.0.0

The entity manager is perfectly implemented and it can handle all future entities that will be implemented.
A basic UI is perfectly functional and handles simple orders.
A unit from the Terran and one from the Zergs is correctly implemented and move correctlu through the map.
The logic of the map is correctly implemented.

######0.3.0.0

Units can be moved in groups without any problem.
Pathfinding can handle orders from groups and is correctly implemented to handle requests to move from one corner of the map to the other.
An initial base is correctly implemented and the building is perfectly functional.

######0.4.0.0

An enemy AI is implemented and can handle simple orders.
The enemy AI follows a simple logic and is capable of attacking the player.
The player can create units at will but with a cost.

######0.5.0.0

Wave system is implemented. This means an algorythm of generation has been established and is working perfectly.
A punctuation has been implemented so it can track the number of unities destroyed by the player.
A win/lose cycle has been established. It triggers upon allied base being destroyed or the player clearing a certain number of waves.

######0.6.0.0

The basic UI is improved to match the real UI from Starcraft.
The mini map is implemented. It shows allied and enemy units. You can move the camera through the minimap.

######0.7.0.0

Fog of war is implemented in the game. You can see further ahead of your range of vision. The minimap is all hidden except for the parts you already have seen.
The player can build buildingds at will. The buildings can be constructed just in the parts designed to be build on.

######0.8.0.0

The system of particles is clearly implemented. Each one of them triggers perfectly.
All units are implemented in the game with all of their specific mechanics.
AI is improved to match that of the actual Starcraft.

######0.9.0.0

The system of capture the flag that involves the ghost and the bomb is implemented.
The bomb appears at a random spot between three posible spwan points.
The player can retrive the bomb.

######1.0.0.0

The player can activate the bomb to trigger the final stage of the game.
Final waves are implemented and properly balanced.
The general gameplay is correctly balanced.

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

Record of the meetings

On this section, a log of the different meetings during all the development of the game will be recorded.

Meeting nº 1 (01/03/2016)

Members present: 8 out of 8

Purposes

On that first meeting, we have talked about the survival mode that are going to implement. The basic idea was to explore new features that could be included on the game, at the same time that each member of the team has assessed the different proposals.

On the other hand, in order to fill in all the documentation that must be delivered on Friday 11th, the different tasks have been distributed among the members of the team.

Outcomes

About the survival mode, some features has been proposed:

A heroe: A unit with enhanced skills.
Atomic bombs: At some points, between Zerg waves, an atomic bomb will appear on the map. With a explorer, the player could get it and use it against the Zergs.
Explorer: As it is present on the original, the explorer will be the Ghost Terran unit.
Resources: Each killed Zerg will give to player some resources (minerals and gas).
SCV: The player will start the game with only one. After some Zerg waves, the player will be rewarded with additional units.
Protect the SCV: We could hide all SCV on the base under heavy attack. Maybe, they could shoot something from within.
Enhancer buildings: Buildings that will boost any skill of any Terran unit. New designs could be a challenge.
Story: Some big anti-Zerg missile is coming. But, be patient. It won't last.
Terran units: SCV, marine, medic, firebat, tank, ghost, goliath and optional, walkyrie and wraith.
Zerg units: Zerg, Hydra, Lurker, Mutalisk and Ultralisk.

The documentation tasks have been distributed as:

@crandino: Welcome page, general anaylisis, assitance to @N4bi on its QA Plan, GDD and record of the meetings.
@weprikjm and @AleixBV: Tech Document
@AGM16 and @RogerOlasz: Audio and art bibles.
@rohomedesriu: UI document
@mickifricki: Production plan document and control and supervise the table with estimated and real hours of work.
@N4bi: QA plan document.

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

Meeting nº 2 (08/03/2016)

Members present: 8 out of 8

Purposes

The aim of this second meeting was to check all the progress made on the documents so far and distribute the remaining points of the GDD between the team members.

Additionally, some changes related to the design have been introduced.

Outcomes

Documents are being developed at a reasonable path according to the schedule.

Design changes:

Gathering of materials will not be present on our game. The player will get some resources with each wave cleared.
During the time between waves, called "Preparation Time", building and creating units takes no time at all. During waves, though, it does.

Distribution of GDD remaining points:

Narrative structure: @mickifricki
Description of all Units present in our mod: @AGM16
Descrition of all buildings present in our mod:
Controls:
Game Objective, how do waves work? All bomb-related gameplay.

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

Meeting nº 3 (15/03/2016)

Members present: 7 out of 8

Purposes The aim of this third meeting was to arrange and distribute the tasks that had to be made for the 0.1 release.

Outcomes

The work was distributed as follows:

Split the map into tinny squares so it can be implemented into the game: @RogerOlasz
Add module map and load it: @N4bi
Movement of the camera, including transition: @mickifricki
Pass all the code remaining to STL libraries: @crandino, @weprikjm, @AleixBV and @rohomedesriu

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

Log of average devitation

The project is currently in progress.

Return to [index] (https://github.com/AleixBV/StarCraft/wiki/Production-Plan#index)

[HOME] (https://github.com/AleixBV/StarCraft/wiki)