Studio 3 team project post mortem

I couldn't think of a good title for this, so here's a generic one that tells you exactly what it is...

This team project first started with the designers being allocated to clients, they formed four to five man groups to address each client. Then they outsourced the programming tasks to us where we were also divided into four and five man groups. We met every week to sort out the changes from the previous week, the feedback for said changes, and what needs to be addressed for the current week. Or at least, something along those lines...

As for the project itself, it's a mobile game where the player plays various minigames that have a connection to real life. Such as avoiding spiked drinks when out at a bar/pub of a night or teaching them to look left, right then left again when crossing the roads to avoid getting hit by traffic. Completing these minigames nets the player XP which is used to give the player a level and to unlock various avatar customization items so they can personalize their virtual avatar.

What went right?

Overall, I think the systems I implemented (Level system, Avatar controller, App check and database storage) were quite sound and did the job they were expected of them. I felt like the project accomplished the goal we wanted to achieve even if we had a lot of roundabout methods of going about different things, such as minigame quality and the git repo (which was a mess).

The level system was something that could have used some touch ups here and there, but was mostly quite robust with letting the other programmers influence the XP gain for the minigames.
The avatar controller did what it was meant to, even though it was the most time consuming. Going through various methods of "discovering" the customization items for it and then setting them when the player wants to change between them.

There was a feature of the app that increased the XP gain by having a multiplier, and that multiplier would be set based upon if you had three apps installed that were connected with project. So I went about looking up various methods of doing this inside of Unity and came across Unity's implementation of the AndroidJava class which allowed me to use the Package Manager to query Android about if a certain bundle ID was installed. The downside to my implementation was that we wanted to target iOS but I had to write native iOS/Swift code to get the same result, which you can't do in Unity on Windows as far as I know.
The database storage was a good feature in my opinion, it allowed us to save the data we wanted and not have to rely on Unity's PlayerPrefs which can be buggy from time to time.

What went wrong?

As I mentioned above, the minigame quality and git repo were things that didn't go according to plan, or rather no plan. And that was probably the reason why...

The minigames accomplished what they were meant to do, but the development of them was somewhat chaotic, the quality between all of them various with a few being larger apart than some others. This is probably due to not only the asset quality used in all of them but even the code behind them and going about different ways of executing things, which is really just personal programming practices but we could have had some sort of structure to the whole thing.
The fix for the quality overall would have been some sort of structure and base template for the other programmers to take up and then extend based upon the requirements of the minigame they were working on. And me being Team lead, I felt like that was partly my fault for not thinking about it in time and forcing an implementation.

Now for the git repo, it was a mess. People didn't pull changes and just pushed their commits straight away, as you can see in the screenshot below. And these "breaks" weren't just a every so often thing, it happened at least once I week from what I can gather. I felt like I was really the only one who knew git to an extent where I can avoid this, it's quite trivial, we didn't have communication on when somebody was pushing their changes. People were using different clients, while it doesn't have much impact. It does mean that features don't line up and the merge tools were different because of it.

It's trimester five and I'm kinda disappointed not everybody knows the intermediate level of git, I think some people still see it as magic to some certain extent. So going forward I feel like I need to establish some sort of git rules document where people can reference to and from on issues with git and general practices for alerting other team members that you are in fact doing something that could take a little while or using different branches to a certain extent.


In the end, I'd call it a success. We delivered to the client and await their response. They haven't said it was shite yet, so hopes are high for this to pull through. If I get a chance to continue development, I'll be polishing a lot of my systems and redoing some systems here and there...

Tom Lynn

Read more posts by this author.