WILLIAM PEPIN

View on GitHub

Post-mortem of Voliday

Introduction

Context

During my 3rd year in Games Programming at the SAE Institute Geneva, we had the project to work together with several other sections on a video game. This game is part of the module 6204 also called specialization module which aims to specialize by having a role within a team and to learn to work in a project bigger in number of people and in objective than the previous ones.

Instructions

We had some requirements, such as that it be a City Builder video game using Unreal Engine 4 and that it have a similar art direction to The Legend of Zelda: Link’s Awakening.

Teams

This project was not only composed of our Games Programming class but also of 3rd year classes from Audio Production and Game Art. Here are the members of the programming team with their roles:

My Roles

Personally I had the role of Producer, I had to prepare and distribute programming tasks each week to the members of the team. I needed to take into account the team member’s schedule as well as what the project manager wanted to integrate in the game each week.

Pre-Prod

Pre-production started in mid-September where we first had to do small tasks to learn how to use Unreal Engine 4 which we had only seen for a few hours the previous year.

These are the tasks that have been done:

Afterwards, we started to take control of our roles. I had to prepare a project on Jira, a tool for planning and assigning tasks for projects, by entering the tasks and distributing them in time and between people, taking into account the requests of the game designer and the project manager.

At the same time, the DevOps team had to prepare versioning software in order to have different backups and versions of the project at all times. The Game Designer had the most imposing task at the beginning of the project, he had to think the game by writing the goal, the objectives, the rules that had to be implemented. The Lead Programmer had to write how the game should be coded to keep the code uniform and clean. The project manager had to plan the end dates of the different versions of the game such as the prototype, the minimum viable product and the minimum lovable project.

Planning Failure

However, even with planning we were quite late in revising the milestone dates. This delay is mainly due to the fact that we took some time to get the hang of Unreal Engine 4 and also some common module renders just before the holidays. So at the end of December and beginning of January, we redid the milestones to have a more realistic schedule with what remained to be done and what we had time to do.

Artists

We worked with the 3rd year Game Art students who produced the graphic assets for the Voliday game. They had to produce a large number of assets but despite this they kept to the deadlines.

Tools

We also had the 2nd year games programming students produce tools for the project. We didn’t use them because it would have taken us longer to integrate them into the project than to do without.

Audio

We also worked with the 3rd year Audio Production students who produced the sound assets for the Voliday game. They had to produce a large number of assets but despite a slight delay the sounds and music should be present in the MLP version of the project.

Prototype

The first milestone was the prototype of the game, a very simple visual version with the main gameplay mechanics. Initially scheduled for late December, it was pushed back to early February.

MVP

The MVP was the second milestone, which is a version of the game with all the mechanics to make the game playable. Originally scheduled for early March, it was pushed back to late March.

Conclusion

Rendering MLP

We will be releasing the MLP version of the game, the fun-to-play version, on Tuesday 26 April 2022. It will be available on this page itch.io: https://volcanoteam.itch.io/voliday

Difficulties encountered

My main difficulties with this project were that I initially felt like a bully handing out tasks to team members. Also to take into account the side commitments of the members while moving the requested tasks forward quite quickly. I also had the problem of having difficulty dividing time between programming and my Producer tasks, and there was a difficulty in communicating with some members which led to mixing up the tasks that needed to be done according to roles. And finally, getting to grips with Unreal and more particularly the blueprints took a lot of time because it was fairly new.

What I learned

As I got to know the team members I felt less of a bully, especially given their feedback. Depending on the side commitments I learned to redistribute tasks to other members if the person didn’t have enough time to still make the project progress at the requested speed. I also learned to share my time by defining which days I was going to work on which task, whether it was programming or my Producer tasks. Communication problems were more or less solved through oral discussions and written documents. Then I was able to get to grips with Unreal and the blueprints over time with the help of my fellow students.

##Acknowledgements I would like to thank everyone who contributed to the project.

The teachers:

Externals:

2nd year Games Programming students for tools:

Game Art students:

Audio Production students:

And my 3rd year Games Programming classmates:

Retour à la page principale