Our team of five created Life in Small Steps, a narrative and puzzle game, in five months. These are our thoughts about the process, about what went right and what could have gone better. We hope these insights will be helpful to future-us and other aspiring game developers.

Aiming at a polished game from start

From the start, our goal was to develop a polished, complete game, rather than the playable but wonky experience that usually comes out of jams.

We settled on four criteria for what we considered a “polished” product:

• design-wise: no testers who are lost, or who do not understand the logic of what’s happening in the game ;
• design-wise: the game is fluid and the whole system, visual and audio, is coherent and puts the player in the desired state of mind ;
• programmation-wise: the game runs in its entirety on all platforms it can reasonably be expected to run on, there is no bug when doing “regular” game and no game-breaking bug when trying to drive the game into a corner ;
• generally speaking, no more “low-hanging fruits” in the to-do list, no task left over that would be quick to do and would improve the game.

This influenced the scope and the way we planned the project in order to have time to polish the various features before the deadline. It also impacted our choices regarding game mechanics, because we only kept the features we knew we would be able to refine, and scrapped the rest.

Of course, the game is not perfect and there are always some things that we would have done differently, better, given a few more months. But overall, this approach led us to a game we feel accomplished and proud about.

Short development cycles and early and frequent playtests.

It might seem obvious to experienced game developers, but playtesting and iterative development is underdeveloped in amateur game development. For Life In Small Steps, we knew from the start that we had some key gameplay concepts to validate, and so we decided to organise our work to be able to playtest early and often.

How did we do that? We structured our workload into 2-week milestones, or runs. As much as we could, we picked the tasks for each milestone so that it corresponded to a vertical slice (a small playable demo of the game built around a specific feature).

Our first milestone was a proof-of-concept of our basic puzzle, our second one was a demo of our narrative scene, our third one added the gameplay variations on the puzzle (and music), …

This system allowed us to quickly evaluate features inside the team, and most importantly to test early and often. When I say early, I mean that we already had outsiders playtesting the game after our first 2-week iteration. And we got valuable feedback from the start of puzzle difficulty, UI design, and the future links between narration and puzzles. From there, we tried to test often, but the time it took for playtesters to get back to us, usually around one week, slowed this down a bit compared to what we had planned. We still carried out three full rounds of alpha testing (on vertical slices) and two of beta testing (on the complete start-to-finish prototype).

Playtesting shaped the game. In addition to many small adjustments to art, music, accessibility features, writing, etc, it drove us to make two major changes to the game.

The first one is easy to understand: we had to rework most puzzles because our first batches of design were far too difficult. This was due to the inner workings of our team: the first tester of all puzzles was our programmer, who had a knack for logical puzzles and set the bar too high for most players. In addition to being objectively too difficult, the puzzles also lacked a sense of progression. Because we wanted the difficulty tied to the narrative, rather than a classic, easy-to-hard progression, we originally missed designing for progression inside each chapter. In the final game, inside a given chapter, each puzzle now builds up on the previous one.

The second major change we made to the game was to go from non-linear to linear gameplay. Life In Small Steps is a game about the impact of mental illnesses and medication on cognitive abilities. To highlight this, we wanted the player to be able to choose how difficult their puzzles were by choosing a mental state and whether the character has taken medication or not. Playtests revealed that this mechanic was not understood by players at all. They felt like the puzzles were arbitrarily hard or easy, which was the opposite of what we wanted.

We tried several things to make the link clearer. We tried to clarify the process in the dialogue at the start of the game. We introduced a new, separate screen whose sole function was to pick the character’s mental state and medication, to show that the puzzle changed depending on what was picked. We decided to let the player only pick the medication, with the mental state being already determined, thinking it might be more immersive because in real life, you can choose to take emergency meds, but you cannot choose bad days. It was very clear from the playtests that all this failed. And even if we were not one hundred percent sure of these mechanics (hence the early testing), we could not have predicted how badly it was perceived by players.

Because we were operating on short development cycles, pivoting at this point, at the beginning of the third month, was not as difficult as we could have anticipated. Once we had determined that the best solution was to go with a linear narration and puzzle design, we were able to quickly scrap the now-unused parts of the project, and test our new concept.

For those who are worried that 2-week development cycles might end up being a constant crunch, it’s important to keep in mind that we picked our tasks for each cycle to avoid exactly that. Some cycles were busier than others, especially for our programmer, and, at the end, our composer, but generally speaking we managed to avoid crunching by communicating a lot about our availability, and having a good vision of what we were each able to do in a given time. Sometimes we even underscoped a milestone, but it turned out to be okay too because we had a global vision of where we wanted to go, and could always pull from the backlog of “future tasks”.

A jam about mental health

Life In Small Step was created for the game jam “Mental Health Game Dev Champions 2024” from Safe in Our World. This jam was aimed at “empowering gamers and developers to create thought-provoking experiences, around the theme of mental health”.

Mental health is a very wide theme, and one that is close to each of our hearts in different ways.

A fun game about serious matters

One of the struggles we encountered with Life In Small Steps was to make a game about a serious topic that wasn’t a “serious game”.

One factor was that our game has a lot of text, but none of the typical visual novel gameplay mechanics to make the narration non-linear. We found that adding voice acting, something we had originally chosen to do for accessibility purposes, made the narrative sections of the game a lot more lively. Compared to our initial plans, we also had to add small narrative bits to the puzzle sections, to tie everything together.

Another factor was the difficulty of the puzzles, and how that was tied to the narrative. Initially, we wanted the player to be able to pick the difficulty through narrative choices, to make the game more interactive and to highlight the message of our game through gameplay. However, after testing a couple of designs for this mechanic, we had to drop it because it seemed too obscure for players: they ended up facing (seemingly) arbitrarily hard or easy puzzles, which went against the narrative we were trying to weave.

Finding the right mechanics and balance to make an entertaining game about a serious topic was our biggest design challenge with Life In Small Steps.

An emergent auto-fiction

Our game ended up being a work of auto-fiction, but it was never a conscious choice. The topic we had chosen within the mental health theme, the cognitive impacts of long-term mental illness, was one personally familiar to our writer. As such, it felt natural for them to draw from their experiences to write the game. It also alleviated the need for research.

However, this non-choice came with its own challenges. For example, coming up with a character that was specific enough to feel relatable, but generic enough to represent the experience of many. Or writing dialogues for a psychiatrist that could not be construed as medical advice, even if the scene was about the psychiatrist character giving medical advice.

It might have been easier to approach those challenges if we had identified that we were working with an auto-fiction earlier on.

Other takeaways

• Give everyone room to pitch in
  We did not adhere to strict roles. Instead, each person was lead for one or more aspects of the game, but the others were invited to pitch in regularly, either to get feedback on creative aspects, to prioritise features, or even to design new puzzles. It made for a pleasant working environment where everyone felt empowered, and it allowed us to push the game further than we would have with strict roles.
• Invest in tools
  We invested time setting up tools, in particular Codecks and github, so people who weren’t programmers were able to use it too. Our composer, in particular, took advantage of github to make iterating on assets a lot easier. We also developed our own puzzle editor when it became obvious that designing only with pen-and-paper would be limiting. It allowed people other than the designated designer to help conceive puzzles and iterate quickly on existing designs.
• Plan for accessibility from the start
  This is a very common advice for people showing an interest in making more accessible games, and yet it is usually ignored. Planning accessibility features from the start, even if some are only implemented in the end, tremendously lowers the cost of those. For example, you wouldn’t design and program a character’s movement the same if you know players will have the option of making infinite jumps. We listed the accessibility features we wanted in the final game as soon as we had confirmed our core concepts, and were able to implement about 90% of them before the end of the jam.
• Take local holidays and festivals into account
  Because we had an international team, we did not know of each other’s specific holidays and other festive periods. This led to a lot of stress and some crunch for our composer, who had to work around several Indian festivals over the month of October. Going around the table at the start and having everyone identify periods of the year when they might not be available would have been most helpful.
• Invest in voice acting
  We had originally planned to add voice acting mainly as a precious accessibility feature. However, once the voice was added to the game, it became obvious that it brought much more than that.
Something that we could have done better, to make the voice acting shine even more, was start recording a bit earlier even if the text wasn’t entirely final. It would have made the process less stressful, and would have enabled us to fine-tune some lines.