Trailers
Overview
I led a 28-person team to create a co-op puzzle platforming experience involving some very cute candles! This was for my Senior Collaboration project at the University of Staffordshire!
Being a producer for a team of over 28 people across two campuses was no easy task, however for an 8-week project I believe we succeeded greatly!
​
​
Twin Flame's development time lasted 8 weeks, here are some of my key contributions:
Role: Lead Producer
Genre: Co-Op, Puzzle, Platformer
Engine: Unreal Engine 5
Team Size: 28
Duration: 8 Weeks
Platform: PC (Itch.io)
Year: 2025
-
Coordination
-
Coordinated the development of the project ensuring a smooth run of development from start to finish.
-
-
Communication
-
Ran weekly meetings, set weekly goals, made announcements, made review posts, etc.
-
-
Project Management
-
​Organised the projects milestones, schedule, documentation and more.
-
Coordination
Initial Week:
Starting off with the initial week, I made a skills-audit form for everyone to fill out to get an understanding of how our resources were spread. It was at this point that I found out that I was going to be the producer. This was a great start because I was then able to allocate roles to everyone based on our strengths and weaknesses. I feel that I assessed the team well here and spread our resources well, even over second-choice areas such as visual effects, animation and audio.
​
Scope:
Following on from this, the skills audit immediately indicated to me the weak-points of our team and limitations to the scope of those areas of development. Ultimately, I knew that the scope of our game would need have simple animations and not many characters as we only had one character modeller, and no specific animator. Having this understanding of our teams limitations, coming up with the game idea/vision became easier and I think two candles in a dark tower was a great idea with manageable scope. ​​This immediately set us on the right track as we were not overwhelmed by scope, and I believe that while this is less significant at the start, at the end of the projects development, having a smaller scope enabled us to create a polished and feature complete game.
Furthermore, I specifically remember a point where one of our designers suggested making an outside level. I personally shut this idea down straight away due to how much stress it would have put on the art team. At that point in development, the art team were just about to move onto animations and so prop development would slow down, hence a completely new environment was a terrible idea.
​
If I had not be rigorous with the scope, this one decision could have drastically changed the quality of the end product. I am proud of how well I managed the scope of Twin Flames, and I definitely took a lot of learnings from how it was managed when I was a Junior last year.
​
Tasks:
The development of Twin Flames followed a hybrid model. The development process was encompassed by a waterfall methodology, but an Agile methodology within it. What I mean by this is that there were milestones of where the project had to be at, which was already laid out by our University via the weekly briefs, but within each week we would have regular meetings to discuss current progress and what needed to be done next (agile).
For managing tasks, our University made us use MS Teams Planner. Personally I preferred when we used JIRA during the Junior Collaboration Module, but it was still effective. I setup clear labels for each task to help organise this large board of tasks:
​​
​
This kept everything more organised.
When it came to actually setting tasks, I didn't specifically set that many but I have a good reason for this. Each week I would lay out Goals to hit by a deadline, example:
​​
​
​Then from this list of goals for each department, the Leads would then respectively set the tasks to their team. I feel that this was a successful approach for two reasons.
One, allowing the leads of each feature team to set tasks meant that they can include more specific detail in that task on how they wanted it to be done. For example, the art team would know more about the pipeline or rules for making an asset and hence can specify that in a task with more detail that I would have been able to. Ultimately leading to clearer and more specific task setting.
The second reason is that each Lead will then know who in their team has worked on what area before. So if John had worked on the lantern in week 2, and then it needed improving in week 5, the Lead for that team would know that John had already made it before and so the upgrades to the lantern should then be handled by John. If I was setting tasks for all 28 people it would have been harder to manage things like that and it would've increased the chance of task cross-over where 3 different people have worked on one feature which would've slowed down development.
​​​
Playtesting:
​An additional point about coordinating the project is how well we responded to feedback. Week 6 involved a large playtest session where we got feedback from over 20 people. As a producer this in invaluable as it gives me understanding of how the project is being received and if any major changes need to be made. I have covered my response to this in a previous forum post but essentially, I instantly went through all the forms feedback in the Excel spreadsheet and collated it into a summary of feedback post for Teams. I then organised a meeting for the team so that we could gather together and review the changes we need to make. Tackling this feedback head-on was a big positive for the project as it allowed us to fix weak areas and improve the project drastically.
Communication
Communication is a huge part of being a producer too, if you can't communicate with your team or can't get them to communicate with each other, then the project is ultimately doomed to fail. The first thing I did as a producer was to create tags on teams for everyone so that specific groups of people could easily be notified:
This made communication much more effective.
​​
As the producer, I ran most of our team's meetings. Encouraging open-communication was something I aimed to do during meetings by letting people say their opinions and ask questions as much as they needed to do. I wanted the team to always feel heard and so that they know they could talk to me about anything. Moreover, I tried to give positive feedback whenever people posted progress updates on teams to ensure that they knew their work was being acknolodged and appreciated. I hope this helped to motivate the team to keep working hard throughout (which they did well!).
​
​Meeting summaries were a technique that I know really aided in our teams communication. After any meetings like our regular Monday meetings or Wednesday review meetings I would always provide a summary of what was covered in the meetings for those who missed it. These regular meetings were a great method of communication and helping us reflect on our progress so far:
This was clearly a success with people because other leads started to do the exact same thing and this helped the team to stay up-date with information as in a non-professional environment, not everyone is available all the time. Speaking of this, my attendance was great throughout the whole process and I ran nearly every meeting we had with the team and lecturers other than for any medical appointments. As a producer, it is critical for me to be on-hand for people to rely on during these sessions and I feel that I did this well.
​
On top of this, I directly messaged people where needed throughout the project to communicate any changes or issues if they were specifically involved. For example the trailers development was done right at the end of development so directly contacting Adam allowed me to stay in the loop and ensure it was going to be ready for deadline
Project Management
Planning:
As mentioned in the Coordination section, we were given weekly briefs by the University and a general over-arching flow of development for the 8 weeks.
​
During Hollowborn, my final year project, I used a Gantt Chart to manage the projects milestones and deadlines. I found the process very helpful and successful. Therefore, ​I did make a Gantt chart for Twin Flames to try and keep track of milestones and progress, however I feel that this was not very effective. I found myself not using it all that much. This is my Gantt Chart:
I hadn't updated it properly as it did not feel all that useful. It could be due to the milestones and tasks not being specific enough, or it could be just that the projects weekly checkpoints were already pre-made for me by the university. Or maybe even it is because the project was developed using an agile methodology and so the Gantt chart was somewhat useful, but not as useful as reviewing progress weekly and then reviewing from there.
When compared to how useful the Gantt Chart was for my Final Year Project, it feels like I failed to use it well here. Ultimately, the Gantt chart was still helpful but for an 8-week project I may not bother to make one again, but for larger projects it is definitely necessary to have that level of detail for gauging progress.
​
Documentation:
I feel that I should have documented development a lot more than I did. It is important for the producer to be 100% organised and be involved in the creation of things like the Games Design Document and the changelog to ensure that it all lines-up correctly with the vision for the project. There was some confusion caused by this throughout the project with people asking me specific things that I couldn't remember how they were meant to be within the GDD.
Documenting more often would have ensured that I was always up to date and had something to reference if people asked me a question I did not know. Additionally, it would have helped to showcase where the project is at better during meetings.
​
Risk Management:
During a game's development, big issues and road-blocks can occur which is why, as a producer, I should have developed a contingency plan. I didn't even consider Risk Management as a producer, but this is something very important particularly for larger projects.
During development, there were issues with the animations as they were taking too long and didn't look great. Fortunately, we quickly figured out that we can try and use mixamo to get some animations into the game at least, however this risk should have been identified already so that the mixamo solution was there as a back-up without us needing to panic. Understanding ways to pivot or tackle big obstacles in a game's development is now something I understand the importance of as a producer.
​
Reflection
Improvements:
Comparing my work to other's and industry level work has helped me identify plenty of areas for improvement.
Presentation:
For a start I should have presented my information better to make it easier for the team to read. These big lists I was giving for the weekly goals were sometimes a bit overloaded, and an approach I could have taken for this is to present it in each team's channel respectively (rather than all in one channel like production), or I could've have made them into a table format for easier reading and clearer presentation.
For example something like this:​​​​
This is a much more presentable format, and tasks can be created easier by leads based on this.
Furthermore, presenting within meetings was something I was learning throughout this project. Creating a PowerPoint to go over current progress and issues is much more effective that just chatting with people over teams. This helps to keep them visually engaged and is something I only made once throughout the project so I would change this to do this for every meeting as long as it is applicable.
​​
Communication:
​I definitely could have improved how I managed the team and communicated with people too. The project suffered because of issues related to the art and audio team. This came from me not checking-in with people directly about their lack of progress of absence.
One guy on our team, "Julian", had a much different situation than what I was expecting which explained the lack of work. If I had discovered this sooner I could have then planned for this and adjusted scope, however for too long I left it unchecked until it became such an issue that I put some sound effects into the project myself. In industry you can have daily meetings to check-in, but here it is not the same and I should have made sure to check-in more often with members of the team, specifically the leads, to understand any issues and why they are happening rather than hoping they get fixed or their work is done soon.
Another example is the art team, "Haroon" was really struggling with the animations, but I didn't know this until about a week later so I should've been more proactive in dealing with this and checked-in with him about what's going on and what I could have done to help him.
Conclusion: