Since the success of the first Game Jam, I have eagerly awaited the next one. It is a chance to improve our processes, attract more people, and of course make another game. Judah and I had a retro and came up with some ideas to improve the jam. We didn’t pose them as formally as I have chosen to here, though.
Logistical Changes
The main goals of the jam have not changed: learning to make games better and to make better games. The other goals of fostering teamwork and being inclusive also remain in the forefront. The format and process of the jam itself can influence these goals as much as the participants. Ideally, the logistics should make the experience smooth and help those participating do their best work. We want to correct anywhere that the process is the cause of friction.
Separating from Hackathon
We chose for this jam to be separate from the SEPMakes Hackathon. Mostly this was to allow people to attend both events. It should also make it easier for Game Jam to make changes to its process that would conflict with hackathon. While it requires some more work to get things set up on our part, we hope it will improve attendance.
Limiting the First Meeting
The first meeting of the Game Jam is when we form teams and choose the theme. For the first Jam, Judah and I took some time to give suggestions to people on how to get things done efficiently. Nothing out of the ordinary: don’t bite off more than you can chew, keep it simple, etc. We gave examples of winners of other game jams to create some useful expectations.
It seemed like a good idea for newcomers, but it slowed that meeting down a lot. Unless you were new, it was not an engaging portion of the meeting. We decided to remove this part of the meeting and focus on forming teams and setting the theme. Saving time will also allow for teams to discuss their ideas for their game within the scheduled meeting time.
Replacing Standup with Playtesting
The Hackathon has some patterns that it sticks to very closely. One of those is the post-meal standup. After eating everyone shares a bit of what they’re doing and how it is going. For hackathon this is an opportunity to learn about things you aren’t working on. There is also the chance to help another team if they share a problem they are caught on that you have knowledge about. For hackathon it is a good use of time.
With everyone working on the same thing, we predict standups won’t be as useful. Standup is usually short, but every second matters. Waiting to start standup while others finish eating is time that could be needed to get your game done. We didn’t want to lose the chance to knowledge share, so Judah suggested that we implement some playtesting. Having people spend some time playtesting each others’ games will give actionable feedback that could improve the game.
We agreed Saturday afternoon seems to be the best time as there would be enough time to actually make changes based on the feedback.
More Casual Presentations
Hackathon presentations are usually long and structured because they cover a lot. Each project is different and need to introduce their main concepts to an audience unfamiliar with their pitches. For a game jam, that seems unlikely to be the case. While not everyone is necessarily using the same game engine, we are all trying to make games. That along with the decoupling from hackathon means that our end-of-weekend presentations can be a lot more lax.
We don’t want to discourage people from being more verbose with their presentations, but the need to limit people’s presentation time seems much less necessary.
Team Changes
While the flow of the event should ideally be frictionless, it is only the framework for the work being done. The potentially more important improvements to be made are within the teams making the games. On top of trying to make the experience smoother, I also have some ideas for making game creation better.
Unifying Vision Early
In the first game jam, my team didn’t have a perfectly unified vision of the game. While that wasn’t explicitly a problem, it meant there were some discussions that needed to be had mid-Jam. While they were great discussions about game mechanics and user experience, it was time spent not developing the game. Making sure everyone is on the same page for the game should save time in the long run.
Build in the Overflow Valve
Finishing the core mechanics of the game early in the jam is likely to save time. Obviously, it’s good to finish things early because it means there’s more time to add more content. It also means that if you haven’t thought that far ahead, you have to spend more time deciding on what to add. If you do that planning while you’re already in the context of planning, it is less time-consuming. Coming up with a game idea that is easy to add to or having stretch goals in place from the start should reduce wasted time.
The Jam Itself
Thursday
Like the first game jam, we formed teams on Thursday and voted on our theme. This time, “Dimensions” won. Again, not one I was expecting, but definitely a theme with a lot of potential. My team landed on a character transitioning between 2 and 3 dimensions to solve puzzles. We decided on this after the Thursday meeting and decided to do some brainstorming before the Friday kickoff.
I was hoping that with everyone doing some thinking, we could rack up a number of different puzzle and level ideas. We could use all those ideas to get a good picture of what it is that we wanted to make. At the very least, we could get a lot of stretch goals down on whiteboard.
Friday
The teams reconvened after work, ate some food, moved desks, and started coding. I spent a good hour in front of a white board writing down all our goals and plans while the team shared ideas. We built up a beautiful collection of different puzzles that could be done once a stronger idea of how them mechanics were going to work. We assigned out tasks and got to work.
Saturday
Saturday: the meat and potatoes day of the Jam where everyone has the most time to get things running. We went into this day with a good start on our game and a solid roadmap for the weekend. So, of course, we hit some bumps in the road with development.
As lunch rolled around, we told people to get their games ready to have others playtest them and everyone got back to it. We had our character model made, a proof of concept level, and the main mechanic was functional, but had some issues. After dinner, each team sent a person or two around to playtest each others’ games. Some bugs were found and feedback given; while not as illuminating as we hoped, it was very cool to see how far everyone had gotten.
Sunday
On the final day, the expected, last minute rushes occurred. We tried to put last minute polish on everything: music, menus, and levels. We waited until the last minute to upload something to itch.io, but that’s just SOP for all these events. When the true deadline arrived, presentations began.
Like the first game jam, we had someone from another team play the games while the creators spoke about their game. With 4 teams, we blazed through presentations. There were some really cool ideas. I’m always impressed by how creative interpretations of the theme are.
You can find the games from this game jam on the SEP itch.io page.
Results
I’ve kept specific happenings during the game jam related to the changes we made saved for this section here. Were the alterations correct or do we need to iterate on things again next time?
Separating from the Hackathon
The cost of this change was felt mostly in the planning. We did have to spend a bit more time and effort getting beer and making sure the food arrived and was set up. The main benefit, the freedom to make changes that would be incompatible with the hackathon, was worth the cost. The other changes for the logistics of a game jam are pretty much dependent on this separation. We ended up at about the same attendance, just slightly higher. Plus, I got to participate in the 2022 Summer hackathon as well, which is a pretty big upside. Not great for the things I usually get done on the weekends, but I do thoroughly enjoy myself at SEPMakes events.
All in all, I think this was the correct choice and, in the future, we plan to keep these two events separate.
Limiting the First Meeting
We cut out the guidance and examples of previous game jams. Honestly, it didn’t seem to have a huge impact. We had newcomers to this game jam, yet everything went pretty smoothly. So excluding this extra bit of information from the meeting appears to be the right choice. Judah and I still feel like that type of information could still be useful, but this meeting was not the right place for it.
Replacing Standup with Playtest
Keeping up with what other people are doing is nice, but the Game Jam time crunch is strong. No standup allowing for a quick dip into the commons to grab food, eat and then return was definitely something I took advantage of. There was still socializing while eating and discussion of the games, but the lack of process around it let people set their own levels of priority.
The playtests themselves revealed some bugs and allowed for some suggestions for each team. While this is a competition to some degree, the focus has always been more on the knowledge gain. This is something we will definitely be doing again.
More Casual Presentations
There are fewer teams in the Game Jam than at a hackathon, so presentations without hackathon numbers are inherently going to be shorter. The presentation themselves were also shorter because everyone’s pitch is the same: to make a game. Showing off a couple game mechanics and talking about a few issues that your team ran into ends up being fairly concise.
Nobody was timing, but I think presentations clocked in at 20 minutes. This change mostly piggybacked off of being separated from Hackathon, but it will be one we continue with.
Unifying Vision Early
My team spent the first couple hours on Friday laying out a roadmap. To make a long story short, eventually everyone agreed on the vision of the game. We tried to keep that vision simple, but broad. This was a good exercise and seemed to find some of the places where we had disagreements in what the game was going to be. It didn’t perfectly unify our vision, in the end, but we had some very challenging issues during development that lead me to believe this idea isn’t necessarily wrong, just not well explored this iteration. Whether this strategy is effective will need some more experimentation.
Build in the Overflow Valve
This game jam did not test this hypothesis particularly well, either. Our team didn’t get as much done as we would have liked due to the issue with our main mechanic. We did reach moments where people had finished what they could and needed something else to pick up. That we had a list of things to do made those moments simpler. Mostly, though, we did not venture particularly far past our MVP, so this change is open for further exploration in the future.
Building new Hypotheses
So like a good science experiment, we need to make more hypothesis for next game jam. There are some that are already in place and will make their appearance in the next blog post about jam #3. The ones I want to focus on here are inspired by the issues my team had that I’ve hinted at until now. These are not the ones from Judah and my retro on the event; for those, you will need to wait for the next blog post.
Reducing Game Complexity
I am an ambitious person. Not all the time, but when it comes to creating something, I get a vision in my head that gains a lot of momentum. For this jam, the idea for transferring from 3D to 2D space had blinding potential. The idea is not the first of its kind, but it did have some cool things in it to learn and some potential for visual pizzazz.
It also crossed my mind that since it was a puzzle game, it would open up the door for other people to build new levels independent of one another so that we could “Build in the Overflow Valve” with minimal overhead. I was very wrong.
Core Mechanics are a Dependency
It turns out that this core mechanic was pretty difficult to implement. In the time of a game jam, you have to make concessions to less robust code to just get something working. I had something working by Saturday Afternoon and was working on building the process for teammates to build levels fluidly. Blender not playing as nice with Unity as I had hoped mixed with one of the team members making my code better caused some massive delays.
These delays prevented us from building other levels and. unfortunately, puzzle games are entirely the levels that make it up. I can’t fault my teammate for improving the code. That was not my best code; it was midnight code. I didn’t foresee the problems that it would cause in our process of making levels and gave him the thumbs up to do it. That code is so much better now, but as a result, we had one incredibly basic level to show for it.
Choosing a core mechanic whose implementation is simple but extensible is a more optimal choice for a game jam. Whether that will be possible for me to do is likely the larger challenge.
Reducing Team Size and Assigning Roles
I have had a team size of 3 and a 4 in our game jams. The team of 3 had a designer and the team of 4 did not. Even 2 more developers made these teams felt vastly different. Having a solid list of things to get done did not prevent 4 developers stepping on each others toes in a small codebase. Even with active attempts to prevent it from happening, it was harder to avoid. I am not planning to enforce any numbers on other teams, but I am going to be attempting to actively recruit a team for the next game jam with a specific makeup.
My hypothesis is that there is room for 2 developers and anyone additional needs to be in a more design or aesthetic focused role. We have a lot of creative developers here at SEP who are not designers. Perhaps specifically asking for someone who wants to work on music or 3D assets for a whole weekend and not code will be good. Perhaps it won’t; that’s the point of the experiment. I think a potential side effect of explicitly requesting design roles for teams will open up the game jam to be a more unique experience based on what role you want to fill, though I worry about lopsided teams.
Begin the Countdown
The next Game Jam should happen in the early months of 2023. The next jam’s blog post will be more timely. I, for one, can’t wait to take another crack at this.
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
