Molyjam 2013: Observations From a First-Timer
Last weekend I attended Molyjam, a game jam event hosted by Uken Games in Toronto. A game jam is an event where people volunteer to work on a game for a weekend and see what they can make by the end of the weekend. For me, the end result was Lost Dog, a 4-player marco-polo experience where you are trying to find your lost dog before a coyote finds it first (Play in Browser). The game was made over the weekend with contributions from myself, Aaron Bernstein, Katherine Mackay, Edith Chow, and Ryan Roth. This was my first game jam event and this post details my observations about it.
Things that I loved about Molyjam:
- It encouraged creativity. The theme of the game jam was to make a game inspired by a quote from Peter Molyneux. This resulted in a lot of really cool games because people were free to fail. Their projects did not have to be a commercial success or even make much sense. This allows for some pretty great innovation and experimentation. A recent game jam commercial success story is Surgeon Simulator 2013, which was developed in 48 hours at the 2013 Global Game Jam.
- It was a great opportunity to meet people. I went to Molyjam solo and met incredibly talented people. One of the things that I really liked about the people there was that everyone was so passionate about making games. After all, most people would not spend an entire weekend voluntarily making games in a high pressure environment. There was also a large diversity of people in attendance: from hobbyists to professionals, and from game jam veterans to first-timers. This is a great culture of intelligent competent people and I am glad to have the opportunity to take part in it.
- It was a great way to release a playable game in a very short period of time. Most people (hobbyists especially) do not actually end up completing the games that they start. Largely due to losing momentum as life and other projects typically get in the way. By limiting the time available, there is a consistent sense of accomplishment to maintain momentum. That being said, the risk of failure is also high due to the lack of time. That risk can be mitigated by being flexible with your final deliverable. For example, when we were running out of time, we decided to cut content to ensure that we had something playable by the deadline.
- It was a phenomenal learning experience. By immersing myself in game development, I was able to learn a significant amount in a brief period of time. I made it a goal prior to attending that I wanted to learn Unity and C#. After attending I can safely say that I know significantly more than I did prior to the game jam.
Tips for attendees of future game jams:
- Avoid complicated collaboration support systems such as Git or Mercurial. The whole purpose of collaborating on a project is to be able to get more accomplished in a shorter amount of time. However, time spent working on collaborating more efficiently is effectively time spent not getting anything accomplished. I’m not saying that these tools have no place in a collaboration project. What I am saying is that every hour needs to be fully utilized when you have less than 48 hours to work. We completely wasted at least 3 hours trying unsuccessfully to get Git to work properly. That time could have been much better spent.
- Make an internal deadline so that you have sufficient time for Quality Assurance (“QA”). You will need to use your professional judgment in order to define “sufficient time” based on the complexity of your game. We did not budget sufficient time for QA and as such we found ourselves making fixes and squashing bugs right down to the deadline. Furthermore, bugs made it in to the final game that could have easily been caught and fixed had we budgeted sufficient time for QA.
- If you are planning on being a floater to work on multiple projects, contribute art or music skills. It is near impossible to be an effective programming or game design floater due to the complexities surrounding code integration. It is very difficult to silo off sections of code and have them work properly. In a time sensitive environment, it can be more work to bring on another programmer and get them up to speed than to simply continue without them.
- If you are coming to a game jam as a programmer, ensure you have sufficient programming skill to complete a game on your own in the event that finding a team does not work out. This advice is a result of observing some groups disband due to either a lack of game design ideas, incompatible skills, or inconsistent end-game visions. Always have a backup plan that you can implement solo. My backup plan was to make a game entirely in Microsoft Excel, simply because that was what I was most comfortable with, making it possible to build a playable game quickly.
Feedback for the organizers to improve future game jam events:
- There should have been scheduled time after the showcase to walk around, play games, and meet the developers. I was very impressed with many of the games shown, notably Optophobia (a game where the player must close their eyes and make leaps of faith in order to progress). It was unfortunate that I ended up having to play them at home after the event, rather than with the developers of the game at the event. This was a missed opportunity for social interaction between developers who were not on the same team.
This summarizes my experience as a first-time attendee at Molyjam. I very much enjoyed it and I look forward to attending more game jams in the future. However I’m sure that given the diversity of people in attendance, there are a lot of different experiences. If you had a similar or different experience feel free to let me know in the comments, on Twitter, or by e-mail.