In the game jams I have been associated with there have been times where I felt like we were successful and other times where I felt like we weren’t. The idea is to build a video game over a short period of time. If you fall short of having anything to show at the end, it can be frustrating. More than likely it wasn’t due to lack of effort. I want to provide some tips that can help you be successful in your next game jam. These come from my own experiences.
1. Reduce the Scope of Your Project Early (and often)
Depending on what method you are using to come up with ideas, almost every team finds themselves in situations where the team is left saying, “Do we have time for this?”. That is actually a very good question. The teams that I have been a part of that truly struggle often miss this question early or perhaps they do not revisit it until it’s too late.
My suggestion is that during the development process, everything is on the table. The game will likely evolve, and that is okay! Instead of being frustrated with that, realize that it’s part of the overall process in game development. The difference here is that it is in a very short period of time so game jams tend to potentially feel like you are always aiming at a moving target.
I believe you just have to embrace that concept. It’s part of the fun of it, really.
Before you start each task, this should be checking in on the scope of the project. You should continuously be asking, is this something that HAS to be in the game? If not, I bet there are some other things you are better off working on. This is particularly the case if you are still in the early prototype stages.
2. Leave 1 Hour to Upload Your Project
I’ve made this mistake before! You have the project complete, but something about building the game isn’t quite working. In my first Ludum Dare, I need to upload the game to an online platform such as itch.io. I thought I could do it pretty easily. What I found out is that my game didn’t look great.
Luckily, I had a bit of time I could take a step back, fix some of the errors that did entirely break the game. Still, I was up to the wire on getting the game submitted. Once I did get it submitted, I realized that the link was set to private so people were unable to play the game. It was so frustrating!
Honestly, had I not left myself about an hour to get everything built, uploaded, and submitted, there is no way I would have completed it. It truly was crunch time and I was sweating it.
3. Know at least one area of interest before the game jam
This is my suggestion for really any game jam. You do not have to know a theme to have an area of interest. As an example, in the last Ludum Dare, I knew I wanted to work with the AI system / NavMesh system in Unity. I was able to watch a handful of tutorials beforehand, which lent itself well to me not feeling entirely lost as I got started.
I was able to come up with what I think was a fairly creative idea, a bunch of chickens in my game, that allowed me to really learn a lot through the process. This was my goal and something I wanted to focus on. What about you?
Just some examples here, but if you want to work on your art, then why don’t you keep the gameplay very simple and build a beautiful environment or character that is the primary focus? If you want to work on your programming abilities, then I would suggest keeping your models very simple, maybe even primitive game objects that don’t require modeling.
The idea here is that you want to determine what you want to get out of the game jam before it ever starts. Allow that to be the driving factor in what game you decide to build based on the theme.
4. Create Goals and Revisit Them Often
I like to feel organized. I think it is even more important when working with a team. Honestly, to keep people truly organized it will take a considerable amount of effort. In the teams I have been a part of, there seems to be one leader that arises and they generally just start taking on this role naturally. I would highly recommend using this as the method.
I once worked online with a team that had a designated project manager. He brought nothing to the table more than telling people what to do. It didn’t work out so well and it’s one of the few times I worked on a team that totally fell apart before the end of the game jam.
My advice is just to create those goals as you move along. One of the best methods I have found is to time-based goals. An example might be, “I get to spend no more than 30 minutes on this model”. What this allows me to do is work within that constraint. I am feeling that crunch all the time, making the model as quickly as possible, but also focusing on the important parts first.
In the Global Game Jam, one model I worked on was a large crane that was a part of our junkyard scene. It was important to make it look right. I afforded about an hour on that model. For smaller models, it could be as few as 10 minutes.
My small goal might be “Create a model in 10 minutes”, but the overarching goal might be, “Create 5 models in 1 hour.” The even broader scope would be something like, “Create a junkyard scene in 4 hours.”
Team members should be creating smaller goals for themselves, but the team overall should have their own too. The last one mentioned above (“create a junkyard scene”) may be a team goal as you could have someone modeling, someone putting the level together and working on lighting, and the programmer perhaps working on any functionality you want to have in the scene. In our case, picking up the player with the crane and a few other items.
5. Take Breaks / Sleep Well
This is one you hear on every list. I am trying to give truly helpful advice. This is one that is heard repeatedly, but probably not well executed by many of the teams.
If you are in an environment where there are sleeping arrangements, I would advise that you really consider your sleeping arrangements. Most facilities will provide you with a dorm room maybe, but they probably have no pillows or maybe even blankets in many circumstances. You want to be prepared for that.
I recall a few instances where I worked probably entirely too late. I enjoyed that, but when I went to go to the sleeping location, it is was pretty miserable trying to get rest in there. A few people had cots, but most were sleeping on the floor. My body doesn’t hold up to that anymore!
It led to me being fairly cranky and uncomfortable over my time there. If there are no adequate sleeping arrangements from here on out, I definitely will be renting a hotel room nearby. The goal is to enjoy your time, not be uncomfortable, miserable, or cranky!
In addition to this, I would suggest that you work as long as you want, but find adequate sleep following. I’m naturally a night owl. I would prefer to work until 3:00 am. Of course, when I do that, it means I tend to sleep until about 10:00 am the following day. To me, that’s okay. I am still putting in my time.
6. Have a Single Mechanic Focus
One of my favorite tips is this one. I think it can really help people who are new to game jams and struggle to know exactly what they might be capable of building.
It’s a backward approach. Start at where you want to end. Determine what single mechanic you want in the game early, and keep that as the end goal. As an example, if you are really new to programming, you might consider doing a story-based game where players can interact with either objects or NPC’s in the game. A simple dialog box appears to reveal the story. THIS IS YOUR MECHANIC.
Beyond getting a player up that can interact with other things (basic movement and triggers) in the scene and getting a dialog box to appear, everything else is secondary. Obviously, this is very simple for some. If you are brand new to programming, I think it would be a great place to start. You will not feel too overwhelmed.
A side benefit to using this method is that it keeps the team in the focus of the end goal. You can focus on the art for the dialog boxes, the story, and laying out the pathing for the character. However, when your teammate starts talking about how awesome it would be to have “this easter egg in the game”, you can say, “well, it doesn’t really relate to our primary mechanic, so can we wait on that and see if we have time?”. Trust me, it happens quite often.
7. Get Feedback Often, Preferably on a schedule (Hourly Review Meetings)
If you are continuously creating things, I would definitely be getting feedback often.
As a programmer, you want to create simple prototypes. Using the example above, if you are creating a game where it is story-driven with a dialog box, build the basic mechanic, get a temporary dialog box to appear. Let your teammates play it. What do they not like? How can it be improved? Most of the suggestions will be polish ideas, but write them down anyway.
As an example, they may suggest, “the dialog box needs to be bigger” or “the text is too small, it’s difficult to read.” These don’t deal much with the programming side, but it’s something you can speak with the artist about.
If you are an artist, the concept is similar. If you are creating the main character, my advice would be to spend 5 minutes speaking with teammates about your idea for what the character will look like. Your concept art doesn’t need to be fancy, but perhaps something to give your teammates an idea. Then get feedback before you build the final version. You may receive feedback such as, “Why doesn’t it have legs?” or “Can he appear a bit more friendly somehow?” This will give you some clues on what direction to take your art.
I would suggest that at every phase, anytime you build anything, you at least have someone take a quick peek. Do this at key moments though. Other teammates are trying to get things done too. It can be annoying to work with someone who asks you to come to look at their work every 10 minutes.
In my most organized teams, we planned to speak at the end of each hour. This allowed us to say, “Hey, I’m working on something for the next hour, but at 9:00 pm let’s get together for a quick review.” If you plan things out well, you will have a few items to show at the end of the hour and can get feedback quickly on all of them.
8. Put Your Ideas on Paper Throughout the Project
You are pushing through a lot of ideas, suggestions, and feedback as the game jam goes along. I can count several times that I have had some kind of idea for something, but I didn’t want to bother my teammates with it. We get to our hourly review meeting and I forgot what I was going to say.
Jot your ideas down on paper. If you are concerned about something specific, write it down. Using the previous example of a story-based game and dialog boxes, if you are concerned about the amount of text on a dialog screen being an issue, it’s probably something to address with the artist creating them.
If you are an artist and realize that there is too much text for a dialog box and we need some ability to flip between multiple dialog boxes, scrolling, or perhaps shortening the dialogue, then you need to address that with the writer and the programmer.
It’s the little things that seem to slip through the cracks and cause major issues later on. In addition, you can use your sketchbook to make notes on changes that are being suggested for the game during your review meetings. It doesn’t have to be anything fancy, but it’s a good place to go for reminders about tasks you need to work on.
Did you finish your tasks for the hour early? Great! You likely have more tasks you could jump on, or you could review the suggestions that have been given to you and make some educated guesses as to what else you might be able to work on.
9. Manage your to-do list often
We use sticky notes in my class to help organize game development projects. We also used it during the Global Game Jam for our larger team. Our actual process is similar to the agile scrum system.
One area is your backlog. Any ideas that come up that you want to try to get to go into this section. Try not to limit your teammate’s suggestions. Their ideas may be crazy, maybe unrealistic. Let them have creative input. It doesn’t hurt to throw the suggestion in the backlog as long as you can collectively agree on what the most important items are.
As an example, you might have someone say, “Hey, I would really like to be able to put this cool little easter egg into the game.” Your response should not be, “No, we don’t have time for that.” Instead, add it to the list and say “I think there are probably some areas we have to focus on first, if we have time we will try to get it in.” Most teams will not have an opportunity to add it, and you probably know in the back of your head it is a bit unrealistic. Still, let people provide suggestions. If you have that environment, you don’t know who might throw out something amazing after a few terrible ideas.
The second section is the “To-Do List”. We keep this fairly clean. What are my items I can get done in an hour? You remember me suggesting hourly review meetings? This is an opportunity to add things to your to-do list for one hour and refine what you have in the backlog for the upcoming pieces you want to add.
The last section is your “Done” section. As you get pieces done, move the sticky notes to the done section. This may allow other team members to want to take what you have completed and start working on it or implement it into their tasks. As an example, as a programmer, I want to add the character model as soon as I can. It just looks significantly better than a cube or capsule. You can also test scale and things in the environment that may force you to make some changes.
10. Create an “If it was just this… I would be happy” statement
Lastly, I advise everyone to create a statement that keeps the end goal in mind. If you could just have a piece of your game complete, what piece would you want to have most?
I would suggest putting this in big, bold writing above your to-do list. When you get a crazy idea that you want to implement, run it by your statement. If it doesn’t fit within that scope, it can go into the backlog, but it probably should be listed as a priority.
Focus first on those elements that are a direct impact of what you truly want to have done at a minimum. Using our example of a story based dialog game, if your goal is just for the player to interact, I probably wouldn’t start working on the character being able to jump or have any attacks or defensive abilities until that basic movement is complete and the ability to interact is complete. Once you are done with that, you can move on or maybe even revise your statement to something a bit broader.
One benefit to doing it this way is that it keeps people from getting their feelings hurt. Someone might have an absolutely crazy idea. Instead of having to say, “No, that’s a terrible idea”. You can say, “I don’t think it fits within the scope of what we want to complete.” Refer back to the statement with them, and it helps keep them on track.