This is the second in a series where I document and reflect on my experience building my knowledge in game development, and writing through the process. Think of it as a bit of a diary — entertainment for the learned, therapy for the learning.
I’ve just released my third game, Wendell’s Extreme Feeding Contest. What’s special about this one is that it was my first collaboration.
I’m going to walk you through the process of two newbie game devs’ attempt at project management. I am doing this to reveal to myself which of our tactics worked and what didn’t (and why), but also as a reminder of some things to remember next time I am working in a team.
Up until this point, I was a lone wolf, out on my own on a deserted island (my room) with nothing but StackOverflow and Unity docs to keep me company.
A friend and I had been toying with the idea of collaborating on a game for a while now. We wanted a fresh new game on our portfolios to prepare for GDC 2020.
Well, GDC did not happen. But we decided to still give the personal game jam a shot! Here’s how it transpired:
After a pretty hilarious/stressful brainstorming session, we came to a mutually satisfying agreement on a theme for our game. We settled on: “Vampire blood-drinking contest”
We took a few precautions to make sure we were on the same page. We gave ourselves the task of drawing exactly (or a close representation of) what we envisioned this game to look like. I thought this was a good method to hash out any underlying misunderstandings in what we wanted this game to be.
For both humor and educational purposes I will post these important early-stage visualizations here:
I think it’s safe to say, we could pretty much read each other’s minds. Jokes aside, this sparked a discussion on the key mechanics of our game, as well as how this would be broken down into manageable tasks.
My partner had the idea of organizing our project tasks using an online tool called Trello. We could now see the full scope of our project (or at least what we could make of it at the time), and could easily prioritize the wants vs. needs of our game to be a (personal) success.
So now that we know what needs to be done, who the heck is gonna do it? Well, there’s two of us: me, and my partner — which means we have two options. That’s more than enough, right?
As we discussed what areas of game development we excel at, and what areas we will need support in we came to a daunting realization:
We had the exact same skill set.
Alright, no problem. No sweat. We’re both programmers, neither of us are artists, we know not about animation, nor sound design. Welp, it was time to hit the books then. This would throw at least a baby wrench (the plastic kind) in our project timeline, but surely not an adult wrench, because we had a secret weapon, say it with me:
Free. Assets. Online.
Well, that secret weapon turned out to be of little use due to our extremely specific theme and mechanics. We needed consistent character design, a themed visualization of gameplay prompts and progress indicators, and to top it off, our budget was 0 dollars (maximum).
My partner decided to take a deep dive into learning pixel art, while I took care of the intro “cinematics” (strong word).
This set us back quite a bit, and led to multiple nights of frustration, agony, and stalling on my part (my partner seemed fine throughout this entire process, kudos to that guy).
By the 7th night (the night of our original deadline), we took a step back to look at our progress.
The good news: We had all of the crucial mechanics in the game, ready to be performed gracefully. The intro cinematics (I’ve gained confidence over these last few sentences so no more quotes around that word) were done and gave the user sufficient context to take the game seriously.
The bad news: Details, details. We hadn’t yet wrapped up the game with some kind of indication of winning or losing, the intro dumped the player right into the gameplay without any warning, and the gameplay scene itself still lacked a cohesive environment to align with the setting the intro had set up, along with a slew of further adjustments needing to be made.
One could call this the “polishing” stage of game development. “The hard part is over, so just clean it up, Kaz, whatcha’ complaining about?”
I believe I began to suffer from what I will call “Last Leg Fatigue”. Sounds like a gnarly disease, but what really happened is I became lazy and hopeless that we could not wrap this up into the pretty bow I envisioned in my drawing shown at the beginning of this article.
This was the most important part of the development process — what I do here will either make or break the game (quite literally). Playing it over and over searching for bugs, fixing those bugs, which in turn created more bugs. It takes a lot of resilience to complete a game. I respect the quality assurance process more and more as I continue on this journey in learning the facets of game dev.
Side Quest: You may be wondering what happened to our Trello board. It’s out there somewhere, unused, collecting dust in the internet’s attic. I suppose when you come upon the final stretch of a team project, you’re communicating more, the list of things to do is constantly being talked over and spammed in the Discord chat, and everyone is hyper-aware that we’re “almost done, just hang in there!”
So here we are. The game is done (for now), we’ve done all of our high fives and back-pats. Now what? Well, the point in me making these micro-games is to learn something new about game dev. Sometimes I facilitate my own learning by choosing specific tasks, sometimes these lessons come in left-field.
Since this post is getting pretty long, I’ll make a numbered list of what I’ve learned about collaborating on a game:
- It’s important that the team is in agreement with the game’s direction. If not, it’s time to have a discussion on where you’re not seeing eye to eye. Perhaps some new ideas will sprout to make the game even better (or perhaps the Trello board will be set on fire out of rage, either way, it’s better to be aware of these things early on).
- If you’re making games with the intention of improving your skills, it’s important to define and not lose sight of your team’s learning goals throughout the development process. I say this because there were instances that I wanted to reuse code from a previous game for certain components, not taking into consideration that my partner wanted to learn how to write this code himself, or that maybe, just maybe, there’s a better way to go about implementing the systems we were remaking (and this was our chance to do it).
- The usual creative freedom that comes with making a game solo will need to be compromised on to some degree when working in a team. Everyone should be proud of the final product and feel like their contribution meant something.
- Communicate! Towards the end of the project, life obligations began to pop up and take priority for a time. I think one thing my partner and I did a good job of is being clear and honest about how much time we can allocate to working on the project. There were little surprises, and no confusion or resentment because we had these types of discussions early on.
Before completing this game, I was afraid to work on a team. I didn’t want to slow anyone down or prove to myself that my skills were of insignificant use. I hope this is helpful to someone who might be currently feeling the same way, it’s really not scary at all as long as you are in a supportive, motivated team and actively contributing to that mindset.
Thank you for reading this far, you can find me by visiting kazmuir.com. If you have anything to add to this topic please comment below. (I won’t make the same joke as last time, I’ll just leave it at that).