Play as a skeletal humanoid creature in an eerie woodland environment. Scared of the dark, you can only move within the ring of light from your campfire. Gather resources to keep it alight or to build more campfires, whilst also defending them (and yourself) from the predators that roam the area.

Development

An artist, a programmer, and a musician have dreams of making games. They find each other and they find Ludum Dare and they think, “Yes, let’s do this!” So they do this.

On the first morning of the 72 hour game jam, the three of us met in my apartment to determine our roles, brainstorm, and get to work. There was me, the artist and narrative designer in charge of creating all the visual assets and developing the narrative overlay of the game. There was our musician, who was in charge of developing the music and sound effects. And there was our programmer, who was in charge of building the game in Godot, and then taking our assets and putting everything together.

We started the morning brainstorming over pastries and coffee, first working individually before throwing our ideas around and fleshing them out together. We spent too long discussing minor details and developing ideas that we inevitably abandoned. Eventually, we realised we needed to take it back to basics and determine what exactly it would mean to play the game. I came up with the following chart to better organise our thoughts:

After we’d decided on a survivalist horror themed game, we fleshed it out like so:

With this clarity, we could finally start. The next two days were a supercharged bubble of intense work, bouncing between quietly progressing on our individual responsibilities and regrouping to check-in and discuss before returning to iterate on our individual work again.

Lessons & Insights

Use multiple references

While we were still brainstorming, someone casually mentioned Don’t Starve as a passing reference. My subconscious mind latched onto it and created something that was accidentally reminiscent of the game, something that was picked up by many of our players. To capture and recreate the feeling of a great and successful game is no bad thing, but it wasn’t done deliberately and it would have been better to create something that wasn’t quite so derivative. This highlighted the importance of being aware of what you’re drawing from and to ideally go beyond the first source that comes to mind.

Determine the visual language beforehand

Creating visual assets for a game is so different to any other kind of art. You’re creating all these different pieces that have to look like they all belong together, as though they all come from the same world. It’s not like creating different pieces of clothing for the same collection, or jewellery or paintings. Instead, it’s clothing AND objects AND creatures AND paintings AND the entire world itself. So maintaining that visual consistency was something I struggled with. Practice and experience would have helped, but really I should have taken the time at the beginning to fully define the visual style - everything from colours and line weights, to simple shapes and relative sizes.

Leave time to play-test

I cannot stress this enough, play-testing should be a priority, even with tiny game-jam games. Make sure there’s time to see the “final” build and to make changes long before the submission deadline. This little readjustment of time allocation would have saved us from many a painful and half-hearted, “Yeah, it’s fine. Just upload it.”

Clear instructions are useful

It’s fun to play with words and create cryptic clues for how to play a game, but maybe, when there isn’t enough time to create elaborate, integrated tutorial sequences, it’s better to just tell players how to play, clearly and without fluff.

Feedback is addictive

The best reason for participating in these jams was for the comments. There’s something intoxicating about reading what someone thought about the thing you just made. The nice comments boost your ego and validate what you’re doing, which is nice, but the criticism is where the beauty lies: it’s where you realise how differently people can experience the same thing, it’s where you discover problems that never occurred to you, and it’s where you realise that you couldn’t get away with the bug or detail that you thought no-one would notice or care about. It’s the reason that doing the game for ourselves wasn’t enough - we had to get it out there.

Teamwork makes the dream work

Making a game is fun. Making a game with friends is the most fun. Bouncing ideas off each other, collaborating creatively, and working together to make something that you’re all invested in is an incredible experience. The dynamics are also fascinating: it’s a great challenge to learn what drives each member, to understand how they approach problems, and to know when to push them further and when to rein them in.

A narrative designer is a legitimate thing

At one point, our programer pointed out that I was being too much like a film director, obsessing over things like story and theme and how they tie into the mechanics. I think he meant it as a complaint, but I took it as the biggest compliment. Months later, when I learned more about the different roles involved in game development, I realised that actually, I was being a narrative designer and it was normal for me to be so much more excited about the narrative elements of the game than they were. Apparently, the role of a narrative designer is not usually well-understood or appreciated by other game dev members. I see his comment as my initiation into the field.