(For context, Misorderly can be played or downloaded through links in my portfolio.)
It’s difficult to explain anything that went right with our project without first explaining everything that went wrong. So for this post-mortem, I’ll be examining the major obstacles we faced in creating the casual action runner that is Misorderly – and what it took to overcome them. I should mention that all points raised here relate to soft skills – design, project management – so if you’re looking for a technical post-mortem, this isn’t it.
Problem 1: Mixed Vision
Misorderly wasn’t our first idea. Originally, our favourite concept was a god game where tiny people wandered around a rubik’s cube planet and each square was a different land form that evolved depending on the other land forms it touched. But at the time, the teachers felt it was more of a toy, than an actual game, so we shelved that idea.
All the other ideas we came up with, only most, and not all of the team loved. And at VFS (Vancouver Film School), you’re encouraged to only go forth with an idea for your final project if everybody loves it. So if I were to go back even further, I’d offer the notion that something that was done incorrectly in our class was team forming. Each person on our team had such different player preferences. To the extent where one of our teaching assistants, Brant Stutheit, suggested that we do an activity where we write down our top 5 favourite games and see which ones we had in common. It took us until our top 20 games to eventually reach consensus – Bioware’s Dragon Age series. We then explored what it was about the series that we enjoyed, and we realized we all liked playing as mages. This was the beginning of Misorderly.
We decided to make a game centered on being a mage. So we brainstormed what we each enjoyed about playing as a mage – healing, buffs, spells, support – and we deduced our mage would need a party. But given the scope of 5 months and 5 relatively inexperienced students – how could we manage to capture the essence of the RPGs we loved?
Suggestions were made for things we thought would make our lives easier in production, such as a side-scrolling camera to reduce environment art assets needed. Or a cartoony art style over hyperrealism, to invest in creating more characters versus polishing a fewer number. Or restricted, grid-based movement, to simplify combat. But not everyone was ecstatic about these changes in direction.
Everything I’ve mentioned thus far formed the basis for the mixed vision we had for the majority of production. We were so concerned with placating everybody’s wants that we A) wasted a lot of time in pre-production changing our game concept and B) ended up with a “swamp water” game concept that had too broad of a target audience (not that we were able to accurate pin point what our genre or expected player experience was for the longest time).
Lesson 1: Player Vision
At VFS, we had 4 mentor sessions a week. This meant teachers and industry folk came by our desks, examined our game and our progress, asked us questions about how we were doing, and offered advice and suggestions on how we could improve our game.
We tried to sit on advice for a couple of days before deciding whether to act on it, but given the high number of sessions each week, that became more and more difficult to do the closer we came to big milestones – there was more pressure to change. One of our teachers told us that our game went through more iterations than any other project that had gone through VFS. One of our major struggles was that our desire for a complex, strategy-rich game was at odds with the time restrictions offered for the night our game was being created for. See, the production period of VFS final projects culminates with an event called “Pitch n’ Play’, where the students give 7-10 minute presentations of their game to industry folk, who are then invited to play the games in a two-hour networking session. So although we had rewarding gameplay loops, we needed a 20-minute tutorial for players to get a comfortable grasp on the mechanics and to truly enjoy the strategic elements. We did not have that time. So we continued simplifying our mechanics, whilst naïvely holding onto our vision for a complex player experience.
It wasn’t until the final month of production that we fully acknowledged that this wasn’t going to work, and we took our combat-grid and puzzle-runner sections and mashed them together, into the casual action runner you see today. We knew we had to go casual, because we simply didn’t have the time to pursue anything more complex.
But by this point, the game had morphed way beyond any kind of product that any of us would have been stoked to purchase on Steam. Motivation was sapped. We’d started off wanting to make an incredibly unique game that catered to all of our passions, and by that point, we were just hoping we’d eventually finish the game and that somebody would find it hard to play. And that would make it all worthwhile. And by ‘it’, I mean our time spent in production, and all the drama that had come with it. Which brings me to my next point.
Problem 2. Prolonged Interpersonal Drama
So this next point is very sensitive. I’ll give the basic summary – we started off as a five-person team and became a four-person team just after milestone one. Let me preface everything I’m about to say with the following. I do not hold any bad feelings against the person we let go from the team. They had external, personal issues to deal with, that weren’t necessarily their fault.
However, I don’t condone the behavior they displayed. We attempted to make things work with them for 3 months. It got to the point where we were spending 2-3 hours per week on either partial or full team mediation sessions. For context, our core hours were 10am-6pm, Mondays to Fridays. With an hour taken off for lunch each day that means 7% of development time was wasted on team drama. This is without taking into considering the emotional toll this took on everyone, which in turn affected team morale and motivation.
Without speaking for others, let me explain how I felt. By the time we made the decision to part ways with our fifth member, I was on permanent verge of panic attack and had been feeling tight chest pains for a week straight. Not to say one person directly caused all this – I had external issues to deal with myself – but the team drama pushed me beyond my normal capacities to deal with stress.
I also had to accept responsibility for my role in what happened. I’m the type of person, who can’t sit idly by when issues arise – my personal motto is that if you have a problem with something, and you do nothing to address it, you have no right to complain. But during production, I learned this could come off as harsh, and that a confrontational nature isn’t conducive to everyone’s situation. Honesty is the value I hold dearest, but sometimes my openness came across as tactlessness, and when confronted about it, I went through some painful personal growth to try to become a better person.
Lesson 2: Drawing Boundaries
In contrast, we eventually realized that the person we had the greatest issues with was not willing to change their behavior. It was at this point that we knew we had to draw the line. We had one more team meeting with them then brought in teachers to finalize the process.
But here’s the thing. They should’ve been cut from the team during pre-production. There had been warning signs from early on, and we’d brought these up with teachers. But we were encouraged to do everything in our power to keep the team together. Splitting up the team was a last resort. We were of the belief that if we kicked them off the team, they would fail the program and their life would effectively be destroyed. We weren’t comfortable doing that.
So we let the problem stew. Our mitigation was only effective in so far as it delayed the inevitable blow-up from the build up of interpersonal tension. But the team members that remained, and the one who left, would’ve been much better off – both project and emotional health-wise, if we’d been able to part ways much earlier.
On our end, the split meant we had to start over from scratch with character art. This was a huge blow to our production timeline and meant redesigning the game to a more manageable scope (this was before the previously mentioned merge of combat-grid and puzzle-runner sections), as well as shifting roles around the team that created more stress. (E.g. I took on the role of art support, despite not having taken the art stream at school.)
For the person who left, departing earlier might’ve given them the chance to join another team, or to have more time to properly plan out and work on what they eventually ended up doing. Overall, it would’ve allowed us to avoid a lot of emotional trauma that we all endured. But let me re-iterate – one person did not solely cause the team drama. Which leads me to the third problem.
Problem 3: Mixed Management
This one is personal. As project manager, I’m only proud of my performance in the last two weeks of production. Otherwise known as that sunny, lovely thing called “crunch time”. Prior to this, I made a lot of mistakes. But I’m glad I did. I learned a lot about human motivation, about my teammates, about myself, and I feel like I’ve grown a lot as a person. It forced me to mature in many ways. I’ve still got a long way to go, but I’m more confident knowing that I’m capable of identifying and rectifying my mistakes.
In the beginning of the project, I was way too stressed and strict about certain things. Wanting everything to be perfect was a detriment – it made me indecisive about things, or prone to change things for fear it wasn’t the best possible choice. I know this clouded my ability to procure a solid vision during the earlier days of production and contributed to the great number of iterations the project went through.
Then there were the smaller things, which still added up. For example, we had issues with team members not coming to school on time, which meant there were large chunks of time where the whole team wasn’t present. This set us back when it came to needing to discuss things with individuals, or work being blocked because someone else needed to complete something first. So I initiated a rule where at 10am sharp daily, we would conduct scrum. If anyone came late, they’d have to perform a solo scrum. This helped encourage (stress) people to come on time – but only to a certain extent. We even ended up having arguments about the importance of punctuality.
But after that particularly tumultuous period in production that culminated in us letting a team member go, I ended up burning out. I didn’t feel I had the right to advise people on how to organize their work, how to motivate themselves. I felt a lot of guilt for what had happened. So I went to the other extreme and adopted an incredibly relaxed management style. I named us “team chill”. My attitude was that what was most important was the happiness of each team member – regardless of where the project ended up.
And so came the period of great unproductivity. Team morale was low and we were all visibly tired. We had little direction and negative outlooks for both the game and our futures.
Lesson 3: Optimism and Schedules
To turn things around, I began by questioning my own low morale. How could I have any chance of motivating the team if I felt so down myself?
I realized that the roles I had taken on for the project didn’t reflect my passions and what I wanted to do in the industry. Up until that point, my time had been filled with project management documentation and writing dialog. Whilst I love narrative design, this meant I’d been living in excel and word and had yet to see any visible impact from my work in game – I’d barely spent any time at all in the Unity project. And this problem of being pigeonholed was something that affected other people on the team too, where they weren’t doing tasks that correlated with their life goals. To some extent, this was a by-product of the structure of a program that’s marketed as game design, but teaches students more about game development. So by the time you reach production on final project, you have teams of students who all want to be game designers – but who have to fulfill other roles.
The very act of identifying one of the sources of my dissatisfaction was enough to make me feel better and more energized. The second source was a bit more problematic. It was the fact that our game sucked. It was confusing, had contradictory design and was just downright not fun to play.
This was the point at which we decided to say goodbye to our puzzle-strategy game and said hello to our casual action runner. This was our final major iteration. We were one week away from alpha. (Which we really only reached at beta.) This change greatly relieved me. However, not everybody on the team was able to foresee what the game could become, if we worked really hard up until final. I understood why. Each person had different reasons for being at VFS, for coming to school each day. So I made an effort to talk to each of them individually and find out what their blockers were.
One of the things that probably ended up helping me more than them, was finding out that our programmer really disliked UI programming, which sapped a lot of his motivation. So for the sake of getting the project done, I offered to do the UI programming for him. In the end, this was a huge benefit for me because it meant I could get more hands on with the project, learn additional technical skills, and it helped me realize that I love coding.
But the thing that probably helped the most from a practical standpoint, was when two of the industry mentors, Jarret Metcalfe and Glen Hamilton, came to our group and asked about our task-lists leading up to final, and whether the remaining scope was manageable. My initial response was that I’d written and printed out my own personal task-list and it was under control, but my teammates preferred to concentrate on their work without taking time out to write schedules. The mentors were shocked and told us we absolutely needed to plan our schedules and it’d be well worth our time.
I was pretty embarrassed. I knew it was something I should’ve done earlier – that I had been doing previously, but hadn’t felt I had the power or moral standing to enforce anymore. But that conversation was the catalyst for change. Afterwards, I asked my teammates to make task lists. The first positive to come out of scheduling was that we quickly realized that our level designer was over-scoped so we moved particles from his workload to our artist’s task list. This was a great move, because the amazing particle work he did bumped our game up several levels both visually and gameplay-wise (since they were important for player feedback). The greatest benefit was now everyone had tangible daily goals to meet and this made it easier to track progress in the lead up to final.
I’m really proud of what our team accomplished in that final month. We crunched hard, and we ended up with a finished, fun game. But what really amazes me is how we came together in the end. When I think back to earlier days where we were all glum and didn’t enjoy spending time with each other, then compare that with crunch-time where we were going out for lunch, breaks, and dinner almost daily as a team, and having fun together – I’m happy.
The team isn’t going to be developing Misorderly further. We’re all looking to start our careers at established companies and be mentored within the industry. But I’m grateful for the time we’ve spent together – albeit relieved that the project’s finally done. I think the greatest thing I’ve learnt from this is that culture is of utmost importance to me, more so than the title I’m working on.
So for any future VFS students reading this, let me offer this piece of advice when it comes to team forming. Choose communication and interpersonal skills over technical skills. It’s easy to watch a YouTube tutorial on how to unwrap UVs in Maya. It’s much harder to reconcile personality differences and to try to make people get along. These are people you’re going to be working alongside for five months. You don’t want to hate them. But most of all, remember that final project and pitch n’ play aren’t the be-all-end-all of your career. You’re going to make mistakes. Embrace that. Be open to being proven wrong and learn as much as you possibly can. We’re making games. Might as well have fun while we’re at it.
(For context, Misorderly can be played or downloaded through links in my portfolio.)