Chillennium Post Mortem

Written by Ryan Kubik

Introduction

Chillennium 2016 was an event put on by Texas A&M from September 23-25. We were a team of four students representing West Virginia University at the event: Destiny Dunn, Jordan Hallow, Connor Haynes, and Ryan Kubik. This was the first game jam that some of us had ever participated in and the first jam that all of us had done together as a group. You can play our finished game here.

Tools/Tech Used

We used Game Maker: Studio to create this project. We had all recently picked up GM:S in the most recent Humble Bundle and were interested in trying it out. We knew that we were going to go for 2D since that's what Destiny had experience creating. She used a combination of Paint Tool Zai, Photoshop, and her Wacom Intuos Tablet. Because of this we felt GM:S would be a good fit. We especially liked the ability to easily export to most major platforms.

In order to collaborate we elected to use Source Tree as a version control manager. We hosted our repository on Bitbucket. We attempted to use Game Maker’s built in source control technology but couldn’t get it up and running quickly and switched to using Bitbucket. We had a few minor issues with this course of action. We would always get files pulled to our machines appropriately; however, sometimes when a new object (or other asset) was created it needed to be reimported on different machines due to overwriting the game’s configuration file.

Game Idea and Design

The jam theme was “Foofaraw”, a word that means a great deal of fuss or attention given to a minor manner. We had trouble coming up with an idea based on this theme and settled on creating a 2D RPG style game where you explored around the world collecting achievements. Our foofaraw twist was that you received achievements for all manner of silly things, walking 10 steps, turning on a TV, opening a door, etc. This was topped off by a rather absurd celebration of confetti and balloons to accompany each achievement. We hoped that this would work well with the theme and be a fun little game idea that had a reasonable scope.

What Went Right?

A lot of developers seem to want to avoid using tools like Game Maker as they appear to be too simple. For our purposes (especially as relatively inexperienced jammers), a simple game engine was exactly what we needed. We had to spend very little time learning how to use our game engine and got to spend the majority of our time developing and learning how to jam.

We picked a game engine that all of our members were familiar with. This was a great asset as members who needed to sleep (or became ill as it turned out) could go rest or recover without forcing the rest of the team to wait on them.

What Went Wrong?

Even though we thought we knew better, scope was still an issue. We pared down a lot of features but still were implementing new achievements til the very end. We should’ve hit a cut off point and switched to polishing what we already had in the game. I believe that if we had taken the time to nail down a more definitive the minimum viable project very early on we would’ve done better in this regard.

Part of the reason we didn’t have a well defined MVP was that we started with a lackluster idea early on and pivoted to a different idea partway through first day. Didn’t suffer TOO much since we stayed in the same general genre. However, we never stopped to reconsider what our new MVP and goals should be for this different game idea.

A final manifestation of our lack of time to polish the game and do general play testing was a lack of intuitiveness in playing our game. While we were testing all of the achievements, we ran around attacking and interacting with every object, because that’s how we envisioned the game being played to get the achievements. However, watching others play the game a little after submission it became painfully obvious that we never gave players a good reason to even try attacking anything! This made it so that players missed the entire point of our game!

We were using bitbucket for source control which worked wonderfully… until we lost internet connection. In the future we’ll look into a participant hosting the repository locally so that we can avoid being locked out of our project for a few hours. This was particularly stressful as it occurred towards the end of the jam.

Part of our ambiguity in not having a clearly defined MVP resulted in the creation of a lot of art assets that ended up not making it into the final game. If we had clearer asset (art & audio) requirements from the get go, it would’ve been easier for artists to focus on core important assets. Also due to to this situation, audio was a total afterthought. We didn’t have anyone experienced in creating audio assets as part of our team. This meant it fell by the wayside as no one was particularly interested in picking up the audio torch.

Conclusion

It’s hard enough to create an interesting game idea without having to tie into a jam theme word as well. We struggled a lot with creating an interesting game idea from a theme word. Coming up with game ideas is something that we all need to practice more.

Additionally, something that sounds like a good game idea might not necessarily make a good game JAM idea. Scope is something that really needs to be taken into consideration. There needs to be a (smaller than you think) amount of core gameplay that has plenty of time to be polished.

Hopefully, those reading this can learn from some of the mistakes we made when we participated in our first group game jam. We learned a whole lot from doing this jam and are very excited to do more jamming in the future!