Postmortem

LoJam

Mend was developed during LoJam 2019, London Ontario's second game jam, which promoted games in benefit of mental health and raised over 3k CAD for a local mental health institution, FEMAP. The jam lasted for 48 hours and the theme was "Healing is not linear".

Mend's development team consisted of Lyssa and myself. We are both programmers by trade and very passionate about game design and gaming's history. This was our first game together and my second game jam.

Lessons I learned from my previous game jam

My first game jam, GMTK Jam 2018, was a great experience and I managed to finish a game that I enjoyed making and still enjoy playing to this day. I also learned a handful of important lessons:

• Having people I didn't know playing my game is what is best in life. It was great reading feedback from people who had played it.

• Having played over 100 games that were created for the jam, I was exponentially more likely to play a game the easier it was to make it run. Browser games were king in this, with Unity games coming in second.

• Putting the previous two lessons together, I decided that in future jams I would focus on getting as many people as possible playing my game, which doesn't necessarily means "the best possible game".

• People really don't want to read how to play a game, they just want to play it and figure out as they go. Having a game that you can just start playing is amazing, especially for game jams.

These lessons would eventually shape how Mend turned out to be. Speaking of which:

How Mend came to be

When the theme of "Healing is not linear" was announced and we first started brainstorming, we also starting recalling our own struggles and victories with mental health. It hit very close to home and it was an emotional process, but we managed to sketch out a handful of ideas that mostly fit into three categories:

• A game where your progress isn't lost even when you distance yourself from the objective. Majora's Mask and Minit were the major mechanical inspirations for this. We referenced this idea as "Not all progress is lost"-game

• A game where you helped someone through a maze. In the end, the person you helped would help you. ICO and the early section in A Link To The Past where Zelda follows you were the mechanical inspirations for this one. We referenced this idea as "Helping is worth it"-game

• A simple metroidvania with the theme around mental health. Metroidvanias are famous for being non-linear games, but I felt like the game would tend more towards the "mental health" theme than the "Healing is not linear" one. This was our "plan B" in case neither of the ones before worked out

Our first two ideas fit the jam's themes, but we weren't sure we would be able to make them mechanically engaging or fun to play. What's more, they had their own subthemes that we felt would take over during development. Without a clear creative direction, we started working on our "plan B" game, just to avoid a standstill.

But game development is also not linear.

We went home to shower and sleep. We were pumped about the jam, but not in love with our ideas. I decided I couldn't sleep before having something playable, so I went for a shower. I was thinking of nothing in particular and looking at the wall. I tried to put my mind in that child-like state of "I want to play because I'm bored". You know, the mindset that makes kids create spaceships out of cardboard boxes and chairs. I looked at a tile in the wall and felt like flicking it so it would move. If it did, I thought, it would move without friction until it hit the ceiling, like those ice-sliding block-puzzles in games. I love puzzles and I love those. It was one of the first instances in life where I realized that to achieve some objectives, you have to go in a direction that looks counter-intuitive.

But just moving a piece from point A to point B didn't feel right. It would be linear, but it wouldn't feel like healing. Putting pieces of a larger tile together though? Now that felt like healing. Fixing a whole that is broken. Putting yourself together. Mending.

It occurred to me that, if a puzzle game like this existed, then I had never heard of it. I left that shower with the game's title already decided.

The making of Mend

With the lessons I learned from my previous game jam, we started the LoJam already knowing some things about the game we would make:

• It would have to be playable in a browser so that the most amount of people could play it.

• It would have intuitive controls. It would have to be simple enough that I could send the link to my mom and she would play without me having to explain anything.

• It would be playable, finishable and somewhat polished. This is a very bold target to have for a game jam, but I think it's an important one.

What went right

After I left the shower with the idea, I shared it with Lyssa and we got to work on it. Four hours later, around 3 a.m., we had a playable prototype of the game. There were only 4 pieces to put together and the game wouldn't acknowledge when all the pieces were together, but we could play it and "complete" it. More importantly...

1. We beelined to the simplest playable version possible

Doing this allowed us to play our game very early on. If there's something I have learned from all the game projects I've worked on, is that playing your own game is a very important part of the process. It keeps it going. It lets you iterate faster. And the earlier you can play your game, the sooner you can evaluate the core concept. By the time we played the prototype, we knew that spending the first 6 hours of a 48 hours jam just choosing the idea had been worth it. Because...

2. We had a strong creative direction

For us, we really wanted a game that fit the theme. Having that strong sense of what we wanted really sped up design decisions. Whatever didn't fit got cut very fast, like a scoring system or a limited number of moves. This ended up saving us a lot of time, enough to make up for the 6 hours spent trying to come up with the idea.

3. The ebb and flow of code entropy

As programmers, we can recognize and love elegant solutions. We want our code to be clean, concise and efficient. But code like that takes time. And game development - especially in a 48 hours jam - requires fast iteration. These two ideas conflict each other, but I didn't have to choose between them. So I focused on writing code that was straightforward, brute-force-y and reliable. Very far from efficient or elegant, but almost every single feature I added this way worked right out of the gate and let me go on to test it. But if I kept doing this, it would eventually reach a tipping point and collapse onto itself. So, every 12 hours or so, I stopped at a good playable version and went to town refactoring code. It probably took me around 1 to 2 hours each time, but I am absolutely sure it was worth every minute

What could've been better

I wouldn't go as far as saying this "went wrong" (because we're happy with how it turned out) but it's for sure the game's biggest flaw and the most common negative feedback we've received: the game was too easy.

The original idea was to have a 3 by 3 block that you had to piece together. Our first playable version had a 2 by 2 block, which made the game very simple to make, but also very simple to play. Maybe too simple to play. One of our design principles was that our game had to be always winnable. Introducing the 3 by 3 block pieces could lead to unsolvable situations, but with 2 by 2, the game guaranteed always to be solvable.

So, about 24 hours into the jam, that left us with a choice. Our two major remaining goals were polishing the game and implementing the 3 by 3 gameplay. We could do one of them for sure, but maybe not both. We had to decide which one to do first, knowing we might have to sacrifice the other.

We took the safe route and started polishing, even without the "main" gameplay, the 3 by 3 version, being ready. We added alternative control schemes, input buffering, more animations and better tweens. We focused on getting the game feel relaxing and the objective of the game obvious without any text.

If this sounds like putting the cart before the horse, that's because it is. And normally, we would never do that. But this game was special for me and my girlfriend: it was our first game together. We both wanted it playable and polished.

Conclusion

It was a great game jam experience and we worked hard to make sure everything about the game fit the theme. In the end, we ended up pretty happy with Mend and we already have plans for a complete version.

You can read more about Mend and how it tries to show its theme through mechanics here.