My Friends the Monster Trainers is Jamwitch’s award-nominated (had to get that in there) Pokemon-inspired narrative deduction game, created for Ludum Dare 58. In this devlog, I’ll give an overview of its development, some narrative deduction thoughts, and what’s next. 

Narrative deduction thoughts

Pokemon x deduction

Narrative deduction games, like The Return of the Obra Dinn and The Roottrees are Dead, are my current favorite genre - I wrote a Bluesky thread about my love for them and previously wrote about them in a The Case of the Dungeon Descent devlog.

Going into LD, I knew the other half of Jamwitch, Rose, wouldn't have much time to participate, so I planned to make a text-focused game. When the theme was revealed, it was right up our alley: “collector” brings to mind cute creatures and nostalgic games for us like Pokemon and Dragon Warrior Monsters. I realized there was a great fit between deduction game fill-in-the-blank mechanics and the nerdy excitement of poring over a Pokedex, like Rose and I did with the red Pokedex book we had as kids.

Search vs batch evidence

In games like Her Story and Roottrees, you search through a database of evidence to find your next clue. I happen to love this mechanic - discovering something via search, whether via deduction or serendipity, feels amazing.

On the non-search side, there's a few ways you could get your evidence:

1. Have all the evidence you need from the start (which is an intimidating but exciting prospect - [CLASSIFIED] of 2015 is a great example)
2. Have all the answer slots available, but unlock evidence in batches (Rivals and other Owlskip games use this)
3. Play through distinct cases with their own evidence and answer slots (as in the Golden Idol lineage)

Although I love search, when I play games like A Case of Fraud that have batched evidence, I also really enjoy the excitement of getting a new stack of evidence to dig through! It’s another example of narrative deduction synergy: I’m eager to learn more about the story and characters, and also eager to see what clues I can find.

I think option 2 has a lot of strengths: it's a fun challenge to figure out what goes where in the whole answer space, but searching the evidence is not too overwhelming. The narrative unfolds in a structured way - which is less cool than "everything's there the whole time", but easier to create!

To keep things straightforward for me and approachable for players, I took the batch approach for MFTMT.

Validation and brute forcing

The Return of the Obra Dinn's innovation of requiring three correct answers to lock in deductions is a great solution to players being tempted to brute force. I planned to take the same approach for MFTMT - which has very few options for each dropdown, making brute forcing easy and tempting.

But when I tried waiting for three correct monsters to lock in, it made the start of the game feel too unfriendly. It didn't feel like you were making progress, and it was too hard to tell if you were supposed to get a monster like Ignine and were missing something, or if you weren't able to solve it yet. I want MFTMT to feel approachable and rewarding, so I decided to validate per monster, so you get that ongoing feeling of accomplishment.

In the jam version, a monster would immediately lock in once you had it correct, but in a subsequent update I added a Validate button that takes a bit of time instead. This is at least one point of friction to make brute forcing less tempting.

"Is this cheating?"

MFTMT relies a lot on Pokemon tropes, so there's plenty of opportunities to make guesses based on vibes rather than picking up a specific hard deductive clue from the letters: what elements a monster might be, what it might look like based on its name, what its habitat might be based on its appearance.

I don't think solving based on vibes is a bad thing in itself - it still means you're thinking about the story and setting and what makes sense in this world. I had a similar experience guessing on some characters in a version of Funeral for the Sun's demo - it actually felt great, like I was on the same wavelength as the storytelling, to be able to guess correctly despite insufficient hard clues.

But the problem comes when players have to ask themselves "Is it cheating to put that?" or don't enter something because they're "not supposed to" until they have a hard clue. Regardless of whether solving with vibes is good or bad, it's disruptive to the experience to have a mismatch between the expectations for how gameplay is supposed to go and a way to succeed at the game.

After finishing the game, I watched Jackson Nagy's talk on Stumbling in puzzle games. He discussed how players will learn a pattern and keep applying it just in case they stumble onto the answer; he recommended having an early level that subverts that pattern, so that players learn they can't rely on it. It's tempting to save subversions for later, but adding them earlier spices up subsequent levels.

I think that would be a good way to address it for MFTMT if I ever revisited the monsters and puzzles: instead of always playing into tropes, have a couple puzzles close to the start of the game where your expectations are subverted. Those would be fun to solve and would put players on their guard to also confirm their vibes with evidence.

Making the game

Writing the game

One advantage of the jam timeframe is you don’t have time to second-guess! After coming up with the game concept and the character ideas, I decided the monsters would belong to five elements (later alignments), and quickly brainstormed some ideas for monsters fitting those elements .

I used temporary names for most of the writing process, before enlisting my talented husband Hunter to help me come up with more meaningful Pokemon-like names. Meanwhile, Rose was drawing pixel sprites for each. If we had more time to be creative, I think the monsters could have had a bit more interesting concepts and designs - more interesting than "fire dog" or "phoenix", for instance.

After settling on a list, I outlined the plot, divided the story beats into sections, and then worked out which three monsters would be solvable per batch. With that, I could outline each letter's contents and clues, and then start writing. I had a couple interesting ideas for tricky clues, like Pharolith's alignment and guessing Malegora's moves, but was mostly hoping the process of picking out the different clues from the story would be an enjoyable process on its own.

This was the most fun I've had writing for a game! It was easy to draw on Pokemon tropes while using the clues I'd outlined as structure. I generally struggle more with dialogue than prose, which is not ideal for gamedev (although feel free to try my interactive fiction Twine wizard puzzle game!), but writing letters in characters' voices turns out to be something I enjoy - I do think Ollie and Harper's voices could be more distinct, but it felt easy to write as them, and I felt I was hitting a good balance between keeping things concise and still having enough personality and storytelling in each letter.

Alignments

The type chart showing what's good or bad against what feels like an important, crunchy element of Pokemon, so I knew that would be a good source of puzzles. I used planets and the term "alignment" to inject some flavor and make it a tiny step less obvious what type goes with what monster.

 I liked the idea of a cycle, like an elemental cycle or a weapons triangle, because it feels neat and lets you deduce some relationships based on ones you're sure about. (If it were a grid where each alignment has an unknown number of relationships, each one would have to be clued in some way, which could get tedious.) One cycle seemed too straightforward, so I decided to have two strengths per alignment.

As I got into the weeds of the alignment puzzles like Pharolith, though, I started to regret how dense this is - every alignment has a relationship with every other alignment, so lots of potential combinations look really similar when you take the net effect. I'm not sure what would be better here. Maybe six alignments so there are some neutrals as well?

Coding the game

Like most of my jam games, MFTMT was built in plain HTML/Javascript: it's straightforward, fast for me to work with, and works well for UI/text-based games. The code is definitely game jam-y, but I was careful to keep my state separate from the UI - I have one big `showPage` method that's in charge of setting all of the classes, display styles, and dropdown setups for a given page state, which I call any time there's a risk the state changed. It's not very efficient compared to a real UI framework, but it made it easy to catch bugs in rendering separately from bugs in state.

Jamwitch's typical jam process is:

1. Brainstorming, outlining, etc
2. Code a prototype UI
3. Create the content and gameplay, test in the prototype
4. New UI; polish, polish, polish

When Rose has the whole weekend to devote to a jam, we can parallelize these steps and she can bring her UX skills to bear, but for MFTMT, I had to give it my best shot. I'm pretty happy with my Pokedex and mailbox, which are completely CSS.

Prototype:

Final post-jam:

By the way, I really wanted to give Harper and Ollie distinct handwriting, but I found all the fonts I tried were harder to read than my pick, Playpen Sans. I knew players would have to skim back over past letters, so legibility is really important. (I also couldn't find nice-looking colors to have a different paper color!)

I do think that orienting yourself in the social context of a new piece of evidence is a fun part of deduction games, so I feel like a moment of "Who wrote this? Ah, it sounds like Harper" could be even be a positive - but let me know what you think.

Updates

Korean translation coming soon

Erica was kind enough to offer to do a Korean translation of MFTMT! That's in progress now and will be ready in January. I really appreciate Erica reaching out and I'm excited that some new players might be able to enjoy it!

Thinky Award nomination

I'm really happy that people have been enjoying MFTMT! Not only was it chosen as a Thinky Games Club pick, but it was nominated for a Thinky Award for Best Free Game. Jamwitch has been making small games for a long time, and it's always really wonderful to hear when people enjoy them, but getting an official nod from the puzzle game experts at Thinky Games is really special to me and I'm super grateful to the Thinky Games site and community. 💛

What's next

I'm happy with MFTMT and I think it works well for the time and skills we had to make it, but I can also imagine a lot of great improvements:

• Each batch of letters could come with a snapshot picture from the characters' adventures. I'm imagining you can use these to capture images of the monsters, Roottrees style, and that the pictures would be a new source of visual clues that work together with the letter clues.
• The monster designs, alignment setup, and worldbuilding could use more thought to make them distinctive and fun to solve. One idea someone mentioned that I loved would be to include a Pokemon-game-style map of the world to help you stay oriented.
• And of course, there could be more monsters and more story for our intrepid heroes.

Because the reception of the game has been great, it's tempting to plan to expand it. I would love for more people to find the game or to consider it on their list of deduction games. But that's also a daunting task - Rose will be very busy for the near future and I have lots of others things I'm focused on (like The Daily Spell!) Putting together a larger game sounds like a lot of work that's not the fun part of designing and coding a game.

So the question is, do I follow the model of amazing solo devs like Hesperus Games making their own games, or do I follow the model of Type Help and just keep making small games until I make one good enough that someone else volunteers for the not-fun part?? 😄 I'm aware that's not a realistic path, but continuing to make small games is what I would like to do anyway, so maybe I'll stick to that.

I'm definitely still pondering this question and will see how things go!

This was a long devlog, but I'm too busy to make it shorter! So if you read all of it, thank you! 💜