Studio 3 Postmortem – Slime Herder

A reflection on the performance of Team Slime Herder in relation to our production practices and integration of industry topics and issues into our work practices.


Task management and tracking.

On a weekly basis several tasks would be set and required to be completed in order to meet brief milestones and deadlines. Many of these tasks would arise throughout the dev process such as bugs and altering features to suit new design insights. Tasks were almost always completed within the time that I had set for them including assets received from collaboration (art, UI etc). However the turnaround times and accuracy of the tasks completed by the programming team were very good.

In relation to the core development team the efficiency can be attributed to using Trello effectively throughout the project’s lifespan. The Trello was updated several times a week to outline the current set of critical tasks to be completed and were sufficiently detailed that work could be conducted independently.This was bolstered by in person verbal discussion for more complex tasks. It also helped that the each member actively checked the Trello board and updated completed and partial tasks as they were done further streamlining the process.

To reproduce this result in future projects I believe one of the biggest keys as ensuring that the task tracking tool did not become stale. By frequently updating task, members are up to date on the project progress and can maintain focus on required work. Selecting a tool that is appropriate for the project scope is also relevant however consistent clarity remains the priority.


Team/production management

Including collaborators I had to manage 8-9 people and obtain deliverables within deadlines to ensure we had assets for our milestone builds (alpha, beta etc).  Overall this was a great success bar a few instances of sub par assets or collateral being omitted altogether. Most collaborators were able to understand the game’s premise and themes and then translate this to appropriate assets including sprites, background art, a game logo and UI elements. The quality of these assets were up to a high standard and where applicable were iterated to meet the specifications (e.g. logo).

A contributing factor to this was the point at which the collaborators joined the team. Due to having a functional prototype and example artwork and documentation artists were able to understand our requirements almost immediately. However as this left us with a shorter timeframe in which to execute and deploy these assets we adjusted the due dates for asset creation. By allowing several days slack we gave ourselves the opportunity to reassess and have any assets reworked if they did not meet functional or quality standards. This ended up coming into effect when our background art had to be reassigned and reiterated due to quality issues.

To assist in future collaborations it’s is obvious that providing as much indicative functionality and visual feedback in a prototype is the most effective way to communicate requirements and give assets an actual context. Establishing clear deadlines is a must as asset creation time can vary drastically and any production issues need to be made apparent from both sides of the team. In future I will now establish baseline fidelity requirements to avoid receiving assets that are not usable, especially in a commercial project.


Preventing Discipline crossover and team conflict

Historically myself and certain team members have a habit of conflicting and having a large amount of negative interactions due to leadership and disciplinary crossover issues. However for the duration of the Slime Herder project issues were at a bare minimum with 2 small incidents resolving quickly and having little effect on the project outcomes.

A large part of this is due to establishing my leadership role clearly during team formation. By providing sufficient documentation and grounding the dev team’s understanding of the project’s goals I was able to gain the team’s trust and respect. When a team member did overstep their bounds rather than passively ignore it to prevent conflict I addressed the issue immediately despite discomfort. By resolving issues quickly it prevented any lingering discord and prevented the project from veering off track.

As stated having a solid foundation during team formation is key to keeping everyone focused and incheck. Establishing expectations and team boundaries early helps to prevent a lot of issues however addressing problems as they occur is essential and needs to be handled as such by the team lead consistently.

Issues with asset deliverables

In two instances assets delivered were not up to standard or they weren’t delivered at all. In an attempt to maintain the working relationship and obtain deliverables I maintained communication with the collaborators in question and tried to work with them and lead them to understand our requirements or to even stay in contact and produce assets. It was only after too much time was invested that I realized I need to move on and source alternate avenues. Luckily we were able to either get an alternate person to deliver our assets or sources open licence assets ourselves. However this situation is not optimal as there is a sacrifice made to the project’s overall quality and the time consumed in the process is extremely valuable and in a commercial environment has negative financial implications.

Unfortunately it is hard to gauge how work from new collaborators will turn out if you are unfamiliar with them but in turn part of this issue can be put down to a lack of reference documentation or documentation that is not detailed enough.

Some of these issues are difficult to prevent however what I can do in future is provide a large amount of reference material and issue quality guidelines for asset creation. If assets do fall through however as they are likely to in the future, I need to evaluate how much time i am willing to invest in people who do not deliver and move on sooner to ensure that the critical path is not delayed due to issues in one department. This requires further development of my leaderships skills and ability to evaluate priorities objectively.


Not playtesting early enough

Playtesting is a huge part of the development process and in hindsight I believe we missed out by not conducting more testing earlier. There was some feedback and observations seem fairly obvious now but could have been easily uncovered has we put the game in front of more people and gathered more insight into our design assumptions.

Part of this is a personal issue I have with presenting ‘unpolished’ to people which prevents and slows down the feedback process.

In short I need to be less worried about prototypes flaws and search for the feedback I need on the game’s core design. Alternative to just using in person testing there are channels for testing such as online communities that i have recently started to utilize that helps remove some of the personalization issues. Our playtesting needs to happen as soon as we have a playable loop.

Not enough pivoting on early prototypes

In the early weeks during research i worked on several prototypes and then settled on the lemmings based concept. Rather than further iterating and experimenting, we locked down fairly quickly in fears of not meeting deadlines. As much as this is true there is missed opportunity to find more interesting combinations of mechanics.

The main reasons for this behaviour is part of generally risk averse approach to concept development and wanting to leave ample time meet deadlines however this could also be indicative less than optimal scheduling and prioritization when balancing the extra tasks we were assigned.

In future I need to allow for extra pivot time in my working schedule. When evaluating prototypes i’d like to record and make notes on those that had interesting elements and further explore combinations and new dynamics even after choosing to pursue an overall design. By maximizing this process more innovative and unique games can be created.

Underestimating time for new tasks – marketing, level creation

During this project there were a lot of new tasks and challenges to learn about and overcome. Usually our projects solely focus on developing a prototype but this time around there was an equal focus on marketing and additional tasks and due to our team size team management made up a large component of my schedule. Although the project ran smoothly for the most art I feel that certain aspects could have received more focus such as some of the marketing components and public engagement.

Mostly this is due to the clear lack of experience with releasing a mobile game but is also an issue of prioritization and research. Level creation and iteration for a puzzle game was a far bigger endeavour than I could have expected but could have been managed better by doing earlier time tests and adjusting schedules to account for it. Another reason some tasks were neglected was their position in relation to the critical path as twitter posts and blogs aren’t critical to the game launching but do affect its reach and success.

When entering into unknown areas of development it’s clear that I need to devote more time to researching new tasks and evaluating their impact on the project schedule and any risk associated with it rather than assuming that tasks will be equal.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s