Hi and thanks for your interest in Nonverbal Communication!
Here’s a variety of things I wanted to share about the process of creating and improving the game, in case others might find them fun or useful.
There will be spoilers! I strongly recommend playing the game before reading this (about 30 minutes of playtime).
The previous release can still be played on the Spring Thing website, for the time being, and I’ve also uploaded the latest version here:
Nonverbal Communication — itch.io — play online
(Note for the latter page: it looks fine on my end, but my husband reports that on his devices the itch UI overlaps with the game! Clicking the bottom-right fullscreen button should help.)
And here’s the gblorb file itself:
Nonverbal Communication (May 12).gblorb (655.9 KB)
I’ll submit a post-comp version to the IF Archive soon, so that I can update the IFDB page with a new “Play On-Line” link.
Why make Nonverbal Communication?
I’d been doing some thinking about text parser games and their essential components, and it struck me that verbs are the all-important core of the player’s interaction with the parser world. I began to wonder, what would a parser game without verbs look like? Could it even work?
The first step of entertaining that possibility was to rethink the player character’s relationship to its environment: much of the agency would need to be transferred from the player to NPCs. But how do we justify this lack of agency or the obedience of said NPCs?
A few possibilities came to mind, and for a while I entertained the idea of a baby who can only say a few words and has to rely on adults for actions — maybe Mom takes you places, Dad gives you objects, etc. I figured the use of SAY might be a necessary evil, tampered a bit by the ability to speak directly to the parser without having to specify the verb every time (as SAY would be assumed except for meta-commands).
But ultimately I fell in love with the “word mage” concept, and the fantasy setting allowed me to do away with SAY after all. This left only non-essential courtesy verbs like WAIT or THINK, and meta verbs like UNDO. Yay!
Inspired and excited by these ideas, I decided to put together a little something for Spring Thing, and finished just in time! I opted to enter it into the Back Garden, partly because I was unsatisfied with the level of polish and partly because I didn’t wish to compete for a blue ribbon or prize anyway.
Development notes and sketches
Most of the changes that happened during development were a result of overcoming various technical issues and design challenges (more on these in the next section). At this stage I was also trying to solidify what kind of experience I wanted the player to have, what positioning of items and NPCs would make the most sense story- and puzzle-wise, etc.
Fun fact: the three actions mentioned in the intro (LIGHT LAMP, EAT PASTA, ENJOY POETRY) are references to three famous works of IF — Colossal Cave, Aisle and The Hitchhiker’s Guide to the Galaxy, respectively!
I pretty quickly settled on a classic ‘wizard tower’ with one room per floor, but for a little while I struggled because stairs (specifically spiral staircases) affected the ability of characters and objects to move between floors, by reducing visibility and introducing movement constraints. I briefly envisioned a single-floor home divided into four rooms instead, where the Depositor could have access to every room, but I decided against it.
Ultimately I fixed the stairs problem by turning them from the classic spiral staircases into relatively straight ones and keeping descriptions vague enough to allow for different interpretations of their positioning, making it much more plausible that the mage can see the floors above and below.
An unused item appears here: a bottle of glue, which could theoretically have allowed the player to attach one object to another!
This is much closer to the current version of the game, though a few things have been moved around since. At this point I was making final decisions regarding which automatons can move (or be moved) and which are stationary.
I had originally considered having at least one or two unnecessary items such as a bed, which could be played around with for fun and might help the player get the hang of game mechanics. They were cut out when I realized how much work I would need to put into the essential items to make them work, and how much more complicated everything can get with each extra object. It’s probably for the best, as I fear they could have turned into unintentional red herrings!
A checklist of the interactions between each noun and automaton. Despite this, I still missed several cases at first because of the multiple states that some items can be in!
I had planned to use red for “dead end” interactions (game overs, actions that result in no change to the game state) and green for the rest, but in the end that felt overly complicated and I just used red for everything. Black is for interactions that can never happen because it’s impossible for these items to be near each other.
The first sketch of the game’s cover picture, featuring my favourite hexapodal pal! The “GO” in its eyes is a little more visible in this version.
Technical and design challenges
I had never seriously used Inform 7 or made a complete parser game before starting this project, so there was a bit of a learning curve as I figured out what was and wasn’t possible! I feel like I’m still missing some of the essential skills to smoothly implement certain things, but it was overall a wonderful learning experience and I feel at least somewhat confident in using the system now (I’m also totally in love with the natural language syntax).
Once again, I want to recognize the contributions of my partner @Allx, who helped me scour through documentation and was an invaluable beta tester / troubleshooter!
Looking at the source code, you can probably tell that I was a total newbie:
I left a few notes in there identified with ***, but there’s much more that could be discussed!
Some highlights:
-
I foolishly named all of the automatons by their full names in the code, which was an absolute pain to have to type (or copy-paste) over and over and over! But at least it looks pretty?
-
All that copy-pasting led to a really bad bug in the first release where the locket’s position was determined not by whether it had been nabbed by the Collector, but instead whether the dragonsbane had been nabbed! Which means that if the dragonsbane was collected first, the locket escaped the dresser and started following the player… (perhaps an act of desperation by the APOLOGIZE, making the locket hop after you!)
-
It took me a while to learn that you can nest ‘if’ statements and outcomes by using a colon, so in a few places I think I still have identical if statements one after the other with different outcomes (if the X is Y, say “A”; if the X is Y, now B is open…)
-
I only found out on the final day that you can divide your code by parts, chapters, etc, so the classifications are very half-assed (just enough to save me from the awful amounts of scrolling I was doing before!)
-
I successfully disabled most of the standard commands by having them be understood “as something new”, but I discovered the hard way that directions exist on a separate layer that can’t be fully blocked with this method.
In an old version of the game I had defined the Workshop as being above the Bedroom, and I had neglected to take the line out afterwards, so as a result it was still possible for the player to teleport between the bedroom and workshop with UP/DOWN and totally break the game… I found this bug by complete accident while testing for something else, so I don’t know if any players encountered it before it was fixed! -
Despite the default parsing limit being 9 characters, I had created some redundant synonyms “just in case”, like AUTOMATONS for AUTOMATON. It turns out that this triggers an obscure Inform bug where duplicate list items can interfere with other commands. In my case, things were fine for a while, but when I decided to add a third synonym to ABOUT/HELP (such as HINT), both AUTOMATON and AUTOMATONS suddenly abandoned their programmed behaviour and started to behave just like ABOUT! Changing the parsing limit to 13 characters solved the problem.
Special thanks to everyone who took the time to report bugs or help me with technical issues, as well as those who wrote a review or shared their transcript! It was deeply appreciated!
Other challenges touching on technical implementation or design:
-
Due to the absence of LOOK, I implemented WAIT to act as the “see the state of everything around you” command, and I tried to mention important objects every turn so that the player wouldn’t lose sight of them.
With UNDO, in addition to its default effect, I added something that I always wished to see in other games: a description of the game state, in this case similar to what is seen with WAIT (but collapsed so that it doesn’t take up too much space). When I need to UNDO multiple times, I often lose track of which turn had what, so I thought this would be a helpful addition!
In the past few days I finally figured out how to program “text that varies”, which I used to add nearby automata’s initials to the status bar as a little bonus. -
The Basher Automaton is the only object that can never be described by the Gazer, because it bashes itself too quickly! I tried to include enough descriptors in various other places to convey 1) the Basher’s general appearance and 2) its ability to move around.
-
The order of automatons was of the utmost importance when trying to determine how to construct the puzzles and mechanics, and it took me a while to settle on a final order. The GO automaton could have been the Explorer, the ATTACK automaton could have been the Crusher, the LOOK automaton could have been the Appraiser…
I eventually settled on having the GO automaton be either first or last, so that it wouldn’t leave the room in the middle of a turn. The ATTACK automaton was interesting to place early on as well, as it created a great obstacle. Having LOOK at the end was perfect for providing an up-to-date status of the object in question. And of course, having CLOSE after OPEN was a must!
The availability of suitable synonyms also heavily influenced the decision process, but to my relief it ended up not constraining me as much as I feared! I did get stuck with “Exposer” in the end but I think we made it work, hahaha. -
I hesitated a lot about whether the ME command is too hard to find without using some kind of bold text! As a player I think I would find this version of the puzzle more satisfying than a version where it’s made obvious, and I’ve received positive feedback to that effect from others too. I also left the word un-bolded in the HELP menu in order to make things more consistent (I figure the in-universe justification would be that bolded words are escaped nouns hiding in new places, and your own self doesn’t stand out in the same way).
That being said, I acknowledge that every other essential word being bolded can create an expectation that holds the player back, so I’d like to maybe solve the issue through a more refined help system. Perhaps the THINK command could give you a nudge in the right direction?
I would have loved to reference another default Inform message by sneaking in a clue like “you are, as always, self-possessed”, but that would probably just be confusing… -
I don’t think there’s really a ‘bad’ way to experience the game, but I feel like some endings might be more narratively satisfying or interesting when they’re experienced before other endings (incidentally, the San Francisco group followed my perceived “ideal” order in their playthrough, which was very fun to witness!)
I’ve been making small changes in order to gently nudge the player towards endings which I feel are best obtained early on, but I was careful not to restrict freedom in any way. -
I liked the idea of keeping track of the Ambler’s positioning, so that the game could describe it walking from one object to another more precisely. But this would have involved a lot of extra work, so I didn’t have time to implement it and instead tried to keep some vagueness in the descriptions of the Ambler’s movement.
Thinking about it further while planning game updates, I started to wonder if implementing this tracking might actually confuse players by giving the impression that the Ambler has to be positioned a certain way to solve puzzles? (An idea I’d be interested in exploring, but which is irrelevant here!) -
The question of “what to use against the dragon” was a big one, and I was a little stumped by it until the dragonsbane idea! I was happy to find an object that could be integrated into the world in a believable and easy-to-grasp way, and wouldn’t be too difficult for the player character to use.
-
I had initially planned to give the player an extra turn in the yard with Ignipter, an option I really liked because it could give a great sense of agency and closure, especially if you get to finally use APOLOGIZE. I ended up cutting that out, mostly due to technical/scope issues, but also in part because it was difficult to reconcile it with the newly-developed lore (the level of toxicity of the dragonsbane fumes, Ignipter trying to have a conversation, etc).
I do regret that loss a bit, but ultimately the current version really grew on me! A neat side effect of this choice is that the game can be finished 100% without using any verbs, which would not have been the case otherwise. -
Combinatorial explosion is a real concern for a game like this, where few things are handled automatically by the parser and many interactions have to be painstakingly defined by hand! I’m sure there are ways to streamline things, and I’m hoping to learn to be more efficient with my Inform code, but I think scaling up this kind of program will be particularly difficult either way.
I really felt that pain when I was trying to anticipate all possible stackings of items in the Workshop and write special cases for each. Making the workshop collapse upon leaving was a way to close the door on a “tutorial” of sorts, but also to spare myself the horror of throwing 5 more objects into the “depositing” interaction pool!
How was it received? What worked well (or not so well)?
I was very pleasantly surprised with the game’s reception! Players really “got” what I was going for, and I was delighted by their different approaches to the mechanics.
I felt particularly honoured to be compared to Andrew Schultz, as I’m a big fan of his clever wordplay!
I think the experimental nature of NC, and the way in which several of its elements fell into place pretty neatly (both by hard work and by luck), really helped create the sense of wonder and surprise that I was hoping for. But my system was so precariously built, and I gave myself so little time before the deadline to fix things up, that some things unfortunately ended up falling apart. I apologize to anyone who experienced issues while playing the game!
Planned changes and improvements
I consider NC to be pretty close to its “final” state now that the bugs have generally been ironed out, but there are still some changes I’d like to make, including:
- Improving the clarity of some interactions (ensuring that there’s no confusion regarding what the automatons are doing)
- Fixing some of the awkward repetitions and excessive line breaks (if possible — I’m not sure yet what’s causing some of them!)
- As mentioned above, creating a more refined THINK/HELP/ABOUT system
- Implementing more custom responses (e.g. when trying to use GO, ATTACK, TAKE, OPEN, CLOSE…)
- Adding more synonyms
For the time being I’m prioritizing improvements to Dysfluent since they’re well overdue, and I also want to make sure I spend enough time on my IFComp 2024 entry to make the August deadline. But I’m eager to revisit NC when I have the chance!
Where do we go from here?
Several players have expressed interest in seeing more of this concept. I would love to dive back into it at some point — hopefully in a less clumsy manner, now that I have some experience under my belt! However, I’m not really sure what form this hypothetical future release should take, so I’m curious to get some feedback from you all.
It would be possible to just extend this story by adding more scenes or giving the player more things to do. But the more I think about that option, the more I worry that it would have a negative impact on the narrative arc, and generally be messy to program or play…
I think I’d be more inclined to try writing a whole new story with similar mechanics, but I’m having trouble deciding if it should feature some of the same characters (e.g. some kind of sequel or spin-off) or a brand new cast.
I’m already starting to have a few ideas, so I’ll be giving this some more thought and looking for an opportunity to create something new in the future!
In conclusion
I’m really glad that this little experiment worked out well, and I’m very grateful to everyone who so kindly engaged with it! I hope to keep making crazy games and to provide joy to like-minded players for years to come.
And just for fun…
Which automaton was your favourite?
- Ambler
- Basher
- Collector
- Depositor
- Exposer
- Fastener
- Gazer
Thank you once again to all readers and players! 
If you have any comments about NC or anything in this post, I would love to read them.