Recently I joined PirateSoftware's 16th Game Jam with a friend of mine. Little did I know how great of a learning opportunity this was going to be. Not only was it a lot of fun, but it forced collaborative problem solving which was crucial to the game's development, and my personal learning as a software engineer.
👾 Starting the Jam
One of the most difficult parts of any project is starting. It's the largest the task will ever seem and you have no momentum built up to move forward. Before the game jam I was stumbling on various project ideas to implement, not thinking any of them were worth bringing to life. When my friend suggested the upcoming PirateSoftware Game Jam we signed up right away and started a small project to work on to understand each other's work flow and strengths.
The advantage of this setting is it gives you a structured start to your project, and forces you to start. You get a theme (this jam's was 'You Are the Weapon') and a timeline. From there you have to figure out what to make, how to make it, and how to publish it all within the given time frame. Sure when there's thousands of entries the odds of winning or being recognized are small, but that's not the point! The amount of things I learned went well beyond my expectations and helped spark more creativity in me.
The importance here is understanding that no matter what you're going to work on, you just have to start. The whole process will be a great learning opportunity and help you stay on your toes. Even if the final outcome is nothing but another personal project that doesn't see the light of day, you're still ahead of where you were before you started. Once you have momentum it becomes much easier to think of new and better ideas!
🤝 Collaborative Projects
Unlike personal projects, the game jam experience allows you to exercise you ability to work in a team, forcing better organization and constant communication. It becomes more important to document what tasks you're going to work on and what solutions you plan on implementing. It means sometimes dealing with merge conflicts (which I found can be extra fun in Unity) and integrating the team's solutions, or adapting to changing priorities and switching gears.
On top of just the teamwork and collaboration benefits, there are probably many things the people you are working with know that you don't. In my case there is tons I learned from my partner:
- I've never done any pixel art before, here I created half of the assets in Aseprite
- I've never done any SFX or music before, but now I've added some of my own sounds that bring the game to life
- Most notably, and in general, I learned a lot more about why and how OOP and event-driven design patterns are implemented on a larger scale and got to see first hand how this affects the scalability and maintainability of the game
📈 Reflection, Results, and Summary
After a final night of coding and getting some sleep, reflecting on the jam was really great to see what we could have done better. It became obvious how important taking breaks is, especially when trying to debug. By having a fresh mind, I was able to quickly fix a large bug that I had previously spent over an hour trying to rush to find a solution for. Additionally, it was much easier to refactor and take advantage of/understand proper programming practices, which this alone assisted in clearing out bugs that had formed from the quick disorganization that occurred.
Although we may have submitted a game with lots of bugs and didn't win, I am excited for the next game jam where I can implement everything I learned and can continue to build on my knowledge. Maybe using a more Unity friendly version control tool, or focusing on keep the scope of the game more manageable. If you are interested in the official submission you can play it here. After the submission I decided to fix the major bugs in the game to create a more playable test, which you can find here.
Happy to answer questions and hope to see you in the next jam!