Game Jam Day 10

Tag: [day-10]

The main activity of the final day was lots of polishing and minor enhancements, guided by feedback from play testing.

Then we submitted the game! You can find it at https://grumblyharmonics.itch.io/clock-tower.

Play testing

We got three friends to play the game as of [day-9], using a special version hacked to intercept I/O calls and write a transcript.

The testers gave us some direct feedback, but what we found most useful was reading the transcripts to see what the players wanted to do and what they expected would happen.

The Play Testing wiki page has a summary of things that looked like they should be changed based on play testing. Some highlights:

• Everyone wanted to be able to pet the cat.
• People tried to interact with things that were mentioned in room descriptions but were not real game objects, like the welcome mat in TOWER-KNOCK and the window in TOWER-TRAPDOOR. (Finding a key under a welcome mat is an early puzzle in Maniac Mansion.)
• Entering the unlock code into the box required fairly specific syntax that players had difficulty finding.
• Only one of the random knock responses gave a strong hint that you had to go out to seek inspiration; if you didn't see that one, what to do was unclear.
• Testers tried many alternative ways of phrasing commands, like CLIMB LADDER instead of UP and PAUSE instead of LISTEN.
• Some logic bugs, like being able to get infinite keys by knocking more than once.

Polishing

This final phase of polishing, fixing minor bugs, and altering the design to solve problems was a lot of fun!

We added more sounds: cat meows and wind on the mountain peak. (Yes, you can pet the cat now!)

The inventory now shows a list of "special attributes" you have, which include things like being inspired. It also adds a quality-of-life improvement, in that the attributes remember the secret code for you, once you've heard it. This game mechanic is hidden from the player at first. It only appears once you have at least one attribute set.

The game now gives you a score when you quit or win. This is in keeping with this game's being a sort of exercise in implementing classic adventure game tropes. The score mostly tracks things you need to do to win the game, so it can almost be thought of as a progress tracker. However we did add 1 extra point. The way of earning it is an homage to both Witt's End and the Breathtaking View in Adventure.

We made the ENTER CODE and FEED commands more accepting of different syntaxes. In one way this work reduces complexity, by turning special cases into more general cases. But there are also knock-on effects, as you can now ENTER and FEED things that were not originally conceived as being able to handle those verbs. We started to appreciate why the old adventure games had so many default messages, when you can do anything to any pair of items.

The LPeg-based parser was mostly pretty capable at accommodating the syntax changes. One notable challenge was the command GIVE CAT FOOD. The intended meaning of the command has CAT-FOOD as the direct object and CAT as the indirect object; i.e., "give food to cat". But it's tricky because CAT, FOOD, and CAT FOOD are all valid item references (because CAT FOOD can be abbreviated FOOD). The command is parsed instead as having CAT-FOOD as the indirect object and an empty direct object. which is a syntax error. That's because GIVE is a synonym for FEED, and the parser is interpreting it analogously to FEED CAT. Where FEED CAT means "feed (an unspecified object) to the cat" and works, GIVE CAT FOOD means "feed (an unspecified object) to the cat food" and doesn't work. This bug remains in the submitted version.

We had had the idea of automatically word-wrapping text to a reasonable width. We ran out of time to do it automatically, but we did manually wrap long strings in the source code.

Binary packaging

On day 9 we made a Windows executable package, which is what the play testers used. Today we additionally made a macOS .app package and a source zip file. These are automated using a makefile and some shell commands. https://alexjgriffith.itch.io/caph was our model for packaging a Love game.

We know the Windows package works, but we did not test the macOS package at all before the submission deadline.

Public dev log

We wanted to copy this dev log from our private Fossil repository to the public itch dev log. The Fossil wiki is Markdown, but the itch blog uses HTML. We used Pandoc to help with the conversion:

pandoc -f markdown -t html devlog.md -o devlog.html

But the process was not smooth, because itch's HTML editor mangled the markup in various ways. It required a lot of manual fixing.

Our use of internal links in the wiki page was also a problem. Fossil lets you link to various things like checkins and issues by their hash, using syntax like [](870e0a8afe600cef). These links don't have any meaning when copied outside their original context.

We had made limited use of Fossil's embedded pikchr render to make some diagrams. These also needed manual attention to post them on the itch blog. The Fossil web UI pikchrshow path can convert pikchr markup to reusable SVG, at least.

Puzzle dependency chart

Ron Gilbert wrote an interesting article on puzzle dependency charts. This is The Clock Tower's chart:

Fossil

With the frequent commits happening today, we were feeling the lack of a tool like git log -p, for which we haven't found a ready replacement yet.

The other feature of Git we use frequently that Fossil doesn't do as well is committing only a subset of working directory changes, as with git add -p. We took to using fossil stash a lot and storing partial changes in temporary files.

Overall, our experience with Fossil was positive. It's neat to be able to get source code management and all the nice features of a forge, in a form that's pretty easy to set up and doesn't require creating an account somewhere. Besides the issue tracker and the wiki, we used the chat feature a lot as a place for communication just about this project.

What changed

The game we submitted differs somewhat from what we had envisioned at the outset. That's fine—we know, going in, that a game jam would in part be an exercise in being selective and making adjustments in order to meet development constraints.

With the core idea "text adventure plus audio" we originally thought about having 3D x, y, z coordinates for sound sources, with stereo sound cues so that you would be able to sense where objects are in a room. It would extend even to adjacent rooms: if you're facing north, and there's a passage to the east that leads to a room with a river, you would be able to hear the river in your right ear (at a reduced volume) even a room away. You might even be able to face different directions in the same room and hear the sounds coming from different relative directions.

We ended up not having 3D positions of sound sources. Every sound plays with an equal left/right balance. The idea of being able to hear things in nearby rooms survives partially in the clock chimes, which you can hear all over the map, at a volume level according to the proximity to the clock tower.

The original idea also had an element of experimenting with accessibility. When you have a game that integrates and depends on audio to a high degree, what do you for people who cannot hear well? We thought about having a scrolling frequency spectrogram (like the one at music from another room) to give an visual indication of what sounds are currently playing. Actually two spectrograms: one for the left and right channel, the idea being that you could tell which direction a sound was coming from by seeing the same pattern in both spectrograms, but more intense in one or the other.

Before the jam started, we asked on the love forum whether it would be possible to get audio samples after processing by the audio engine. In short, no, it doesn't seem like it's easily possible to get the information we would need using the normal love libraries. So we gave up on the spectrogram idea. But if you were making a game in HTML, with easy access to Web Audio and AnalyserNode, it might be a cool thing to try.

Love2d does support setting the 3D position of sound sources. Our not taking advantage of that was more the effect of time constraints and lacking a clear vision of how it should work.

The game as submitted does some mixing of turn-based and real-time mechanisms. The commands and game state updates are turn-based, but the audio effects are real time: the radio stations keep playing all the time, and there are things like gradual fades between sounds as you move between rooms. One idea which we did not realize is making the real-time sounds extend more into the turn-based command interface. While you are composing your command in the bottom line of the screen, the sounds that are playing get shown in a scrolling transcript above that:

Town Square
You are in a town square with cobblestones below your feet.
There are exits to the north and east. A wheelbarrow leans
against a tree.
* "—boards today! Bill builds 'em, you buy 'em." (radio)
>look at wheelbarrow
You see nothing special about the wheelbarrow.
* Bong (the bell rings).
* A dog barks.
* "Cheep!" says a bird.
* Bong. Bong.
>play the magic flute

Doing this would be a lot of work: besides whatever terminal-fu is needed to make the scrolling work, you would need timed transcripts for all the audio files. But it would be another neat experiment in accessibility, and it would have the effect of reinforcing the noise or lack thereof in a given scene, as places with lots of sounds playing would have faster scrolling text.