Over the last week, I’ve technically had to prepare for two releases, and guess what? Both games are out, and I’ve updated the game menu to include links to them! It’s pretty cool how both games were originally made at 48 hour game jams, and both are being updated as we speak. Feel free to read on about my experiences with Global Games Jam this year, and try out these two releases as soon as possible, all feedback is awesome!
So last Friday (23rd) was the third time I have participated in Global Games Jam, a massive international on-site games jam that has thousands upon thousands of participants at sites around the world. For the third time, I was at the Staffordshire University site. Not only is it my University, but it’s also holds the record of the largest GGJ site in Europe for the last two years, and this year was the fourth largest GGJ site in the world! The University has since done a small report with interviews from the participants and organisers, if you want to know more about the site.
Last year had a few issues with developing the game, which ended up producing an unfinished game. I planned to learn from that and hope to finish a proper game this time around, and I feel that the team succeeded. So here’s what I learned and how our team was able to overcome those issues.
Using the Right Tools
Last year we used Unity, which is a really good multiplatform 3D games engine, however most of the team had little experience with it. This meant that we were pretty much learning as we went, which isn’t the best course of action if you only have 48 hours to make something.
This year, we used Unreal Engine 4, another really good multiplatform 3D games engine. This time, everyone on the team had been using Unreal Engine 4 from other modules, so we had pretty good knowledge of what we were using, giving us more time to focus on the game. We were even able to learn new things about Unreal Engine 4 while we worked, so it was a win-win!
One of the gripes about some of the GGJ sites is that you are required to be on fixed team sizes, if you weren’t on a team you were randomly assigned to one. This made last year a nightmare, since a lot of teams scrambled to get people they know, and we ended up with seven people, including two artists and a designer. Having too large a team can be troublesome as you assign work for people, and if some people in the team have very little to do, their motivation drops, which was what ended up happening.
While the same restrictions applied, we ended up with some misfortune of two team members not turning up, dropping our team size to five. Despite the set back, it ended up benefiting us, as we now had three programmers, one artist and one audio person, which is much more manageable.
This year, we made it our priority to get a basic game working before we started adding as much content as we could. Therefore we were able to get a basic tower defence prototype built by the end of the first night, giving us a whole day to fix up and add on more stuff to it. This is what eventually lead to us making a near complete game, where as last year was more focused on design and content, meaning we left gameplay to the last minute.
Meaning we were able to pull off this!
So here’s to next year!