I recently completed my third game jam of the last twelve months. It was quite the realization that in less than a year my jam entries have gone from a solo GameMaker Studio menu-based game, to a solo 3D Unity dungeon crawler, and now to an 8-person-collab arcade survival Unity project. As much as I try to push myself every day, I always find I learn more in the compressed hours of game jams than in the month or two separating them.
This jam in particular provided exactly the kind of insight into development nearly impossible to reproduce outside of a professional setting, and for that reason I continue to find game jams invaluable to my growth as a developer, designer, and in this case Unity-logistician/technical-director. I’m proud of myself, our team, and the game produced, and I hope this postmortem illustrates why.
As the most experienced Unity developer on the team I was looking forward to my first truly collaborative Unity experience. I’m a fervent user of version control in all my projects, especially when using Unity, and this was poised to be my first dive into the VCS nuances team-developed Unity projects come with. Many developers I’ve spoken to at meetups had many warnings I had gratefully noted, and their advised team workflows for Unity collaboration were strategies I’d hoped to put to the test.
But this did not happen.
Due to the mixed experience levels with Git and SourceTree within the group our production quickly came to a halt. Ultimately the call was made, after much debate, to establish an alternative means of approaching the project’s backups and collaboration.
I swallowed my fear, and agreed. Pre-production had gone like a dream, a well facilitated discussion and exploration of concepts all the way up to the design meant the art team hit the ground running. We were approximately 4 hours into our total of 48, and the technical side had already hit a roadblock.
The Takeaway: if you’re going to use a version control system to collaborate, ensure every member expected to use version control not only understands the VCS but can effectively put that understanding into action. Much like games, it’s one thing to understand and another thing to actualize your understanding.
Plug and Play
Development was just a matter of effectively dividing up the technical systems of UI, Audio, Sprites/Animation, to be developed and later fitted into the main project containing the game logic and moment-to-moment action. Then, a specialized Menu scene could be developed in an environment separate from the rest of the project. It was never a divide-and-conquer affair, as long as we didn’t have version control I wanted to be as sure as possible we were using everything else at our disposal to the fullest. Trello boards were filled, Discord channels created, and meeting/eating times set and adhered to. We asked each other important questions with regard to how everyone’s tasks were going during standing meetings, and corroborated how well we met each others expectations for the eventual coalescing of systems.
I’m happy to say that everyone walked away a fan of Unity singletons.
No good Postmortem is over without a good horror story! You probably guessed it, but yes it has everything to do with version control.
One of the compromises made was to keep the main build on a USB during transfer between workstations. I fully understood the risks, potential disasters, and headaches that would come from this. Keeping that in mind, when things finally did blow up we managed to keep a levelheadedness and quickly solved the problem.
One of our teammates had to step away for a few hours during the final 12 hours of the jam for a sports practice, and as such left his computer for us to watch. We saved the working build on his PC and transported it via USB to our new central workstation.
When trying to copy the build over we discovered the USB was corrupted. Despite our militant “safely remove all hardware” rules we’d come across a hardware failure. No biggie, this experience comes with the no-VCS territory. Just reformat the USB and try again right?
That’s when we realized we were locked out of the missing teammate’s computer.
There was the chance for disaster, but rather than panic we simply followed through with every means of relieving the problem. Every messaging app, every means of establishing communication, all were tried. We were prepared to introduce ourselves to his Facebook friends in the hope of obtaining his number. During all this, I was mentally prepared to simply re-do the last few hours of work. I expected something like this to happen given the circumstances, and was frankly surprised we’d made it this far.
Ultimately we reached him and obtained access to the laptop, but again: use version control, use version control, USE VERSION CONTROL.
I didn’t need another lesson in this fact, but another scary developer campfire story has been added to my repertoire.
Modular Design Saves the Day (As it Always Does)
I adore the elegance of modular design, both in the technical organization of a project and in the design of gameplay systems. I’ve been obsessively modular-izing my Unity projects since my last game jam, PTBO Game Jam 02, after realizing how effective production could be when truly playing to Unity’s strengths: components and prefabs.
I speak, of course, of having specialized components as opposed to ambiguous, broad components which require intimate knowledge of their logic in order to modify game behaviors. Many YouTube tutorials, regardless of the engine used, are notorious for the brutal, time-consuming practice of improperly planning code. I break everything up into meaningful slices, and the key is balance. Games are fun because of interesting interactions. If you can’t isolate the aspects of those interactions in code, logic, and design before production then, speaking from experience, you’ll quickly find yourself digging through code you wish you’d written differently.
Turns out this approach is essential for effective group work in Unity, as I’d anticipated.
To my amazement our team had so effectively scoped, cut features, made healthy compromises for the sake of enjoyable gameplay that we had time for extensive playtesting and tweaking at the end of the jam! I was so proud of the team, and so relieved we had a functional project, let alone a game we’d be able to polish to make it shine just a bit brighter.
In conclusion, making the most of what you have and actualizing your determination to succeed definitely makes game jam projects more likely to wrap up well. However, having something like version control firmly established in everyone’s toolbox rather than a select few is more than vital to the group’s development success.