Are you considering flying solo for your next game jam, but you're feeling a little nervous? Perhaps you aren't that experienced a coder, or you're just wondering what it's like compared to working with a team?

I'm a narrative designer and game artist who's all about game jams, clocking in at around 20 over the past five years. I've taught game development through jamming, and even wrote my MA thesis on game jams and learning. (You can download it over at ResearchGate if you're curious about my findings)

Over the past week I tried my hand at solodeving a game for the first time for a game jam! The result is Grumpy Librarian, a visual novel / game made in Ren'Py. You can check it out and play it over here if you're curious: https://classheikki.itch.io/grumpy-librarian 
It was made for the Aalto University Games Now! Online Jam 1, and this was also my first time doing a fully-online jam.

So what did I learn from jamming alone, and what are my tips to you? 

Let's get to it - Solodev game jamming vs. team game jamming:

A note: This is not an exhaustive list, and in no way a guarantee that the game you make turns out good. But these are things I've found helpful. Take them with a grain of salt, or a slice of lemon if that's your preference.

1. It is definitely possible, but you'll have to make sacrifices

Let's start off this list by saying; YES, you can do it, and NO, it doesn't have to be the hardest thing you've ever done in game development. A solodev game jam can be super fun, and my Friday was mostly spent cackling at the project I was working on.
Making a game by yourself is also a very good exercise for any aspiring developer, since it makes it clear just how much work goes into creating a full game and how much expertise each role in game dev requires to achieve professional results. I definitely recommend it to anyone aspiring for a directorial role or designer role, since it shows you just how you deal with the responsibility of a full game experience.

One of the sacrifices you are making in taking on this extreme generalist role of solo developer is that your core skill probably won't get to shine. Most people find it at least somewhat difficult to switch between tasks and different mindsets. For me, the experience made me more empathetic to how my demands as an artist or narrative designer might look to other disciplines.

Then again, when we're talking game jams, we're not talking professional results to begin with. I wouldn't based on this jam game apply for audio positions at game companies, and I'm doubtful whether or not the game I created works as a portfolio piece in any of my core disciplines, even. Considering the time I had to create character art, it's pretty amazing, yet on an objective level I can tell it isn't up to snuff. Same goes for dialogue. And, of course, code, which leads me to...  

2. You don't have to be a coder, but it helps, kind of?

 I am not a coder, but... // I am not a game programmer, but... // I am not a computer scientist, but...

These are all ways in which I've started sentences while teaching game development, because, even though I am not trained as a programmer, through game jamming and narrative design I've gotten proficient enough with code and scripting that I can read code. Not with ease - it's kind of similar to trying to understand the meaning in a poorly translated Facebook post.

So, here are some of my strategies for coping with coding at a game jam as a non-coder:

1. Don't panic - You can always ask for help, if you need it. I recommend having a person in mind to turn to if you run into big issues. It helped me not panic, and in the end, I didn't need their help.

2. Focus on your strengths - be it art, sound, design, music, or writing. Make a game that emphasizes the things you are good at. You don't have to prove your worth as a coder, so don't. Is there a tool you already know? Use that, if you don't explicitly want to learn a new one. Embrace the spaghetti code; embrace the bugs; embrace that the game has simple mechanics.

3. Start by modding a tutorial project - You have limited time at a jam, but I would still encourage you to start from an official tutorial project and modding it into your own thing. Learning the most basic ropes of your engine will save you time in the end, and the engines I've used so far have pretty good tutorial projects offered to get you started (Good examples: Unity, Unreal Engine, Construct 3, Ren'Py. Not so much: Godot, Twine)

4. Start by reading relevant documentation, and then look for examples on forums of how it's used. This one I've learnt the hard way. For example, I spent over an hour fixing a splash screen issue for Grumpy Librarian because I tried to figure this out from forum posts and source code alone. I even looked at the game on different browsers to figure out where the splash screen was coming from. It turned out the solution was well-documented in the official Ren'Py documentation, and took all of ten seconds to implement through simply placing the splash screen in the correct folder.  Similarly, I spent a silly amount of time trying to adjust the volume of the music from looking only at the documentation, not understanding that the issue was about syntax.

5. In general, when switching between languages, syntax will be your biggest source of frustration. To be honest, my coding is at the level of "I guess I could make this well, but maybe I can get this done with simple if/else logic and for and while-loops?". Again, I am not a coder, and you, an experienced programmer, are allowed to frown at me. The good part about that, however, is that most languages support all structures I can come up with. When switching engines, I don't have to learn everything anew, and I don't have to learn the engine fully to get started. You, an experienced programmer, are allowed to cringe at that statement. What will however frustrate you for the first few hours is syntax. I chose Ren'Py for this jam, something I had never used before, and compared to Twine, it is much, much stricter with indentation. It took me a while to understand why I couldn't use '&&' in my conditional logic statements (and I sighed so hard when I found out you simply use the word 'and' in python). My first two hours were spent screaming at error messages I didn't understand. And that leads us to…

6. Error messages could be much, much easier to understand. You have my sympathy. This is true for any engine I've used. Ironically, the 'easier-to-use' engines and tools don't necessarily have easy to understand error messages. The best strategy is therefore usually to Google the error message, but here the size, and activity, of the development community online matters. Depending on what you are working with, there is or isn't a community of newbies like you who are asking the most basic questions. For Unity, there's a lot of complete beginners asking silly questions about the first steps, so you'll find answers easily, even if the engine itself isn't the most beginner-friendly.

3. Deadlines and rules are arbitrary*

Look, you should aim to make the game happen in the time assigned for the jam, but more than that, you should simply finish your game, even if you run out jam time. Jake Parker,  comics artist and the founder of Inktober, has two mantras that I strongly stand by: firstly, Finished, not perfect, and secondly, You need a product, not a project. This sentiment of finishing things being the ultimate teacher is also a rule in the game industry: Just Ship It.

Controversial opinion? Well, I've never been that respectful of game jam deadlines or design constraints, which comes from being a member of the fairly non-competitive Finnish game jam community. It's all about fun, learning and building networks, less so than winning competitions. Think of it as a NaNoWriMo sort of challenge: everybody wins by participating, finishing something teaches you more than abandoning the project, and you are competing only against yourself. This strategy is actually the same for me as a solodev as in a team.

My strategy goes something along these lines:

1. Scope the game to fit the time-frame of the jam. This usually means a game that plays in 10 - 15 minutes, single-location, few characters and one game loop.

2. Realize I won't be able to finish the game during the jam, because I got distracted from the initial design. In the case of Grumpy Librarian, distraction was making art for 7 characters.

3. Get the game ready enough during the jam, so that I want to finish it in the following two-three days, when I still feel motivated.

It usually helps if what I leave for after the jam is easy to do and fun. If you leave gaping holes in your game design, or big scary bugs in the code you won't want to go back. But, if you just don't put in the animations, or need to add some writing to a specific scene, that's much more fun to do. After the jam, I (or team mates) usually only want to make changes that are direct and fast improvements and polish to the game. Which brings us to motivation in general...

4. Task lists help you keep up the motivation

From what I've talked to other developers, staying motivated during your solodev jam is harder than if you have a team cheering you on. I found it helpful to keep a task list. In the task list, I list out what needs to be done, but more importantly, every single thing I've already done. Seeing that row of green makes it so much easier to feel accomplished, and not feel like the list is endless.

Even if it's just for myself, keeping a task list helps me focus. These kinds of lists are what I usually make if I am the producer at a game jam, and they give structure to what I'm doing.

Here's my task list for Grumpy Librarian at the start of the jam:

Here's my task list for Grumpy Librarian right now:

A few tips I've found good for your task list:

1. Let the list live. Some things will move about, some will be removed, some will be added.

2. Don't mark things in red before you have green markings. Seeing the whole sheet in red is almost certainly guaranteed to make you feel demotivated.

3. Prioritize, but don't get boggled down by what you've marked high priority. As you can see, one of the first things I marked OK was fonts. Why - the default font of Ren'Py isn't that bad, is it? Well, it isn't. But by switching the font I learned how to edit the GUI files, which was important. (Sidenote: Also, in a text-based game, typography is going to be visible on every single development screenshot...)

5. If no one is around to hear your terrible puns, does it make them less terrible?

Alright, here's my last tip, and this one goes out to all of my game writer colleagues: it is funny, but not that funny. Practice a little self-restraint. Or then don't. This is your chance to make a game that looks exactly like you want - in good and bad....

Hope you found my tips helpful!

Overall, I definitely recommend trying your hand at jamming alone. I still prefer working with a team, and in person, but if I can do this, so can you :)

Do you have any tips & experiences of your own? Questions?