Post Mortem: Toolin’ Around, By Halves

Introduction
As part of our practice to make user friendly tooling at SAE Qantm, we were required to create tools for designers’ projects.

For the latest project, the design students have to make a game with the following limitations:

In your assigned team, you are to create a fixed-screen game for PC with limited inputs. Your focus will be on mechanics and level iteration.

Creative Limitations:

• Must run on PC
• Use only the arrow keys for gameplay.
• Levels are loaded from an ascii map text file
• Art assets are to be created in Magicavoxel.

While we are not involved in the design process of the game, we have to assist each team by providing them with tooling that will help them create their intended games with ease.

What went right

1.      Programmer per team

This was a happy accident, by that I mean it was never our initial intent as at the start of the project there was three teams. These teams needed different things, which we both started working separately on. Eventually they became two teams with separate needs and as we were already working on separate components we became the programmer for each team.

This meant that we could work on our own systems and be accountable for those.

2.      Communication

As mentioned above, because we had an individual programmer per team we were both accountable and accessible to the designers. They were able to give us design documents early and we were able to create systems then based on their needs. Even though we had set up repos where they could leave error messages, most of my communication was through direct messages. Solving issues as they arose.

The way I worked

Based off the initially pitched game by the designers, I was able to pitch back to them what I thought they would need, this way any issues they had would be addressed early. Not saying that all issues were fixed early, as the designers only decided that they wanted some functionality on the fly but there were minimum problems.

What went wrong

1.      Separate Workloads

While having separate programmers for teams was a blessing, it also meant that you were solely responsible for the work that team needed. While the workload was roughly the same, the difficulty of one workload was more significant than the other. Putting stress on one person. 

2.      Helping alternative team

This follows up with above, When the other team was having issues with things getting done, it was harder for the other programmer to step in and help. This was for a few reasons;

·         Separate systems, understanding the other programmers’ systems could sometimes be difficult as well as altering their work could sometimes cause frustration.

·         Martyring themselves, sometimes people don’t want to be helped due to whatever reason. 

What to do in the future

1.      Scope

In the future accessing the scope of work needed to make sure there is an even distribution of workload. If there is disparity between them maybe take a few extra tasks to help the other
 

Conclusion
This project was a great test of the newly acquired skills from the last toolin, putting what we had learned into practice. The overall outcome of my teams’ game was pretty successful, this in part was due to the great work ethic they have but also their communication with me whenever they had problems arise. IGN 9/10 would work with them again

Check out their game here:

https://slemhosta.itch.io/skimminal 

Development stats

·        Developer: Ben Walker, Dan Ackroyd

·        Length of development: 4 weeks

·        Number of developers: 2

·        Development tools: Visual studio, Unity