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.
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.
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.
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.
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.
26 thoughts on “Making of Counterfeit Monkey: Puzzles and Toys”
One of the things I really like about the way the puzzle-structure of the game works is the gradual introduction of more powerful tools. This is something that a lot of different games do, of course, but I think it’s particularly effective here—it’s not just about levelling up and getting a bigger sword (or even bigger words). It’s intimately tied to how the player gets to know Anglophone Atlantis; once we’ve figured out how to use one kind of tool well enough, we get a new set of possibilities, and the puzzles can get more complex because they require us to figure out which one (or combination) of them we need. Each new one felt like a significant reward, and I think your concept of “a world of toys” played a big part in making that true. The original restrictions on the letter-remover (no abstracts, no animates) seemed to me like eminently sensible constraints, both in-universe and from the point of view of making the game-designer’s job tractable. Dayenu! When they were removed, I had a sense of the game world expanding tremendously. (This is similar to, but I think more profound than, the way single locations on the map turn out to have complex internal structure once Alexandra actually gets to them.) By the endgame, when I was doing things like turning the Catalan punt volat needle into an untalented naval polecat, the only thing that was stopping me from just trying every transformation I could think of for the sake of reading the descriptions was the sense of urgency in the narrative. And after successfully finishing the game, I did go back and do just that. (This included, I am ashamed to admit, putting the canola-oil plant on the dais and setting it to “swap homonym.” Well, I was sure that any response you had programmed in would be tasteful and appropriate, and as it turned out, it didn’t do anything. I think perhaps it ought to produce a mock-epic by Alexander Pope, or some suitable Atlantean analogue thereof.)
Above all, I’m very glad to hear that you had fun creating Counterfeit Monkey; that was certainly the impression I got from playing it, and it’s good to know that the sense of delight in this world and its possibilities was real. I hope you will often have time to work on deadline-free projects like this for your own entertainment!
The original restrictions on the letter-remover (no abstracts, no animates) seemed to me like eminently sensible constraints, both in-universe and from the point of view of making the game-designer’s job tractable.
Yeah, that was an intentional bit of misdirection. Probably not all players do this, but when I play IF, I tend to be very conscious of choices that limit the world model to keep it manageable. “Oh, I guess we’re not going to be able to interact with that NPC.” “Ah, okay, we can’t ever mix up the liquids from the chemistry set.” So I wanted to get people to accept certain limits on the game, because it would make it more surprising and exciting later when it turned out those limits didn’t hold. The other place I intended that effect was when the game shows the player the anagramming gun in such a context that it looks like it might be a bit of backstory only, something you’d never actually get your hands on. And of course having the anagramming gun means that suddenly you can make use of adjective-heavy objects that had previously looked useless.
Edited to add: Conversely, the game teases the existence of depluralizers, the diminutive-affixer, and one or two other items — but the reason the player never gets those is that they’d actually be something of a let-down. I spent a while trying to think of a cool puzzle involving a depluralizer, and it obviously would only be interesting if it accomplished something more significant than basically being an S-remover most of the time. I reviewed and just as quickly discarded a few options: BASES -> BASIS? This is actually where I originally thought of putting a codex in the game, because then I could use a depluralizer to make a CODICES > CODEX puzzle. But a tester popped this bubble for me by pointing out that most people don’t use the word CODICES on a regular basis and that I could not necessarily rely on my players realizing, “oh, I need a CODE, I’ll just depluralize these CODICES.” Once I’d worked out that the depluralizer wouldn’t be able to do much, I decided not to give the player one because it just wouldn’t be that awesome.
As for the diminutive affixer, I basically used up my full stock of jokes concerning such an object during the one scene where it appears.
I think perhaps it ought to produce a mock-epic by Alexander Pope, or some suitable Atlantean analogue thereof.
Yeah, you’re not the first player to suggest this. I may indeed put such a thing into a future release.
I can’t imagine you haven’t been told this, but you really should write a book.
The source text is about 250K words; will that do?
Thanks for this post. I’ll probably need to reread it to understand fully all your preparation.
I have to admit, on a very selfish level, I’m glad I pushed my game through before you pushed yours, 1) so I had 1 less excuse to junk the project and 2) so I can have an unexpected learning experience beyond what I got from writing my own game. I have to admit that most of what I learned about preparation from my own game was stuff I left out.
So your delaying this project due to Important Stuff Happening was beneficial to at least one person! It’s pretty clear how CM does and accounts for things I hadn’t considered Shuffling Around could or would do.
Very minor and tangential comment/question: Is the link to the source code, included in this post, meant to be on the game’s home page as well? At the moment the latter links only to the story file and the feelies…
I’ll add it there when I next update the game and website — which will certainly not be for a few days, because I have a lot going on in the next week. (Despite the implicit evidence, I have had less support time for CM in the last week or two than I hoped — the bulk of this post was written a little while back, and I just wanted to give people some time to play the game before talking about it.)
Is the source text ever going to be released?
It’s linked from this post and from the IFDB page, Al.
Just wondering Emily why the source text doesn’t have a link on the CM Monkey website.
Sorry Emily ingore that last question. I didn’t read a posting above mine
It really surprised me how constrained the vocabulary actually is – I somehow imagined the word list to be ten times as long.
I also really liked how even the most ridiculous created objects provided some sort of glimpse into how the world of Atlantis works. Pity the “bot” object didn’t go further into what a computer language would be like in a lexicographic world.
An interesting thing about this process was realizing how many English words are *not* at all usable this way. The most productive forms tend to be short ones where a syllable is bookended by multiple consonants, or contains multiple vowels, or both (PAINT, e.g, or PEARL), because then the combinatorics work in your favor. And then I wasn’t trying to deal with adjectives or verbs at all. Those two things considerably constrain the natural scope of the problem. Then I also deliberately designed around a few things that would have been challenging.
And for reasons of not making myself crazy, I did not include an object-copying machine (probably technically possible, but would have required fiddly dynamic object creation stuff and just been totally NOT worth it), or any kind of synonym or homophone swapper. That would have required too much hand-rolling, for one thing.
The game still totals out to about 2000 objects, which is a large number for IF, even if not a large number for lots of other forms. Reading through the output of Object Response Tests was exhausting, and I’m sure there’s stuff I missed despite doing that.
Wondering if Emily is going to release the following extensions of hers:
Include Facial Expressions
Include Threaded Conversation
Include Threaded Actions
The source text says at the top that it is there for people to enjoy reading, but that I do not expect people to recompile the game themselves and do not plan to support people doing so. (In the past this has turned out to be surprisingly time-consuming.)
The conversation extensions are being worked on by other people now, and may be released on their schedule.
Do you have the names of those working on Threaded Conversations and Threaded Actions.
It appears that those extensions use the subject object.