Arboreal
Details
Role: Producer Members: 31 to 36 Duration: 1 year School year: 3 Engine: Unreal Engine Platform: PC Arboreal is an open world farming and adventure RPG where you have to save the world and its ancient giants from a spreading corruption.
An abandoned orchard located in a distant town is inherited by you. It’s in dire need of restoration and you take on the task, hoping that soon you’ll be able to live and profit off this land. The townspeople are welcoming and you soon feel like a part of the community, but the world outside the town hides more than meets the eye. Ancient colossi, rooted in their environment have been corrupted. This corruption is spreading across the land like wildfire, and only you can save your new home. |
|
Responsibilities
- Setting up the team structure and pipelines, and improving these throughout the year.
- Setting up and maintaining day-to-day scrum tasks and progress.
- Communicating with stakeholders about the state and expectations of the project.
- Presenting the project to clients, stakeholders and other interested parties during various phases of the project.
- Maintaining a pleasant and professional working environment and atmosphere among the team.
- Being the vision holder for the project and keeping the team and external parties up to date on changes regarding this.
- Managing and scheduling outsourced work from a concept team, Houdini team, and an audio designer.
- Scheduling and facilitating meetings within the team, with stakeholders, and between both parties.
- Setting up the risk list and updating it throughout the bock, ensuring contingency plans are executed if necessary.
- Preparing and executing a marketing plan for the release of the game.
Lessons learned
Full development cycle
This project was the first that ran through a full development cycle, starting with concepting based on a brief and ending with post production after releasing on steam.
This has taught me how all the stages influence each other, and showed how important it is to keep the entire team motivated throughout the stages to make sure productivity stays high and the team keeps delivering good quality work on time. This was also the first time having to manage a team of 35 developers, which meant setting up a clear team structure and maintaining clear communication and direction throughout the project.
Of course this brought up enough challenges and problems, which helped me further develop my risk management methodologies and problem solving skills. Agile project management made it possible to quickly work out our workflow and pipeline issues with the constant feedback of the team.
Marketing
To make sure the game would appeal to a specific audience, that audience first needed to be defined. Therefore target audience research and a competitor analysis were conducted, and out of that research came a persona (representation of our average customer) and the critical success factors our game would need to be of interest to that audience.
To follow up on that a marketing plan needed to be created so the game would be seen and anticipated by our newly found audience. This took the form of social media, press, streamers/YouTubers and expositions such as INDIGO.
The final stage of the marketing journey was community management after the game was released and During patch releases. This was continued until 2 months after the release of the last patch, after which all team members moved on to their graduation projects.
Managing outsourcing teams
During development we requested support from several outsourcing teams (links can be found on the team page of the games website):
QA and Jira
The projects before this were never made with the intention of getting shipped, and therefore QA never played a role as important as it did in this project. When starting off we were therefore not familiar with how to implement it into Jira, or keep track of it in general. The importance of it however already became clear during the first stages of development, and a team member was assigned to take this as a full time role. Together with a more experienced student from another team we integrated it into Jira and set up a way to manage it which suited the teams workflow. From thereon these processes were iterated upon throughout the year. The point that took most effort to get across was that QA is everyone's responsibility. The fact that one person is assigned to it doesn't mean you can ignore it, since in order to test aspects of the game, this person will need to know what the goal of the test is, how it should be conducted, and where they can find the correct build(s) for that specific test. To enforce this, a test plan with positive results became part of the acceptance criteria for each user story that required one, which eventually helped people see the importance.
Pipelines
Setting up the pipelines for this project was very interesting. Together with the leads it had to be ensured that each pipeline kept in mind how that specific discipline worked, and how one specific pipeline would interact when coming together with that of another discipline. Since the feature teams we used were cross-disciplinary the pipelines strongly influenced each-other, and were also influenced by those of the outsource groups which supported our team. To get all these work well together we went to numerous iterations before they started feeling like a harmonious process, which only happened in the later stages of the project. It was a very interesting process and gave more insight in the way disciplines differ, but also how they can work together more effectively by working out their strong and weak points, and letting them positively influence each-other.
Full development cycle
This project was the first that ran through a full development cycle, starting with concepting based on a brief and ending with post production after releasing on steam.
This has taught me how all the stages influence each other, and showed how important it is to keep the entire team motivated throughout the stages to make sure productivity stays high and the team keeps delivering good quality work on time. This was also the first time having to manage a team of 35 developers, which meant setting up a clear team structure and maintaining clear communication and direction throughout the project.
Of course this brought up enough challenges and problems, which helped me further develop my risk management methodologies and problem solving skills. Agile project management made it possible to quickly work out our workflow and pipeline issues with the constant feedback of the team.
Marketing
To make sure the game would appeal to a specific audience, that audience first needed to be defined. Therefore target audience research and a competitor analysis were conducted, and out of that research came a persona (representation of our average customer) and the critical success factors our game would need to be of interest to that audience.
To follow up on that a marketing plan needed to be created so the game would be seen and anticipated by our newly found audience. This took the form of social media, press, streamers/YouTubers and expositions such as INDIGO.
The final stage of the marketing journey was community management after the game was released and During patch releases. This was continued until 2 months after the release of the last patch, after which all team members moved on to their graduation projects.
Managing outsourcing teams
During development we requested support from several outsourcing teams (links can be found on the team page of the games website):
- Audio designer: Payed audio designer who provided all audio assets and sound tracks, implemented later by the team itself
- Concept art team: School team which provided concept art throughout the development process
- Houdini team: School team which provided landscaping and asset placement tools
QA and Jira
The projects before this were never made with the intention of getting shipped, and therefore QA never played a role as important as it did in this project. When starting off we were therefore not familiar with how to implement it into Jira, or keep track of it in general. The importance of it however already became clear during the first stages of development, and a team member was assigned to take this as a full time role. Together with a more experienced student from another team we integrated it into Jira and set up a way to manage it which suited the teams workflow. From thereon these processes were iterated upon throughout the year. The point that took most effort to get across was that QA is everyone's responsibility. The fact that one person is assigned to it doesn't mean you can ignore it, since in order to test aspects of the game, this person will need to know what the goal of the test is, how it should be conducted, and where they can find the correct build(s) for that specific test. To enforce this, a test plan with positive results became part of the acceptance criteria for each user story that required one, which eventually helped people see the importance.
Pipelines
Setting up the pipelines for this project was very interesting. Together with the leads it had to be ensured that each pipeline kept in mind how that specific discipline worked, and how one specific pipeline would interact when coming together with that of another discipline. Since the feature teams we used were cross-disciplinary the pipelines strongly influenced each-other, and were also influenced by those of the outsource groups which supported our team. To get all these work well together we went to numerous iterations before they started feeling like a harmonious process, which only happened in the later stages of the project. It was a very interesting process and gave more insight in the way disciplines differ, but also how they can work together more effectively by working out their strong and weak points, and letting them positively influence each-other.