Making of Counterfeit Monkey: Puzzles and Toys

This is the first of a couple of making-of posts about Counterfeit Monkey, in case people are interested: these are a bit like some of the making-of material I’ve published about Bronze and other games, but I’m splitting it up between story discussion and puzzle discussion.

We’ll start with puzzles. This is going to be spoilery, so if you’re still planning to play, I recommend finishing the game first.

Systematic Mechanic

I’ve ranted before about the value of a systematic mechanic for IF, rather than a hodgepodge of unrelated puzzles. In this case, the mechanic was one I borrowed from an earlier concept — the T-remover in Leather Goddesses of Phobos — but I realized when I started playing with it that modern computing power and the existence of regular expressions could do very much more than the original puzzle ever touched. This one kind of fell into my lap.

Actually, several of the systems I’ve used over the years have been the result of wishing that some other game would really run with an idea they briefly introduced. The time-manipulation mechanic of Indigo was inspired by the stasis-bound apple in Dreamhold. I don’t really remember where the idea for the Lavori d’Aracne came from; that might have been more down to courses in ancient religion and magic than to some other game.

A productive systematic mechanic, for me, is one that

• suggests multiple interesting permutations (e.g., different types of link in the Lavori universe, removal vs insertion tools in Monkey) that can be introduced gradually
• can be implemented with general rules of the world model rather than a heap of special cases
• has clear and readily expressible failure outcomes: if the player tries to do something that might be in-bounds, but isn’t, can we easily and consistently articulate why?

The time manipulation in Indigo doesn’t really live up to all those, which is why a little speed-IF pretty much got it out of my system: I couldn’t think of lots else to do besides aging and de-aging things; the results of aging or de-aging individual items always had to be hand-coded; failure states would also have to be hand-coded. That’s a system for a little game.

By contrast, Monkey‘s letter manipulation suggested lots and lots of possible variations — in fact I thought of way more letter tools than actually appear in the game — and using indexed text, it would be easy to give feedback to the player about what a particular letter transformation had done and why that might be a failure. But I was still concerned that it would be possible to make puzzles that were just too hard to solve. In my view, pretty much anyone can come up with a hard puzzle; what takes skill is writing a reasonably easy but not boring one. So how to do that?

Idea to Implementation

For Counterfeit Monkey I used the design plan I talk about in my article on Idea to Implementation — create the system, then build a throughline plot that takes you all the way to the end, then revise and elaborate as appropriate. That was useful for lots of reasons, both story and puzzle; it meant the game was more evenly implemented throughout than most of my other long projects, and also that it was possible to do revisions in light of how they’d affect the overall story and puzzle arc, rather than writing some middle game and then poking at the middle game uncertainly a lot before writing an endgame in exhaustion and haste.

Another piece of practice that helped a lot was explicitly writing down my design goals whenever I was brainstorming new features. I started doing this in contexts where I was trying to communicate with collaborators, but I found that it was really useful even for this completely private project where no one was involved by myself.

It works equally well as a problem-solving device partway through a project. Find something you don’t like about your game? Stop, write down what you don’t like, write down what you want it to do, write down any principles you can think of that would help you achieve your mission statement. By the time you’ve walked yourself through that process, you’re a lot more likely to have thought of a solution.

One thing I did was come up with some specific principles about the kinds of puzzles that could go into Monkey.

Puzzle Discipline

This is the puzzle chart for a release version of Counterfeit Monkey. (No guarantee I won’t slightly alter it in future releases.)

I started this chart almost at the beginning of the project and revised it throughout, relying on it not only for structural guidance but more generally to enforce discipline in the design. It would have been really easy to make puzzles using this mechanic that were just way too hard, requiring too much lateral thinking. It’s possible in this game to turn a crate into tea (CRATE > RATE > TEAR > TEA), but that doesn’t mean that all puzzles involving needing a cup of tea would be remotely fair.

So I came up with three basic categories of puzzle I considered fair in this context:

• those where you know what you have to change, but you don’t know what to change it into, e.g. needing to reform the PLANS into another object when they’re too large to hide from someone.
• those where you know what you have to create, but you don’t know from what: e.g. needing to get some OIL but not knowing what the source will be.
• those where you have clear instructions about a general category of thing you need, and there are multiple makeable items that would fall into that category, e.g. needing something that makes noise.

I established a color code for these puzzles and made a rule for myself. It was okay if a puzzle fell into two of these categories at once — e.g. the ODOR > DOOR puzzle where you could clearly guess both the to and from states, and which wasn’t meant to be hard. A box could have multiple colors. But if a puzzle I was working on didn’t fall into any of those categories and I couldn’t think how to color it on the chart, that meant it was probably not going to be a fair puzzle and I should revise or remove it.

The puzzle chart was also very handy for designing hard mode, because I could see which solutions had lots of possible solutions and then figure out a way to disable those solutions that testers were using most often — thus forcing players into the less-obvious routes. Puzzle steps that are only available in easy mode have a double outline stroke to distinguish them.

The puzzle chart also shows alternate solution paths, using dashed rather than solid lines where a solution is just one of several possibilities, and dotted lines where something provides an important nudge or clue even if it’s not an alternate solution.

During the first portion of the game, I wanted to minimize the chance the player would get stuck before understanding the mechanic or becoming invested in the story. So for the puzzles in the early game — getting the gel, finding the monocle, opening the locker — progress in one is meant to help with the others. If you get the locker open before reclaiming the monocle, you can use money to buy a ticket to the cinema. If you find the monocle first, looking through the monocle will give a clue about how the locker puzzle works.

Later puzzles are less generous in this sense, but I wanted to work against the problem I had with the beginning of Savoir-Faire, the extremely steep learning curve in a world whose rules aren’t the same as our own.

Removals

In my experience, when you write a big puzzle game, you often wind up with enough remnants to write a couple of additional small toy games — which is part of why Damnatio Memoriae exists, to cover things that Savoir-Faire couldn’t accommodate. I came away from Monkey with a number of puzzle ideas I think are perfectly good, but just didn’t have a place in the narrative.

But there’s also a fair amount of stuff that turns out not to be good in any context, which just needs to be cut out and thrown away.

Even with the systematic mechanic in mind and clear puzzle rules in place, I came up with my fair share of dud content. During the writing, I got rid of a number of lengthy sequences, including an appointment with a vet who had been S-inserted into a VEST by thugs; a translation wand that could change items into foreign-named versions of themselves; a letter-altering sculpture in the Fleur d’Or that you could only use after you’d distracted the staff; and a can of PAINT that could be borrowed or stolen from Professor Higgate and then turned into PINT, PANT, PAIN, etc. In the source code, there are significant numbers of things that are commented out, permanently disabled but not actually deleted in case I someday want that code again — including the entirety of the turntable tool, which would perform a CAR -> ARC or PEA -> APE transformation. (This is obviously just a subset of anagramming, but it was meant to be available before the anagramming gun was.)

Some of these things were bad because they were hard to clue to the player, or because they had exactly one use in game. Some were bad because they felt contrived, or didn’t fit the fiction as well as I liked, or required the player character to be too mean to fit the rest of the character concept.

Some were bad for less obvious reasons. Hahn is the German word for rooster, so that was the outcome of using the foreign-language wand on the COCK. This was unpredictable (even if you know German, you didn’t know which foreign language was going to be invoked in a particular transformation) without being delightful (the way the anagramming gun can sometimes produce amusing or startling outcomes) or promising (what exciting new thing could you do with an object called HAHN? Nothing, other than use it for the one foreign-language-object puzzle in the game). So this was a transformation that offered the player neither agency nor entertainment. And it also required a lot of special-case coding, unlike most other language effects.

It was, I think, fair — that is, there were plenty of clues that you needed an animal in a foreign language, you had this wand, you had an animal, etc. — but that didn’t mean it was a fun puzzle.

Insertions

Conversely, I put a number of puzzle elements into the game fairly late.

Once I knew that the culminating battle was going to involve Atlantida, the restoration gel rifle, and the anagramming gun, I knew that I wanted to introduce each of those concepts to the player at some point earlier in the game, so I put in the traffic circle scene. There were story motivations for that too, of course — but they could have been served with different machinery if necessary.

Similarly, originally the origin paste was introduced at the Counterfeit Monkey and then largely forgotten about until the player needed to use it on the pass to get into the Bureau, so I added a couple more puzzles that required either using it (the car at the traffic circle) or remembering that it existed (the dead drop) in order to make sure the player had it down.

The CODEX puzzle also came in very late. The balance beam and other puzzles around the park had been there from the beginning, but in playtesting I found that testers wandered around the broad open area, not sure what to work on or how. So I realized I needed to confront them, even before that segment, with a challenge that was as glaringly obvious as I could make it. Which is to say, still not necessarily totally obvious to everyone. One thing about working with a systematic puzzle mechanic is that once you get fluent in that system as an author, you forget how not-obvious it might seem to new players; so it’s easy to make even your simple puzzles too difficult.

A bunch of other specifics of game archaeology can be found in the source, but the point here is that, once I had the basic puzzle structure in place, the puzzle changes were typically either making the early game easier, or adding elements that would better prepare the player for late-game puzzles.

A World of Toys

Obviously, a big part of writing Counterfeit Monkey was the creation of bazillions of objects, some of which had no inherent purpose in the game world but existed only because the rules required they must — or because they were an intermediate step between an original object and something else that would be genuinely useful.

Nonetheless, I felt strongly that the descriptions of these objects should always be entertaining or funny or surprising or cool or reveal some bit of backstory. Every single thing the player makes should feel like a reward — a reward for having been clever enough to think of making it.

Not every possible dictionary object is easy to make interesting. There are still some items in the collection that are on the duller side, but when stuck, I asked myself these questions to help me come up with a non-perfunctory answer that would actually support the narrative:

• how might this particular object be different in Atlantis than elsewhere? What would local expectations be about this kind of thing?
• supposing that the object creation is affected by the fact that it’s Alex or Andra performing the transformation, what might the object reveal about them, or make them remember?

If I couldn’t come up with a way to make the thing narratively cool, then could I make it fun?

• how might this object be interestingly randomized?
• how can this object make surprising use of generated text, procedural description, or variable output?

Abstracts in particular are meant to be changeable, but even non-abstract objects got specialized handling in some cases. In practice, this meant that I spent a lot of time — days, in some cases — on objects that many players will never see, such as the film reel or the TALE object. But this was fun to do, and I felt that although most players would not see everything, most players would see at least some improbably detailed rare objects — and that would justify the effort.

This comes back to the other formative influence on Monkey, which is the amount of time I spent not working on it. It was four or more years in progress. I can’t even verify for sure when I started working on it, but sometime before October 2008. In that time I changed careers, freelanced for a while, moved house twice, helped start a company, sold the company, dealt with multiple major family crises, spent significant time out of the country, got engaged, and started an international immigration process. There were months at a time when I didn’t look at Monkey at all.

Whenever I did take it up again, it was usually vacation time or a lull in freelance load, and sometimes what I wanted from it as a project was to entertain me, to be a playful breather from crunchy, deadline-heavy work projects or external stress. I always felt fairly sure that it would be finishable when I needed it to be, because from very early on, there was a playable throughline plot in place. On the other hand, I had no specific deadline I had to meet. That meant that if I wanted to spend eight hours writing some code to spit out randomly generated silent movie scripts, that was what I was going to do.

Result: Monkey was a lot more fun to write than most other IF projects I’ve worked on.

That’s not to say I didn’t struggle with it in some ways — I did, as I allude to in veiled terms here — but most of that comes under the heading of theme and story. About which more later.