Every couple of months I like to take part in a game jam. It's fun to try and build a thing, and also feel totally fine with never looking at it again afterwards.

Usually these happen online, over the course of 72 hours. Probably one of the more famous ones is Ludum Dare. I've done most of these alone, though I have in the past also done jams with one other person.

In the beginning of November I decided to participate in a 48 hour game jam.

This time was a bit different for a couple of reasons:

  • This time I had recruited 3 of my friends to join me.
  • For the first time, I would be doing an "IRL" jam, where many teams would be in the same spot.

This turned into a really unique experience for me.

Days -1/0

Though I program for a living, my professional expertise is in web programming, not game programming. So I decided to do a bit of studying before the jam started.

I had some other stuff to do as well, and some vacation days built up. So I took the Thursday and Friday off, and spent some time looking at tech.

I've taken risky bets with 3d engines in the past, but it tends to be really hard to get anything working, so I decided to try leveraging even a bit of my web knoweldge by going with Phaser.io.

I set up a test project in Phaser 3 and started trying to create some basic gameplay snippets

On Friday evening there was a kick-off event. Lots of people made groups, though since my friends were coming from Saturday morning I was observing more than anything. We all chatted a bit and got a bit "in the zone" with regard to the themes and how other teams would be working.

Day 1

On Saturday morning the real work began!

After some discussions had over Line we had coalesced around building a GBA-style strategy game. Something like Advance Wars or Fire Emblem.

The first bit of work was just to figure out how we would start parsing out work. I had pre-assigned myself to lay the groundwork for the project.

When we started work on Day 1 we already had a thing that could ingest basic maps.

image-20191111234614472

Since we were working on a strategy game we needed a couple of things:

  • Some units
  • Some maps

We talked about an art theme for a while. I was pushing for a serious style, but others on the team felt more like going towards something a bit funner.

Someone mentioned Halloween, and we had a vague fantasy theme, so we ended up with skeletons on one team. We put a purple hat on one of them

s1

We now has the purple team, the skeletons.

We bounced around some more ideas for a bit, and landed on, for lack of a bettor word, blobs. Blobs can easily be green, so we made them such

b1

We now had the green team, the blobs.

The idea was simple: blobs and skeletons were fighting each other. We hadn't totally figured out the combat mechanics, but the idea would be that you could have several different unit types, as well as upgrades.

As to the gameplay itself.... since the idea was 'mana pool', we thought about doing something around MP (magic points).

Most games will say "if you do a special action, you'll use up your MP". We decided to take it one step forward and say: any action will use up some of your points. This would be our gameplay gimmick: a strategy game that forces you to pay to move units. And around the map, you could capture resource areas (Mana pools) to have more MP.

m1

m2

m3

So we had a theme, we had a kernel of an idea for the gameplay itself, so we started building!

There were 6 of us, and only 2 programmers, so figuring out our design theme early on let the non-programmers spend a lot of time trying out different looks and thinking about the game in general, while the programmers rushed to build out the basic game itself.

Lunch time came around and we had a Ramen break

We decided to put some visual aids on the walls to get an idea of what we had to do (along with "Stretch Goals" to help us think about how our game could end up being)

image-20191119222519966

(In the end these weren't updated through the weekend but it was still nice to look at)

The afternoon got into the evening, and then at one point I just thought out loud "....implementing AI is going to be something unfun."

This started off a discussion about what this could look like. We could make the AI super simple. Games like Enter The Breach have predictable, simple rules for enemies, after all.

Someone mentioned the idea of just not having AI at all! This got us into a really interesting series of ideas.

  • Maybe enemies just have super simple movement patterns

  • Maybe enemies don't move at all and just react to you

  • Maybe you just have to win in one turn.

That last idea really saved our skin. If you just win in one turn, then the AI doesn't need to exist at all! This "No AI" solution morphed our strategy game into a puzzle game.

At around 6PM we had this idea. Some designers were tasked with trying to make a really simple puzzle on a 5-by-5 grid. The new game design:

  • You are the Blob team
  • The enemies are the Skeleton
  • You must try to reach the Skeleton Castle with a fixed amount of mana
  • Enemies will attack you if you are next to them

With that simple idea work began. The newly spawned "puzzle design team" (two people who were originally handling art) messed around on some paper and tried to design some levels by hand.

image-20191119223209214

The above picture was our first level! There was some basic playtesting with the physical components, and we decided that by the end of the evening this first level would be playable.

There was a huge sprint on the programming side to program in basic "puzzle game" logic into our grid-based strategy game, so this first level could be inserted. Other members continued to work on puzzles and discuss mechanics or contradictions in the rules.

By around 10PM, we had done it! The first level was playable. This resulted in a "live demo" to the whole team, including me backwards weilding my laptop (turns out to be very difficult to type in this position).

image-20191119223740066

It's hard to underestimate how satisfied I was at this point. We had a workable concept. And it was a puzzle game, so game design could happen even if programming work got stuck in a rut. I was convinced we could go very far in the second day.

We all went home to get some rest, so we could come back in decently early.

Day 2

I got to the space where the game jam was being held around 9. I was the first one there (except for some other guy who had slept in the space). I started getting back into coding, and quickly realised that the programming side had our work cut out for us.

There were a lot of shortcuts taken in the end of Day 1, and if we were going to maintain our sanity we'd need to tactically pay down our tech debt.

I started hitting roadblocks around our hacked together update loop, now that we had some precise puzzle game logic. I was also hitting weird asset issues that ended up being me having made some mistakes in Webpack configs in Day 1.

Other memebers of the team came in around 10. Game designers went to work trying to make some puzzles, the other programmer started to integrate sound effects and music into the game (placeholders until our sound designer made us some awesome beats) . Our artist started cleaning up some old sprites, and working on animations and the like.

image-20191119224653818

(pictured above is a very wobbly table that all 6 of us were on these two days)

There the rubber really started hitting the road. We spent a bunch of time trying to develop new rulesets, and suddenly design decisions came back to bite us. There was a lot of ruminating on the best way to implement the rule resolution, as our existing thing was getting harder and harder to fix.

In one fun little state machine bug, we refactored our audio player in such a way where you would end up with the intro music playing over the level music if you would jump through menus fast enough.

Towards the afternoon we were really rushing to get a final product up. This is where it was really difficult to move forward. Ultimately, when the programming side gets stuck, none of the other processes can really move forward too much.

At 6 PM there would be a presentation of the works. By 5:30PM we had a mostly finished product. It could only run on one of our machines consistently, and if you did certain actions fast enough you could get your units to clip through stuff... but the concept was there! For the first time in my life, I had a real result from a game jam.

Presentations

From 6PM various teams showed off their games.

We had a demo computer set up, and had people play through some of the levels. We were quickly met with some expected results, as well as some unexpected ones.

Since we were designing the game, we knew that we were much more aware of the game rules than a new player. We tried to design initial levels to communicate these game rules. We would introduce concepts individually and hope the player could organically figure things out.

In practice, though, given that we only had about 10 levels or so, players didn't have a lot of opprutnities to figure out rules. We would try to design levels where you would "have to figure out" a system to finish it, and people would end up finishing by accident and not have another learning opportunity.

What surprised me the most was watching people try out the game and be almost afraid to try things out. I tend to play puzzle games with an understanding that I can always restart, so will experiment a lot. But some people would be unsure of how to progress and so wouldn't move their units.

Since our progression curve was based on people experimenting to discover the rulesets, this was a bit of a problem for us.

There was a silver lining in all of this though. Since many people were in this space, the puzzle solving became a bit collaborative. Observers would suggest stuff, we could also help people by giving some hints on things to try out. We could also paper over some design issues by pointing in the right direction. So several people actually got to the end of the set of puzzles, perhaps just skipping one or two of them.

Despite having coded the game, at that point I had not actually beaten every puzzle at that point. And I don't believe anyone else on the team had succeeded in that either. Watching a group of people get from the beginning to the end was a really fulfilling experience.

Lessons Learned

  • If you have 36 hours, plan for an idea that you think will take 12 hours to build. Then cut the project down by 50% more
  • Working in a group of 5 was way less chaotic than I thought it would be!
  • If you are bottlenecked on programming, an idea that can be prototyped on paper is super helpful
  • Having something playable on the first day is essential for motivation
  • Webpack works pretty well for game jams!
  • Push on your strengths. Lots of good artists? Do something with art! Lots of programmers? Do something with game mechanics
  • It's OK for your game to be light on mechanics. Having an experience is what matters