Production Plan - Guille1406/The-Legend-of-Zelda-Hyrule-Conquest GitHub Wiki

General Calendar of Work

Deadlines Calendar

March 10th: Concept Discovery
April 5th: (Vertical Slice)
May 15th: (Alpha)
May 29th: (Gold)

Internal Calendar

March 8th: v0.1.0.0
March 17th: v0.2.0.0
March 31th: v0.3.0.0 (Vertical Slice)
April 8th: v0.4.0.0
April 18th: v0.5.0.0
April 28th: v0.6.0.0
May 8th: v0.7.0.0 (Alpha)
May 16th: v0.8.0.0
May 21th: v0.9.0.0
May 24th: v1.0.0.0 (Gold)

##Risk and Contingency List

###Risk Plan

Risk	Probability	Impact
Not enough time to finish the game	Low	High
UI not accurately responsive	Low	High
Link cant throw Zelda	Low	High
A member of the team quit	Low	High
Enemies AI doesn't work properly	Medium	Medium
Multiplayer camera doesnt work properly	Medium	Medium
Relese "X" time has arrived and is not ready	Medium	Medium
Problems with audio channels	Medium	Medium
Dash doesnt work	Low	Medium
Bugs not finded or fixed	Low	Medium
Gamepad does not work properly	Low	Medium
The programmers do not understand each other and the code is poorly optimized	Low	Medium
Not enough time to make the single player	High	Low
We cant implement the minimap	Medium	Low
The brightness does not adjust	Medium	Low
Memory Leaks	Low	Low

##Contingency Plan

In our company we have a Risk list about things that can go wrong, like the lack of time or lack of staff. To deal with these issues we have four options.

Avoidance: The best thing you can do with a risk is avoid it. If you can prevent it from happening, it definitely won’t hurt your project. The easiest way to avoid this risk is to walk away from the cliff, but that may not be an option on this project.
Reduction: If you can’t avoid the risk, you can mitigate it. This means taking some sort of action that will cause it to do as little damage to your project as possible.
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.
Retention: When you can’t avoid, reduct, or Deferral a risk, then you have to accept it. But even when you accept a risk, at least you’ve looked at the alternatives and you know what will happen if it occurs. If you can’t avoid the risk, and there’s nothing you can do to reduce its impact, then accepting it is your only choice.

Risk	Type of Contingency	Explanation
Not enough time to finish the game	risk Avoidance and risk Reduction	In case of running out of time, we will use the contingency plan and we will cut NPC and secondary mechanics, audios or animations.
UI not accurately responsive	risk Avoidance and risk Reduction	If there is some element of the UI that does not respond as it should, it would be best to try to replace it or as a last resort to eliminate it.
Link cant throw Zelda	risk Avoidance and risk Reduction	Being one of the most important mechanics, we would focus the work on moving the mechanics forward even if we stop implementing other less important ones.
A member of the team quit	risk Retention and risk Avoidance	It depends on the member of the group that fails we will have to eliminate tasks of the scope that was in charge
Enemies AI doesn't work properly	risk Deferral and risk Reduction	We will try to focus the work on optimizing the pathfinding and in case of not achieving it, we would try to advance the project to the point that this problem can be solved more easily
Multiplayer camera doesnt work properly	risk Reduction	As we have a member who has already created a camera, in the case of not being able to create the planned we will use that of the member
Relese "X" time has arrived and is not ready	risk Deferral	If the day of a Release arrives and we do not have the minimum points to perform it, we will expedite the delivery until the next delivery of Release
Problems with audio channels	risk Avoidance and risk Retention	If we can not implement all the audios, we will take advantage of the audios that are well implemented for use in several actions
Dash doesnt work	risk Avoidance and risk Retention	Although it is an important mechanic for the fight with the final boss, we would make a redesign of the battle and eliminate this machine of the game
Bugs not finded or fixed	risk Reduction	We have a team member who is in charge of exhaustive search of bugs
Gamepad does not work properly	risk Avoidance	As one of the most important aspects of the game, if this happens we will defer points that take a lot of time to resolve this critical point
The programmers do not understand each other and the code is poorly optimized	risk Reduction	To avoid this risk we have created the TDD in which we determined some rules to program
Not enough time to make the single player	risk Avoidance	As it is a secondary aspect, if we dont have enought time we will retire the single player mode
We cant implement the minimap	risk Avoidance and risk Deferral	As it is a secondary aspect, if we do not have time we will not implement the minimap
The brightness does not adjust	risk Retention and risk Deferral	If it is not possible to create the scroll that adjusts the brightness, a default one will be set
Memory Leaks	risk Reduction	The QA department will test it from time to time and keep the code with the least amount of memory leaks

##Development Method

The methodoly that we will use is the Scrum methodology. To organize the ideas and task the teams have 2 meetings a week at least, this meetings are face-to-face, the other days we will be connected by skype, where we can support each others.

The meetings are scheduled for Tuesdays at 10:00am and Thrusday at 12:00pm. on this meetings the teams will talk about the progress on the weak, the issues founded and the new tasks util the next weekends.

We are moving to favro, but for now we are working with Trello, here is our Work Schedule, where the team is updating the tasks to do.

##Development Schedule

We decided to make a calendar in function of the availability of the members. here is our Calendar. Since we are working with the Scrum method, our work is focused on sprints that we call Releases, which have dates previously assigned with a group discussion.

At the end we will have 10 Releases, below this the description of each one.

###Releases v0.1.0.0

A map can be created and painted with its layers.
The collisions system is working.
The player can move across the world.
The single player and multiplayer mode can be selected.
the camera moves with the characters.
the camera split on multiplayer mode.

v0.2.0.0

The game can be played with a console gamepad.
A basic UI is perfectly functional and handles simple orders.
The game contains all the sprites and animations of the principal characters

v0.3.0.0 (Vertical Slice)

The enemy AI follows a simple logic and is capable of attacking the player.
Link can lift and throw Zelda or any object.
All the basic attacks of both characters are fully implemented.

v0.4.0.0

All the enemies sprites and animations are implemeted.
The first dungeon and tutorial is already playable.
the Module script is implemented.
An NPC is printed on the game.

v0.5.0.0

All the enemies are implemented and included on the game.
All the items are implemented and included on the game.

v0.6.0.0

Menus is added. You can change the current item and you can open the mini-map.
Map is already designed and printed in the game.
The mini map is working and printed. it can show the position of the principal characters.
the boss is able to fight with win/lose conditon.

v0.7.0.0 (Alpha)

All the map and puzzles are playable

v0.8.0.0

All the NPC are printed and you can interact with them.
the player can buy on the store and can collect Ruppies on the map.
The game has all the fx sounds and musics.

v0.9.0.0

Bug hunting and Polish.
All the animations of the game are perfectly working.

v1.0.0.0 (Gold)

Final Polish.
Gold of the game released.

##Resources List

this is the list of programs that our group will use to develope "The Legend of Zelda: Hyrule Conquest"

###Management

Favro: Tool to organize the team and tasks.
Google Sheets

###Art

Photoshop: Here is where we manipulate the sprites.
Tiled: All the tiles and the layers.
Texture Packer: A tool to organize the spritesheet.

###Audio

+Gxscc: A helpfull tool to convert a .mid into a 8bit song.

###QA

Github Issues: Here is where the QA places the bugs detected.

###Programmation

+Github : To work like a team with the advance updated. +Visual Studio 2015: Here is where we program.
+Violet UML Editor : Simple but it allow us to make an UML very helpfull.

##Members of the team

Leader: Nicolas Babot.
Management: Guillermo Pinto.
Art+Audio: Daniel Olondriz.
Design: Javier Ortiz.
Code: Miquel Izquierdo.
UI: Xavier Olivenza.
QA: Adrian Higuero.

Return to Home