Game development as a hobby is a difficult pastime. It is a constantly moving industry with a million different specialties that you may never end up having any experience with, even if you dedicate your life to the craft. You can put yourself through months of challenging work just to come out with an end product that if you’re lucky maybe a dozen people will play. It really is an industry for the love of the game, no pun intended. It can be isolating and relentless, yet I absolutely adore it. It’s the ultimate creative exercise that requires you to wear many different hats. No shortage of challenges. A puzzle with many solutions.
This past week I got to knock off a lifetime goal of competing in a game jam. Ludum Dare even. One of the largest game jams in the world.
For those not familiar with the event, let me give you the cliff notes version of it. A game jam is a communal event where people from across the globe work to create video games from the ground up in an extremely short amount of time to test their skills and get feedback from a panel, or in this case, their peers. These games are made to fit a set theme which is revealed at the very first moments of the event. In the case of Ludum Dare, there are three versions of this jam – the “compo”, which is a 48 hour solo jam with strict rules; the “jam”, which is their traditional 72 hour jam which can be done solo or in groups; or the “extra”, which is a newly added version with a three week time frame for those who can’t dedicate an entire weekend. As a very beginner level entrant, I went with the recommended 72 hour version as the new “extra” category means you do not get the same quality feedback as the others since it extends to the end of the voting period.
In game design, everything tends to have long timeframes and because of that lengthy projects often end up abandoned and less experimental since we tend to put more effort into the creation of ideas that are safer. Game jams lean towards a more abstract approach of game design as creators try out new ideas or technology and it forces them to keep features minimal, which we refer to as a small scope project. Game jams force the participants to figure out what is important and trim every imaginable piece of fat from the meat. Innovation comes out of necessity.
I went in to the jam with the intention of just having a solid attempt at creating anything. I started six weeks before the jam with a weekly plan to get myself reacquainted with the software I would need as I had been out of practice for around half of a year. This plan was uprooted in so many ways and by the time the start date hit I was not very prepared. For this game jam, I would mostly be winging it. In the case of Ludum Dare 54, the theme was “limited space.” This seemed like a great theme for my first attempt at surviving a game jam. With a theme like “limited space” there would be a ton of options and angles to attack it from to come up with an idea that was original enough to hopefully not be covered by someone else’s entry.
I spent the first hour brainstorming on small ideas that I thought I would be able to handle. The goal was to come up with a game concept that was extremely simple and small and then use any extra time I had to add on new features in modules. I had done my research and read many recommendations that modular design is a great way to survive game jams. It sets you up for success by increasing the odds that you finish a basic gameplay loop and have a working game to showcase in the end. The more time you have afterwards, the more “modules” you add to the idea, and in theory the more impressive it becomes.
The concept I ended up choosing seemed simple enough in my head. For whatever reason, the first thing that came to mind when I thought of limited space was a crowded subway car. Kind of weird, but felt original enough that not many other people would attempt it. The game idea was a grid based endless game where you must simply exist on a subway as more and more people enter the car. Avoiding all contact with them was the core and I decided to give the player three “lives” or as they were simply referred to as “pardons”. A pardon would be used when the player made contact with any other player on the subway. A comedic version of the ultimate test in social anxiety. Just trying to survive in the world without getting in the way of others. The game was given an awkward art style (unintentionally reminiscent of South Park) and was built around some systems that also did not end up in the final version.
There are probably endless things that I could discuss on how the project evolved, which parts of it worked, which parts of it flopped, the issues I knew at release, the issues I found out about through user feedback – but instead of breaking down every little thing I will try to just talk about what I learned. If anyone ever has a serious interest in this kind of thing beyond what I cover here, I love talking about it and if you have any questions I am always open to discuss any of it directly.
Lets start out by talking about some of the things that went right in this game jam.
#1 – Modular creation is key
The best advice I read before starting this jam was to pick an idea that is incredibly small and then add on to it after the core is complete. I created checklists to do this and ordered them based on what I felt was the most important to the theme and then added more features afterwards when I felt like the base was where it needed to be. For this project, things came together at the last minute. They likely would have fallen apart with how tight the time ended up being if I had put a bunch of work in to unnecessary features earlier on in the weekend.
#2 – Let others create their own opinions
With the last game I had a hard time getting feedback after release and I think mostly that was because I didn’t like the game myself. On release, I was very negative and apologetic about it most places I had shared it and I quickly learned that gives off an impression that you don’t want to hear more negativity. It’s hard enough getting quality feedback to begin with because people think you just want reinforcement of what worked. It’s very challenging to tell other people what needs to be fixed and why things don’t work. By letting people create their own opinions instead of painting it for them, they tend to be more comfortable telling you why they do not like certain aspects.
#3 – Listen to problems, rarely solutions
This rolls in from the last reasoning but a while back I had heard a piece of advice about how in criticism you should always listen to people’s problems but rarely listen to their solutions for them. This interested me because it really seemed backwards, but in practice it all makes sense to me now. The biggest piece of feedback I received on this game from other developers was that the game is too difficult to control. My game featured a control scheme where you used the left and right arrow keys to rotate and used the up button to step forward, a control scheme that in the video game industry is typically referred to as “tank controls.” I am still adamant that the game concept only works when it has clunky controls and a more traditional scheme would have made it not only more generic but also far too easy and responsive. This feedback is still extremely helpful because it lets me know why some people didn’t connect with the game and provided a barrier for them to have an enjoyable experience. Acknowledging this problem down the road is helpful and allows me to reassess these decisions in future games, but listening to the provided solution of just moving the character around in a traditional way I believe would not have made this the better experience they think it would.
#4 – Be ruthless with cutting content
This rule is the absolute hardest one to abide by but you have to be able to cut content that feels important along the way. Another piece of advice I read online before I started this jam was to make a checklist and cut it in half by the end of night one. After night two, reassess the remaining items on the list and cut it in half again. I didn’t follow this advice to the tee, but I did use a version of it and it worked to great success. I had to cut a lot of features that would have made this game stand out more, and it was unfortunate but a necessity. The original pitch had all characters moving rhythmically with unique midi instruments attached to them to make an urban themed cacophony, but this idea was quickly cut as time started ticking away. In fact, this idea was so core to the original pitch that it’s why the game was based on a grid to begin with. The project had to evolve to get finished. Lots of other smaller things like a working seat system and a bunch of different rider types also had to get cut along the way. Aesthetic things like a logo and a main menu also never got completed. Tough decisions had to be made, but without making them the game would not have been finished on time and would currently be sitting in an abandoned folder somewhere.
#5 – Have fun with it
This seems like obvious advice but I had to keep reminding myself when things got tough that I’m just here for the fun of it and if I’m not enjoying what I’m doing it’s simply not worth it. There were moments when this project came very close to having the towel thrown in on it. I’m sure the next section will cover that in more detail, however the times I enjoyed this project the most was when I was just riffing off the top of my head. The voice lines were all improvised, for the art I gave myself one hour to just draw characters for a while and most of them made it in to the game. There is even an extremely rare character that has a one in one thousand chance of replacing any of the non playing characters in the game. Putting in little Easter eggs and just being goofy with it at times helped to keep me sane.
Now for the inverse, here are the some of the lessons I learned.
#1 – When things fall apart, take a mental break
To build off the positive section, on day two this project almost collapsed. I had written a collision system that was just extremely broken. Characters were constantly getting launched out of bounds. Animations were broken and characters were walking through closed doors. I had a bug list that was over a dozen items long and they were all linked to a concept that just wasn’t working. I stepped away without intending to come back. About an hour later, I returned and just started doodling. Once graphics began coming together and I had distracted myself from the problem, I came up with a new solution. Spend the rest of the night just getting all the art in place, getting a minimal amount of sleep, and then returning to the project to add audio and give myself one chance to gut the entire collision system and rewrite it from the ground up. Without this break and subsequent regrouping of the project, it would have been abandoned at around the 48 hour mark. I would say this was a win on this project, but it was so close to a fail that I definitely learned a new lesson that day.
#2 – Get feature ready 24 hours before the goal
You know when this project was due? 5PM on Monday. You know when I finished typing code? 4:59PM on Monday. Not only did I work for probably 18 hours of the final 24, but I took a huge risk and released this game with code that was tested for approximately 10 minutes. The final two hours I spent implementing a major feature that was crucial to the success of the game. Why did I wait this long to code the feature if it was so important? Because of the issues discussed in the previous point. Everything snowballs and I learned that I cannot leave important features that long in to the process. Get everything essential done early on. It helps you polish and seek out bug fixes in the final hours.
#3 – Get the full package together early on
Nothing will keep you less motivated than staring at prototype graphics for the majority of the project. Having nice looking visuals and audio makes the goal feel more achievable. It’s easy to leave these features until the end because they don’t always feel like the priority, but really they are a big part of what makes the game unique. Real graphics always line up better than prototype squares and circles anyway. Just get it done and commit. You need to eventually anyway.
#4 – Have a few testers on standby and involved as early as possible
To build on the last two points, getting a build done earlier helps to get it in peoples hands sooner so you can get in feedback that you can use to fix the problems. If you wait too long to get feedback, there isn’t enough time to implement all the fixes and upgrades that will make your game stand out. While I was able to fix a number of bugs in this game due to the hard work of friends, it could have been so much more if I had gotten to that final draft portion much earlier. No one besides me laid hands on my game until the final 24 hours and it should have been maybe a day sooner.
#5 – Comment. Your. Code.
Most people are smarter than me on this one but I am absolutely terrible at commenting my own code. Spending an extra 15 seconds to just add in a little comment about what a line of code does will save you so much time in the later stages – especially in the case of a jam where I was having to take some unconventional approaches to make sure things worked. There wasn’t always time for the cleanest of code and I would probably be embarrassed to show my raw code on this project to anyone that knew what it meant. My code for this project contains zero comments. It’s a really bad habit and I’m going to work on kicking it.
In the end, I was not overly proud of the end product but I do think this is the best thing I have ever created. As long as I’m improving a little bit each time, I am happy. The fact that this game functions better than my last game release and was made in the smallest fraction of time is impressive. I am extremely content with how this experience went and I feel like I tested myself and passed. I still do not feel like I know very much, but that’s alright. Learning a bit with each release is a step in the right direction. I’m not sure if I’ll ever get over the impostor syndrome of feeling like I do not belong when I’m surrounded by people who have done this work for years, decades, or an entire lifetime, but really projects like this aren’t about comparing yourself to others, they’re about creating something unique to you to the best of your ability. In those regards, I call this a success.
The next part of the jam is still ongoing but following the release of the game you are volunteering yourself to rate the games created by others. In the case of this Ludum Dare, there were over 2000 entries and tons of games to play. They’re made by people of all skill levels and talents. For each game you rate, the algorithm helps to push your game out to more people. In short, for each thing you review, in theory, someone else will review yours. The goal is to rate somewhere between 20-50 different games over the course of the three weeks following the jam and provide feedback and others will do it to you in return. It’s a complex system that works surprisingly well. Games are ranked on a 5 star scale in a variety of categories and at the end of the jam all games that have twenty or more reviews are given scores and rankings. While all the entries are available for free to the public, only other participants are eligible to rate games.
I took the time to play as many games as I could and have already received enough ratings to be eligible for scores in the coming weeks. While I do not particularly care about the rankings, I am interested to see where the numbers come out for specific categories to get an idea on where I can improve in terms of my creations. I have already been reading the comments left on my game and they have provided valuable insight in to what issues people see the most. Even though a lot of the issues I had known about previously, the frequency at which people mentioned certain ones is helping me see what problems are mattering most to the user. Some of my biggest gripes with the game have not been mentioned in a single comment thus far which is why feedback is so important. I spent so much time on a fundamental level with this game that some of the problems I see, especially since I created them, bother me while no one else even notices them.
If you’ve read through this and you are an aspiring game creator and you are wondering if you should try doing a jam I would personally say go for it. Even if you don’t succeed, you’ll learn a lot about the process and yourself along the way. If the time span seems much too short, there are literally hundreds of game jams out there every single month all with very different time tables. You can easily submit your game to a small group of people instead of putting yourself out there in front of 2000+ teams. I have also heard good things about the Global Game Jam which is the world’s largest jam and is created to put you in to a team and make games with others. This jam encourages people with zero experience to apply and the idea for newcomers is for them be teamed up with people much more experienced in a mentor type role.
At the end of 72 hours, I felt like I had gone through a war. I was exhausted and passed out within hours. It was one of the hardest things I’ve ever done and I want to do it again. I don’t know if I’ll participate in the next Ludum Dare or if I’ll choose something completely different, but I would like to keep doing these and trying to find out more about my design style along the way. In the meantime, I am going to spend the rest of the year trying out some new engines (starting with Godot) and fleshing out some of the ideas I have for my next larger scale project. I came out of this game jam feeling rejuvenated and chomping at the bit to create again which is more than I can say about last time I finished a project and came out the other end feeling nothing but defeat.
When I started doing game development as a hobby, my two goals were to release a game and to compete in a game jam. Now that both of these have been accomplished, I have decided to keep continuing this journey with two new goals in mind. The first goal is to create something I’m proud of. I want to make something that really connects with me and that I feel more comfortable sharing with others. I do think I’m already getting close to accomplishing this. The second goal is I want to get confident enough in my programming that I can work in a team with others. I know that art is my single biggest weakness at the current moment and I hope someday I can get paired up with an artist because nothing hides the programming flaws better than a nice art direction.
As the journey continues, I’ll keep writing these blog posts. They’re a nice bow tied on top of a completed goal and help me to sum up what I went through to get to this point. Thanks for reading these and joining me along the way.
braktheman 
One thought on “Lessons in Game Jamming”