Unforeseen
|
Details
Role: Producer Members: 5 Duration: 2 months School year: 1 Engine: Unity Platform: PC Unforeseen is a side-scrolling physics based puzzle game, where you guide a blind girl through a forest filled with obstacles.
A series of natural disasters has wiped out humanity. Deep in the forest the last human (a little girl) is hidden in a time sphere, only to let her out when the time is right to save the human race. Centuries later, when the entire planet has been reclaimed by nature, the spirits awaken the girl with as their one goal, clearing her path to the tree of life to add her DNA to it, and give humanity its second chance. |
|
Responsibilities
- Presenting the project to teachers and other teams during various phases of the project
- Setting up and maintaining day-to-day scrum tasks and progress.
- Maintaining a pleasant and professional working environment and atmosphere among the team.
- Being the vision holder for the project and keeping the development and teaching team up to date on changes.
- Scheduling and facilitating meetings within the team.
- Setting up the risk list and updating it throughout the bock, ensuring contingency plans are executed if necessary.
Lessons learned
Improved presentations
This was the first project where regularly presenting was required. This helped me improve my presenting skills in multiple aspects. First of all it helped me improve the content of my presentations. I used to write a lot of text on my slides, where I now put a visual piece, and a few keywords which help me remember the most important points I have to touch upon. It also helped me asses what content is worth keeping and what content makes the presentation unnecessarily longer, based on the audience you're speaking to. Furthermore it also helped me improve how I deliver my presentations in terms of body language, tone, speed, et cetera.
Defining scope
The team was tasked with making a physics based puzzle game, where we had to write our own physics. Since we only had a very short time to make and implement this we had to make sure we had a very clear understanding of what the game would entail, to define what physics we would need, and when we could start implementing the dependent gameplay features. We therefore worked on a planning that set clear restrictions on what was needed, and where cross-disciplinary dependencies lie.
Build stability
Having to deliver a build during various milestones throughout the project instead of only at the end was a new challenge we got during this project. This didn't go very smooth in the beginning, since we just wanted to build on the day itself and deliver that. Of course this went wrong, the build was broken and didn't show all the content we wanted to present. To improve on this for the builds that were still to come we created milestone plans for each build, to make sure it had the right content. We also made sure to build the day before, so any issues could still be fixed if they were to arise. One final thing we also worked on was more regular QA checks, however we could have done much more regarding that topic, which is knowledge I will take to, and implement in future projects.
Improved presentations
This was the first project where regularly presenting was required. This helped me improve my presenting skills in multiple aspects. First of all it helped me improve the content of my presentations. I used to write a lot of text on my slides, where I now put a visual piece, and a few keywords which help me remember the most important points I have to touch upon. It also helped me asses what content is worth keeping and what content makes the presentation unnecessarily longer, based on the audience you're speaking to. Furthermore it also helped me improve how I deliver my presentations in terms of body language, tone, speed, et cetera.
Defining scope
The team was tasked with making a physics based puzzle game, where we had to write our own physics. Since we only had a very short time to make and implement this we had to make sure we had a very clear understanding of what the game would entail, to define what physics we would need, and when we could start implementing the dependent gameplay features. We therefore worked on a planning that set clear restrictions on what was needed, and where cross-disciplinary dependencies lie.
Build stability
Having to deliver a build during various milestones throughout the project instead of only at the end was a new challenge we got during this project. This didn't go very smooth in the beginning, since we just wanted to build on the day itself and deliver that. Of course this went wrong, the build was broken and didn't show all the content we wanted to present. To improve on this for the builds that were still to come we created milestone plans for each build, to make sure it had the right content. We also made sure to build the day before, so any issues could still be fixed if they were to arise. One final thing we also worked on was more regular QA checks, however we could have done much more regarding that topic, which is knowledge I will take to, and implement in future projects.