09. Production Plan
- General Production Plan tool workflow overview
- General Calendar
- Risks and Contingency list
- Meetings Postmortems
- Average time deviation
All work organization and distribution of the tasks for the members of Pink King Games are based and focused to work with two main tools.
- ClickUp: a complete and "every day" updated productivity software, based on agile and scrumb methodologies wich they offer to us a complete very valuable software what assures a better way organization model. With the ClickUp application for mobile devices we are up-to-date to any circunstance and give us a quickly response to any workflow situation on every place. All calendar related organization tasks what we are explaining and detailing here are extracted and organized using this productivity software.
- Excel Pages: used to at the end of the every working day, each member write there his related working task and the estimated and real time taken to complete it. We assure at the end the correct time distribution and promoves equitative workload.
- Discord: One single word, communication. The key of success pass throught a good communication too. We use a private Discord server wich we organize every time we are working on any related tasks to this project. Used to do every couple of days at least, a "quick" voice meeting to expose any change/question and check how the tasks and sprints are flowing.
From very early we started to plan a suitable good distribution on a medium deepth definition of all the global tasks/functionalities that we are planned and designed to include on this project. We used the Calendar function to organize the tasks directly on our choosed productivity software exposed above these lines, Clickup. For this we splitted up our constrained deadlines of our project2 assignment and made it our milestones (the flag colored icons on top of some days on the screenshoots below). Each milestone are splitted on several sprints, dependently of the amount of workload for the respectives tasks accordly one or two for a week.
The animated image shown below comes from our first draft planification calendar. This is expected to evolve along all developing process.
Parallel with our calendar planification we have planned too, to do at least one sprint for week to achieve a suitables and realistic objectives, sometimes when the amount of tasks permits us we can do a couple (concept discovery for example). The postmortem of every sprint and some relevant information is coming to write here on its respective section Sprints Postmortems when every sprint ends.
-
-
Since all of us are living on different places, we put in common a two very important ways to communicate and track ours tasks while working (apart of this we always use clickup to organize every aspect).
- Always online: On splitted-live-work group is really important the online communication, this is key to achieve our goals. With that in mind we are always connected while working, and very often for some aclaration or tasks related/opinion we make voicechats, a continue process of feedback and resolution are achieved with this with high rate to success.
- Track our daily tasks: with a collaborative excel page for each member, every working day put constancy of his work on it, tracks the task, estimated and real times and deviations with this.
-
Face to face group meetings: every wednesday from 12:00PM to - when its done -. This is the core meeting on where we put on the table all the needed sections, all important changes or anticipate problem solving occurs here.
-
One or two weekly "big" dynamic voicechat meetings to cover all our needs.
-
When we arrive at the developing stage, we plan to do at least one internal build every two weeks or when we consider the best moment along their planification. Each milestone has its external and big final build ready when the deadline arrives, at least two days before on idealistic world(fully tested).
-
A continuous QA member that assure us the best possible quality at every stage and a complete tracking of problems/bugs related to usability and player experience. Includes:
- Continuous testing while we update the code, bugs are expected to solve for order of priority or relevance while we working, if the code simply doesn't work, is NOT accepted on the master branch.
- When deadline are nearly, this process is much harder, and the addition of important new code is closed at least two days before the deadline arrives to prevent code related problems, this days the main function is test and harder QA.
- Each milestone are expected to test on target machines with time of fixing if needed.
-
As we commented on top here, we are constrained to four fixed calendar date assignements as we call internally our milestones. In order to accomplish successfully our milestones we divided these on little tasks and subtasks, and create a goal on our productivity software we use, what comes at end with our every version milestone objectives.
For this milestone we have to achieve all needed documentation as wiki and prepare the first important investor meeting, wich include a nice powerpoint format presentation with the best visuals to gain the needed funds to go on a proper way with this project. Includes:
- Welcome page
- General analysis of the base/original game
- GDD
- UI Document
- Audio bible
- Art bible
- TDD (Tech Design Document)
- QA Plan
- Production Plan (this section!)
- And compile the most relevant visuals in a presentation to deliver a pitch with it
In this version is expected to implement the basic core mechanics like the initial stage of combat and swapping between characters, player basic control and animations, at least one primitive enemy/ies,etc. Essencially all the core mechanics what defines the importat concepts of our game idea. An internal early draft is shown below:
The content of this version is expected to be so very close to gold version. On this stage essencially we have developed all the art/fx, level design, user interface and player and enemies relatives solved to a semi final product stage.
Between the end of the previous alpha milestone and this, the content may vary depending on design and development decisions along the developing process. But is expected to include at the end the possible remaining content (cut-scenes if any, improved animations/art/SFX if needed, mainly visual elements and non-related gameplay mechanics, etc), and all the content are polished to offer a better final user experience quality.
To prevent some problems from the future, we made a Risk and Contingency List. In every possible problem that we could think about we came up with a possible solution, and we also added a level of impact (will represent how much trouble the problem will cause) and a level of probability (will represent how likely is this problem to happen).
These last two attributes will be represented in these different levels:
- Very Low
- Low
- Medium
- High
- Very High
- Extremely High
| Risk | Impact | Probability | Solution |
|---|---|---|---|
| A member's PC stops working | High | Low | This member will try to find a backup PC. If not found, he will have to make his tasks in the CITM's computers |
| A member of the team gets ill | Medium | Medium | This member's task will be reassigned to the rest of the team. In case of going behind schedule, this member will have to work (if possible) in his bad state |
| A member of the team drops out | Extremely High | Very Low | One of the worst scenarios. The rest of the team will have to take care of all the work of this member. His tasks will be distributed to the rest of the members. |
| A member of the team does not deliver his tasks on time | High | Medium | The lead will have a chat with this member, to find out what causes those delays, and try to find a solution to it. |
| A member of the team cannot attend a meeting | Medium | High | The lead will summarize the most important points discussed in the meeting with him personally, or he will publish the conclusions in the discord chat. |
| Two members of the team argue and they can no longer work properly together | Very High | Low | The lead will find a solution, whether it is finding a way to solve the dispute, or making one's work not relate with the other one's work. |
| The new characters animations are not aligned | High | Medium | Our artist will change the sprite-sheet so that it works properly. |
| The pathfinding code takes too much time to process | Very High | High | Our expert in A* optimizations will look for optimizations in the algorithm. |
| The levels are not clear when displayed in isometric drawing | Very high | Medium | The designer will make adjustments to the level so the isometric view doesn't cause any problems. |
| The UI displays the banners of the items on the floor in a wrong way | High | High | The UI responsible will make sure that the relative positions are calculated correctly and will find a way to solve it. |
| The game is really easy/hard to finish | Medium | High | The designer will make adjustments to both enemy and player stats and enemy spawns so it offers more balance. |
| The buff manager doesn't take into account some stats | Medium | High | Our code and QA responsibles will find what are those stats and why are not calculated by the buff manager. |
| Objects and abilities are not saved properly when the player saves the game | Very High | Medium | Our code responsible will find out whether the data is not written or is not well read when loading and find a solution. |
| One of our members that will expose during the delivery can not assist the presentation day | Very High | Low | The lead will take this member's part of the presentation, and will expose the best as he can instead. |
| The release its done wrong | Very High | Very Low | We will make the releases at least two days before the delivery date, so we have time to correct any possible mistake. |
We made a Gant Chart for each delivery, to have a general idea of the estimated time that each task will take from a different perspective. To mention, that this is an estimated approximation, and will be updated accordingly to our progress.
Click on the Image or here to see enlarge
Click on the Image or here to enlarge
Click on the Image or here to enlarge
Here we have a list of the post-sprint meetings we had and their respectives postmortems. In these, we have a list of things we liked about that sprint and we want to keep, and things we think that can improve. Some of these points might be contradictory, but it's because these are individual thoughts of the members of the team. Each one of them can have a different opinion on the sprint we are discussing, and all of them must be listened to.
This segment is opened to change over time, as we will update it as time progresses and meetings take place.
Positive:
- Comunication between the team.
- Members give accurate feedback.
- Good Management.
- Start with anticipation.
Can Improve:
- The team lead should be more strict.
- The milestones are too optimistic.
- All members of the team should show a minimum of interest and commitment.
Positive:
- The lead has improved in his role.
- Design and art segments progress correctly. (Important aspects in this part of the development)
- First sprint with a negative feeling overall, and can be used as a reference and an inflexion point.
Can Improve:
- Prioritize debating subjects in the meetings.
- Milestones not delivered in time in this sprint. Some members are bit too much "chill" in this regard.
- Game mechanics debate stretch too long. Way more than expected. And not all the subjects were cleared.
- Agilize distribution meetings.
- More members should contribute when debating a subject online (discord).
We are updating this document in order to keep track of the time deviation of each member. This section will be updated when the next milestone ends.
