Defend Your Friend is a truly co-operative puzzle game.
Both players are not just important, but vital - each with a unique role to fulfil. Through working together, combining their abilities and having each other's back players make their way through carefully crafted puzzles inside an imposing ancient temple. Getting to understand the inner workings of the temple, and hopefully venture off to freedom.
Both players are not just important, but vital - each with a unique role to fulfil. Through working together, combining their abilities and having each other's back players make their way through carefully crafted puzzles inside an imposing ancient temple. Getting to understand the inner workings of the temple, and hopefully venture off to freedom.
DETAILS
|
My Roles: Producer, Team Lead & Gameplay Programmer
Development Team: Frenemies Team Size: 14-19 Platforms: Windows, Mac and Playstation 4 Engine: Unreal Engine 4 Development Cycle: November 2015 - July 2016 Release Date: 2018 Website: http://defendyourfriend.com/ Reception: Defend your Friend was received well by developers and players. It won Best Game of Indievelopment, and passed Steam Greenlight in less than 3 weeks. Awards:
Nominations:
|
|
MY WORK
Defend your friend was my first time functioning as a producer and Team Lead. I used the Scrum methodology and focused primarily on my Team Lead role as a facilitator. I was responsible for the efficient collaboration between the team members, as well as making sure that every individual team member was involved with the project and happy with the work they were delivering.
In this role I organised and hosted meetings, planned and tracked milestone deliveries, gave milestone presentations to the stake holders, managed external resources, and maintained interdisciplinary communication. Having been in this position, I have gained a much better understanding of how game development teams function.
Additionally, I worked on Gameplay programming; primarily related to UX and player feedback. I used a combination of C++ and blueprints to develop these systems.
For more detailed descriptions of some of my tasks expand the tabs below:
In this role I organised and hosted meetings, planned and tracked milestone deliveries, gave milestone presentations to the stake holders, managed external resources, and maintained interdisciplinary communication. Having been in this position, I have gained a much better understanding of how game development teams function.
Additionally, I worked on Gameplay programming; primarily related to UX and player feedback. I used a combination of C++ and blueprints to develop these systems.
For more detailed descriptions of some of my tasks expand the tabs below:
Production & Management
Defend your Friend was my experiment into working as a producer and team lead. Being a producer is quite far removed from my comfort zone so I always wondered how I would perform. Initially the team was going to be quite small, but I ended up running a team of 16 people! This was scary, but it went very well. With us being one of the best games of the year, and getting the attention from Sony.
In this role I wanted to address the main issue I had with producers in previous blocks. Mainly, producers never felt like a great part of the project. Often, the producer felt like a person that made plannings (the developers never saw), and communicated with the supervisors. This is not what a producer should be! So I wanted to be different. Mainly, I wanted to focus on my team lead role as a facilitator. I saw it as my primary responsibility to ensure effective communication between the team members, as well as on an individual level ensuring that everybody was happy and had ownership over the project.
Before the project started I wrote out a list of things I thought were important to succeed:
In this role I wanted to address the main issue I had with producers in previous blocks. Mainly, producers never felt like a great part of the project. Often, the producer felt like a person that made plannings (the developers never saw), and communicated with the supervisors. This is not what a producer should be! So I wanted to be different. Mainly, I wanted to focus on my team lead role as a facilitator. I saw it as my primary responsibility to ensure effective communication between the team members, as well as on an individual level ensuring that everybody was happy and had ownership over the project.
Before the project started I wrote out a list of things I thought were important to succeed:
- Have a long preproduction stage, fully work out the concept and its intentions before committing. Make sure everybody knows what the concept entails.
- Scope low, find something with a low base scope that can be expanded if time allows it; assume this is not the case.
- Design by subtraction, remove elements until the minimal viable product has been found and created.
- Have daily scrum meeting, make sure everybody knows what is happening within the project.
- Regular individual talks, these chats give the team lead insight to issues that may not be obvious at first.
- Double estimations, game developers are notoriously terrible at planning – just double it.
- Scope for programming to be done 2 or more weeks early, give the designers time to iterate. And bugs time to be found, and fixed.
- Quality over Quantity, it is generally better to have a short ‘good’ game than a long ‘bad’ game.
- Discuss big decisions with all involved departments, don’t leave out team members from decision making.
- Encourage cross department interactions, everybody should work as a team.
- Prevent downtime at all costs, get dependencies right – down time is incredibly demotivating.
From this I made a general plan for communication. Slack was to be used for general communication, while Trello was for task tracking. It was the department lead's responsibility to make sure people tracked their tasks correctly.
|
Image 1 contains the meetings that I put in the planning for the project. The most important ones were definitely the scrum meetings, and the lead meetings.
The scrum (stand-up) meeting ensured that everybody had a general idea of what everybody was doing in the project, as well as being a perfect platform for team wide announcements. The weekly lead meetings were some of the best meetings I have ever participated in, and helped us create an efficient planning. The main goal with these was making sure that each department was focusing on the correct tasks. It was all about dependencies, the different departments could ensure that they weren't hindering the other departments, and could discuss exactly what they wanted from the other each other. Generally during these weekly meetings we would reflect on the last week: what went right? what went wrong? how could we improve? and then plan out the tasks for the next two weeks. By planning for the next two weeks, every week, we could reflect on what we have planned previously and realise if anything has changed and analyse why it changed. |
Image 1
|
I also had talks with all team members individually every 2/3 weeks, asking them questions about how they are feeling about the project, and their personal contribution to it. This allowed me to have a pretty good idea of how everybody was feeling, and lets me try to solve the less obvious issues. This was also greatly appreciated by my team members, as they felt like I was really trying to help them.
|
Of course I also still had producer tasks. As a producer I create both high level, and low level plannings based on the lead meetings, performed risk analysis, planned milestone deliverables, communicated with external developers, and hosted stake holder presentations - in which I successfully presented our progress and planning to the supervisors. Allowing us to continue with the project for the entire block.
|
| ||||
high level plan
|
low level plan
|
|
At the end of the block I setup a google form in which people could review each other. Image 3 shows the feedback I received. And people were generally quite positive about my contribution to the project.
Even though I don't think I ever want to be a producer/team lead again, having been in this position has been incredibly valuable. And made me a much better developer. It taught me countless useful skills with regards to effective communication. And gave me a much better idea of how all the departments work, and can best collaborate. Especially for artists, of which I previously didn't know that much. I am very proud of the result. |
Image 3
|
Gameplay Programming
In the next block, I decided that I no longer wanted to be a producer for this project. And shifted my role to that of a par-time gameplay programmer. In this role I worked with blueprints and C++ to create or improve on various gameplay systems. This includes systems such as: The doors, the crystal feedback system and materials, the death system, small development tools such as tools for helping place rocks, terrain materials etc.
This was the first time I got to work with Unreal in a project setting, and helped me get a much better understanding of how the engine works. During this time I went from quite rudimentary knowledge of the engine to intermediate levels which I then continued to improve on during future projects (Akuma no mori, The Red Stare).
This was the first time I got to work with Unreal in a project setting, and helped me get a much better understanding of how the engine works. During this time I went from quite rudimentary knowledge of the engine to intermediate levels which I then continued to improve on during future projects (Akuma no mori, The Red Stare).
