In this post, we'd like to share our experience at the Seattle Indies Game Jam 2019, where we created The BridgeMaster, a tile-based puzzle game. You play as a magician who must salvage materials from the village in order to build bridges and help the villagers escape!

GOALS

Going into the jam, we had a variety of goals:

• Above all, we wanted to choose a game design that was (relatively) simple to implement and polish the crap out of it.
• Our two previous games (Good Night Rowan and Else Return Home) were both first-person, so we wanted to switch it up with a different perspective.
• The last two games also had relatively long gameplay loops. This time, we wanted to make a tighter gameplay loop where the primary action was exercised more often.
• For our other games (first Dog Walk, then FLY2K) we developed a generic graph library for representing nodes and edges/connections. This time, we wanted to utilize that code again but for a tile-based game.
• We also wanted to pay attention to some core concepts of game design and let those inform our process as much as we could. The next section lays out some of those ideas.

THEORY

Before the jam, I thought about what makes a good game for a jam. Following one of our earliest jams (Odd Office), we were super grateful to be recognized by the judges for the Best Game. Something one of them said stuck with me ever since, and it was that they appreciated how it had a clear beginning, middle, and end (which can be difficult to do in only 48 hours). This insight with some other ideas evolved into a 5-Point Theory:

• (Game)Play: The core mechanic needs to be compelling and fun to play. Ideally it is quick to repeat / can be demonstrated quickly.
• Progression: This is where the beginning, middle, and end especially come in. There should be clear advancement, whether in terms of levels, difficulty, plot, player abilities, etc.
• Payoff: At the micro level, this entails the audiovisual feedback when performing the core mechanic. At the macro level, this involves some payoff at the end of each level and at the end of the game.
• Polish: As much as there is time for it, we should give care to the audiovisual aesthetics, enhancing elements where not strictly necessary but the discerning observer will notice and appreciate.
• Personality: Finally, in the narrower sense, the game should have easily identifiable characters within it. More broadly (and perhaps more importantly), the game itself should have a clear style, and it should feel like it was made by real people.

I even made this shoddy sketch for the team at the jam

BRAINSTORMING

With these goals and aspirations in mind, we arrived at the site and discovered the theme: "Intentionally Broken".  Some first thoughts had to do with "broken" games in the meta sense or goofy physics. We wanted to go further though, so we considered what it would mean if the game's setting - the world itself - was broken. Combined with our goal to make a tile-based game, we imagined that some tiles could be walked on while others had fallen away. This soon led to a magician building bridges to help villagers escape a crumbling village. Finally, the piece that brought it all together was that the player's character herself must intentionally break down the villagers' homes to save them.

Here's an early paper prototype of a level

WHAT WENT WELL

First of all, we had a load of fun making this game! I think that should be the top priority of any jam. We also largely achieved our initial goals by choosing this design. The (Game)Play loop was shorter, it had a top-down perspective, it was tile-based, and it used our graph code. We also finished the core mechanics with time for plenty of Polish. This included:

• Displaying visual effects and animations for a variety of events (e.g. salvaging materials, bridge building, teleporting)
• Interpolating rotation of the characters going around corners
• Syncing up the audio to our intro sequence
• Including color-coded visual feedback for the player's input (indicating valid or invalid paths)

We also managed to develop a Progression with five full levels, along with a short intro and outro to bookend the game.

This bridging animation was not strictly necessary yet great to have

WHAT COULD BE BETTER

Nonetheless, there were many things we ran out of time for or struggled with:

• While the intro briefly displayed the title before the first level, we did not fully establish the exposition.
• We also planned a broader outro with its own scenes and animations, but we did not get around to this.
• We had to leave out any tutorialization dialogue for teaching the controls and mechanics.
• While the five levels we made were intended as the tutorial, they weren't large enough to more fully demonstrate the puzzle solving potential.
• Without the dialogue, we could not establish the Personality of the magician or the villagers and highlight the humor in destroying the village to save the villagers ("Not my trinkets and doodads!" "Do you even want to be saved?").
• One Payoff element we imagined but didn't include was a level summary window, indicating to the player how well they did.
• We inevitably ran into some version control issues. Merging Unity scenes amirite?

A grand plan that didn't quite make it

WHAT WE LEARNED

Although we didn't complete everything we wanted, we learned a lot! Some key takeaways:

• Communication is key! With nine people on the team, it became very important to regularly sync up.
• Whiteboards are super useful! We happened to pick a table near one, and it soon became integral to our process. We used it to sketch out ideas and kept a running TODO list with status indicators and prioritization points.
• Be prepared to cut scope early and often! We had many plans, but as the jam progressed, we periodically put features on the back-burner. By Saturday afternoon, we knew we had to switch gears and polish what we already had.
• Clearly delineate responsibilities! Version control works best when individuals are working on separate assets, whether those are scripts, scenes, or prefabs.
• Do variations on art assets at the end! Art must always be completed before it can be integrated, and they can't be integrated before they are done. This means the art team could wind up finishing content at the end with no time to integrate. However, if you've already integrated a given asset type once, it will probably be much simpler/quicker to add or swap in a variation.

We reused the same rig to add another villager type at the end

WHAT'S NEXT

Although the jam is over, we're continuing to polish and extend on the project! A week from now, we'll be showcasing at the Seattle Indies Show & Tell and SI Game Jam Showcase. If you happen to be in town, we hope to see you there at the Pacific Science Center! Here's a sneak peek at some of the new features we've added since the jam and plan to have in time for the showcase:

• New intro sequence starting with an establishing shot of the Magician's home
• Dialogue to help teach the controls and mechanics
• Dialogue with exclamations and responses between the Villagers and Magician
• Various bug fixes and quality of life improvements
• Dynamic music that updates according to the player's current progress
• New, bigger levels added to the level progression!

While we continue to work on The BridgeMaster, we'd love to hear your feedback and suggestions! If you'd like to play the game, you can download it below. Thanks!