What I Learned From Doing A Game Jam Every Month For A Year

By Theo Clarke [03.30.21]

In late 2017, I graduated with an MA in Games Design and started working in QA at a small mobile developer based in Northern England. 2019 was only my 2nd full year working in the games industry, and as a relatively-recent graduate and entrant to the industry, I felt I had settled in pretty well as 2020 approached... but I was still gripped by a desire to challenge myself to learn and absorb as much as I could about game development.

While working full-time as a newbie in the industry, pursuing large-scale personal projects in my spare time was proving difficult. However, I had been able to enter a handful of game jams and had found them to be both enjoyable and educational, while also being manageable in terms of my limited time and energy. And so, I decided I would challenge myself to complete at least 1 game jam per month, every month, for the whole of 2020...

This post is a detailed retrospective on my 1-jam-per-month challenge. I will describe some of the lessons I learned and how you can apply it to your own jamming and broader game development. I used two game engines to make my games: Construct (a 2D HTML-based engine) and Unreal Engine 4 (an industry-standard 3D engine), both of which use visual scripting. All of my games are playable either on PC or in a web browser, with many of them being playable on mobile devices too. I have interspersed this post with screenshots of my games, and you can see more images and information and play my games on my itch.io profile.

I hope this post will enable me to make better sense of what I learned, while also helping current jammers get more from their jams, and encourage those who have not entered a game jam to give it a try. Without further ado, here is what I learned from doing one game jam every month for a year...

Time constraints are a powerful motivator...

One of the defining features of game jams is, of course, that they are time-limited. The jams I entered in 2020 ranged from as short as 3 hours to as long as 14 days. The benefit of having a deadline to work towards became very apparent to me as the year progressed.

With an open-ended project, its very easy to procrastinate or allow the project to stagnate. With a game jam, you are given a set time and a concrete goal to work towards. Keeping this in mind naturally motivates one to keep things moving, plan out your time and ensure tasks are getting completed at a decent rate. My game Polar Night (pictured below, created in Construct engine in 4 hours for Trijam #60 in March) was surely one of the less polished games I created. I could have spent much more time improving and tinkering, but I wrapped it up, learned from it, and moved on.

Polar Night, created in Construct engine in 4 hours for Trijam #60 in March

Time-limiting your projects can also help to keep scope-creep at bay and stop the project from becoming endless. For developers who normally struggle with this in their projects, the time-limited nature of game jams can be very helpful. This can also be applied to game development at large; try setting yourself concrete deadlines, even when not game jamming, and see if this helps you get things done more quickly and effectively and learn how and when to wrap a project up.

Doing lots of small projects can be more worthwhile than one big one...

As I mentioned previously, 2019 was only my 2nd full year of working full-time in the games industry. As such, after spending my days settling in and learning the ways of the industry, I had found it difficult to motivate myself or find time to pursue large-scale drawn-out personal projects in the evenings and weekends. Many game developers will encounter this dilemma at some point. In my experience, the perfect solution to this is to do small and short projects - such as game jams.

Clearing your diary for a weekend for a 48 hour game jam can be a lot easier than finding the same amount of hours throughout a week or month to complete a larger-scale project. By entering game jams, you may also find yourself pursuing much more varied projects than if you only did 1 project. Jams generally have a theme and sometimes have other additional challenges or constraints within them, which can really force you to think outside the box. You may learn more diverse skills, explore more interesting topics and stimulate and exercise your creativity better through game jams and other small-scale projects than one large one.

The Potion Commotion, created in Construct in 48 hours for Spooky 2D Jam 2020 in October

Your perception of your own skill-set might not be correct...

I went into this challenge with a certain perception of my own skill-set, which I gradually came to realise was not completely accurate. I believed that my greatest strengths laid in idea generation, designing fun and engaging gameplay and creating 3D art, with my weaker skills being 2D art and implementing gameplay through visual scripting.

I expected these strengths and weaknesses to show through in the games I made, but I soon realised my own understanding of my skill-set was not entirely accurate. The only area where my skills did live up to my own expectations was my 3D art; I created some 3D art that I was very proud of, such as these assets I made for the game Handy Jobs (pictured below, made in Unreal Engine in 48 hours for Global Game Jam 2020 in January). However, I sometimes struggled in the early idea-generation stages; I compared my own game design to that of other jam entries and realised my own gameplay was often less enjoyable; I compared my game concepts to other games and found my own concepts lacking. In short, certain elements of my games were not standing out as I expected they would, as I had overestimated my skills in these areas.

3D assets I created for Handy Jobs, made in Unreal Engine in 48 hours for Global Game Jam 2020 in January

Conversely, I was pleasantly surprised to find myself exceeding my expectations in other areas, such as 2D art and gameplay implementation. I found myself creating 2D art quicker and better than I thought I could, and I was implementing gameplay and solving bugs with surprising ease. I was particularly happy with the quality and quantity of 2D art that I made for my game Deck 'Em (pictured below, created in Construct engine in 48 hours for Chip 'N' Jam in May).

Deck 'Em, created in Construct engine in 48 hours for Chip 'N' Jam in May

I also impressed myself with the quality of gameplay that I created for my game Ice Man's Journey (pictured below, created in Unreal Engine in 5 days for the 2020 Unreal Spring Jam in June). I now have a better estimation of my own skills, which will allow me to use my skills better and prioritise what to work on. I encourage other game developers to challenge themselves often, through game jams or other projects, so they know where their own strengths and weaknesses lie.

Ice Man's Journey, created in Unreal Engine in 5 days for the 2020 Unreal Spring Jam in June


Imposter syndrome CAN be quelled... but it can easily sneak back...

Like many of my fellow creatives and game developers, I am no stranger to "imposter syndrome". During this challenge I realised that imposter syndrome gets worse for me the longer I go without creating something. In the hours and days after finishing a jam, I had a great sense of validation and legitimacy, and my imposter syndrome felt like it was in-check... however, that feeling would slowly fade and the imposter syndrome would creep back. And so, I found myself yearning to enter my next jam and to create something to fend it off.

This experience has taught me that completing a project, even something as small as a 3-hour game jam, can really help. One of my games, Soarin' Squirrel (pictured below, created in Construct engine in 3 hours for Trijam #83 in August), was a shameless Flappy Bird clone. It was incredibly small and simple, but I still felt accomplished and legitimised as a game developer after making it.

Soarin' Squirrel, created in Construct engine in 3 hours for Trijam #83 in August

I also noticed that other jammers often have similar struggles, weaknesses and failures. This helped me accept my own weaknesses. If you suffer from imposter syndrome, I can highly recommend taking part in a game jam. Exercising your creativity by making something - even something really small - and realising that others have struggles and weaknesses, can be very beneficial to your own self-confidence.

Its not always easy to follow your own advice...

Anyone who has ever been involved in a game jam will probably know that there is a loose set of best-practice advice that its a good idea to follow. Things such as "make sure you get plenty of sleep while jamming", "design your game on paper before you begin developing it", "try and keep things simple so you don't burn out", and "use software and tools that you're already experienced and comfortable with". This is all advice that I would give to any first-time jammer, but I noticed pretty quickly that its very easy to forget this and slip into ineffective or even unhealthy practices.

In November 2020, I acted as an industry mentor for a team of game design students as part of the Ukie Students Game Jam. I advised them to keep things simple, get enough sleep, and stick to what they know. But on several occasions throughout my 1-jam-per-month challenge, I found myself stumbling into bed at 6am with a headache and aching wrists from sitting at a mouse and keyboard for hours, knowing that I would need to be awake to do it all again in a few hours. I took on too much work and ended up having to cut things or change my plan half way through.

I must admit that by pushing myself to work harder than I really should, I did achieve a lot and made some great games that I was very proud of - but I didn't always do it in a very healthy way. An example of this is my game Scrap City Scoops (pictured below, created in Construct engine in 14 days for Gamedev.js Jam 2020 in April), which was incredibly ambitious and one of the best games I made all year - but it was a very long and arduous jam which I had to fit around my job and it really took a toll on me. Going forwards, I will try harder to follow my own advice and hold myself to higher standards of self-care, and I believe other game developers should endeavour to do the same.

Scrap City Scoops, created in Construct engine in 14 days for Gamedev.js Jam 2020 in April

Sharing your work is essential for validation...

Throughout 2020, I kept track of my progress via a Twitter thread, as well as sharing screenshots and links to my games with family members, my girlfriend and fellow jammers on Discord and itch.io. This became essential to achieving a sense of validation, completion and accomplishment for each jam I entered. I shared my game Lazy Santa (pictured below, created in Construct engine in 48 hours for Yogscast Game Jam in December) with some family members, who gave it a try and let me know what they thought and how far they got, which gave me useful insight into the game's playability and difficulty level.

Lazy Santa, created in Construct engine in 48 hours for Yogscast Game Jam in December

Even if you don't think your work is great, even if its something super simple made in a couple of hours, even if you are just starting out and your work is not to the same standard as your peers - don't keep your work to yourself! Set up some social media pages, create a blog or a portfolio website, or join game art sites such as Artstation or SketchFab - whatever method you choose, its important to show off your work. You don't even have to make detailed posts or have a big following. Keeping it short and simple is fine - sharing your work should primarily be for your own benefit.

The many benefits from sharing your work publicly include: gaining a sense of achievement, validation and closure by sharing a finished project; having a record of your progress over time to look back on; receiving useful feedback from peers; feeling a greater sense of motivation to finish something or create something shareable. Indeed, as well as hoping to share my knowledge with other game developers, a major reason for me making this blog post is to gain a sense of closure and make sense of my own experiences.

Game development (especially game jams) should be fun and feel fulfilling...

This is perhaps one of the most important lessons I learned, and one that I would really encourage other game jammers and developers to take away. Though I really enjoyed this challenge for the most part, there was a few moments where I had simply given myself too much work, or a longer jam was really stretching on and felt endless, or I scrapped an idea after hours of work or even abandoned a jam entirely. Game development and jams can be very fun, but can also be exhausting, frustrating or disheartening. It is important to strike a balance.

It's fine to work hard if you are gaining something from it - such as fulfillment, pride or knowledge - but you should not force yourself to continue a jam or project if you are not getting any enjoyment or benefit from it. If you find yourself wishing to stop or gaining no fulfillment, rest assured that it is fine to abandon a project and move on, because above-all, game development and jams should be fun.

In Conclusion...

Before beginning this challenge, I already felt that jamming was one of the most rewarding and worthwhile activities a game developer could participate in - no matter their skill level. After completing this challenge, I am now absolutely convinced of this, and I strongly encourage game developers to join more game jams or take on the 1-jam-a-month challenge themselves - regardless of whether they are students, amateurs, hobbyists, or established professionals with years of experience.

Thanks for reading my first Gamasutra blog, feel free to check out my work or connect with me on the following platforms:

Play my games on itch.io: theoclarke.itch.io

My portfolio: theoclarkeart.weebly.com

Twitter: twitter.com/theoclarke4L

Artstation: artstation.com/theoclarke

Sketchfab: sketchfab.com/TheoClarke

LinkedIn: linkedin.com/in/theo-clarke

Return to the web version of this article
Copyright © UBM TechWeb