Writing a sequel is hard. The IF author’s task is to delight players by expanding the vision of the first game without compromising its core ideas. Pulling that off is tricky because it requires a complete understanding of the audience, which is difficult to gain from the reaction to a single game: what are the core ideas, according to the game’s fans?
I must have come up with the wrong answer to that question, because although with A Smörgåsbord of Pain I certainly expanded upon the ideas introduced by A Matter of Heist Urgency - intricate but narratively smooth combat and meaningful use of music - I may have inadvertently betrayed my fans by intentionally making those scenes more difficult. I thought that the defining characteristic of the series was detailed randomized combat, and that I could improve over AMoHU by making it more deep, complex, and tactical, forcing players to engage with the systems in use. However, maybe what AMoHU’s fans really enjoyed was the frictionless, fast-paced gameplay, and I could have addressed their concerns by keeping the difficulty level comparable to that of the first game but adding more conversation and backstory between the fights and chases.
That’s one possible explanation for why A Smörgåsbord of Pain did poorly in the Comp results. But I don’t think it’s the whole story.
DEVELOPMENT
During 2023 and 2024, I had been desultorily working on earlier versions of some scenes and music, but nothing I did then made it to the final game; A Smörgåsbord of Pain didn’t come naturally to me the way A Matter of Heist Urgency did. In July of this year, with the timeline looking increasingly bleak, I decided to cut a significant midgame scene (it was supposed to involve sneaking around an office building) and expanding the docks scene to compensate, which definitely tightened up the overall structure and made the scope more manageable. This time, I also was able to recruit some beta testers from the forum, so I’d like to thank Robert Eggleston and Anssi for responding incredibly quickly and keeping detailed notes about their playthroughs.
Late August was an accelerating spiral of sleep deprivation. Almost all of the music was written within a week near the end of the development period, because I realized I couldn’t wait for inspiration to strike any longer. By the morning of the 28th, I had finished everything on my to-do list. I was done! That evening on a whim I opened it up with the Windows version of Gargoyle using Wine and was greeted with…
Programming error: tried to read entry 33 in the list channels, which has 32 entriesI can’t deny that it was funny to see that, despite my best efforts and careful planning, I was once again working up to the last few hours. (I did manage to fix that error and a few others, though.)
Together, all of the code in A Smörgåsbord of Pain totals up to 139,501 words, and that doesn’t include the lengthy I6 inclusions that implement several of the low-level or performance-critical systems. The food fight alone is bigger than the original competition version of A Matter of Heist Urgency. Much of this word count is due to complex systems that I think many players didn’t even notice, which I will discuss in the following sections.
RETRY/CONTINUE
The idea for the RETRY/CONTINUE system occurred to me when I was playing some Japanese bullet hell shooter games, which sometimes feature invisible checkpoints in the middle of the level; inserting another coin after exploding moves you to the last checkpoint instead of to the start of the level or the game. I implemented a similar system in ASoP (using Glulx’s ability to read from and write to external files) to try to make the prospect of restarting the fights as easy and appealing as possible, even if you hadn’t saved and weren’t invested enough to restart. I’m not sure if this idea ended up working or not; it may have just made people angrier when they eventually gave up.
DYNAMIC MUSIC
I’m not sure how many people noticed, but there’s an extremely intricate dynamic music system running in the alley fight that took a lot of scientific experimentation to develop into a usable form. Precisely how it works is a trade secret for now, but I will say that it is based on Glk timer events and the extended sound channel functions. It queues up certain musical segments and phrases according to events that occur in the battle, like one of the horses getting knocked out.
There’s also a different type of dynamic music in the food fight; each culinary area has an associated music track, and the game crossfades between them when you move between zones. It was a lot of fun to do research on traditional music styles from different cultures around the world and try to compress each style’s essential features into a single looping track.
THE GRID
The grid positioning system used in the buffet looks simple, but the code that makes it work is surprisingly complex.
First of all, there’s raycasting. (Yes, I created a parser IF that involves raycasting.) If you’re not familiar with the term, it’s a common technique in video game development used to decide where a linear path or ray hits some set of obstacles. Thrown food items that miss their targets hit one of the walls or fly off into the dining area, depending on the positions of the two combatants. I implemented an integer arithmetic-based algorithm to determine the squares through which the projectile passed, which I recently learned is called a digital differential analyzer.
I also wrote the pathfinding code that the llamas use to move around the buffet, avoiding the food counters. (For the technically inclined, it’s just a naive implementation of the case of Dijkstra’s algorithm where all the edge weights are identical.) In a last-minute scramble to optimize the game for web, I ended up making the game pre-calculate all the pathfinding data at the beginning, which is probably why it takes so long to start up on web interpreters. I feel like it’s better to have a long startup delay but quick command execution than vice versa, though.
SITUATIONAL AWARENESS
Situational awareness is an idea that was constantly at the back of my mind while I was working on the chase and food fight scenes. It occurred to me early on that to keep players oriented, the game would have to judiciously supply them just the right amount of information: too much and they start skimming, too little and they get confused. For instance, there are dozens of variations on movement messages that attempt to convey information about the llama’s relative position and likely behavior within a single sentence - a llama “glaring at you across the buffet counter to the east” is currently exactly 1 square to the right on the map, targeting you, and separated by a counter.
I didn’t entirely succeed because several players still told me that they weren’t sure what was going on. For the post-comp version, I might try to improve the unreachablity error messages to give you more usable information - like the approximate direction and distance to the object you’re trying to interact with.
NARRATIVE FLOW IN THE FOOD FIGHT
With the food fight, I attempted to create a combat scene that would read like a book. This meant that I had to eliminate the mechanistic rhythm that the game can easily slip into when printing NPC action paragraphs; you can see that in the pirate ship fight in AMoHU. The solution is something that I codenamed the QAD system. (QAD stands for Queued Action Description. I like acronyms.)
The QAD system operates on a queue of events generated by NPC action processing rules earlier in the turn sequence. It repeatedly checks through description rules which can consume events, and some of these rules consume more than one and print out a single paragraph incorporating the relevant data from all of them. You can see this happening when multiple llamas are moving at once.
I had originally planned to do much more with the QAD system, but ran out of time. Thus, A Smörgåsbord of Pain ended up as more of a proof-of-concept of this idea than a full implementation. I think it’s a very successful proof-of-concept, though; even the limited applications that I had time for hugely improved the narrative flow of the descriptions and let it pack more information into much less screen space.
OTHER MISTAKES
In the introduction, I discussed one possible mistake: I took the series in a direction which was unexpected and disappointing for many fans of the first game. I suppose there are also occasional disambiguation issues in the food fight and warehouse scenes. However, I don’t think these problems alone fully explain the game’s placement. Since I didn’t get any clear negative feedback, I have had to speculate about other possible reasons.
First, the cover is not made by AI. I drew it on the computer with a graphics tablet, and if you look closely you can easily see the messy boundaries on the shading bands and the texture brushes that I used for the fog and clouds. If anyone wants to see proof, I can also send a screen recording I made of myself working on it.
Since a few people mentioned pony racism as a possible concern, I’d like to clarify that I do not condone any form of racism, and neither does the game if you look closely. Sheila and Edna are shocked when Anastasia punches the llama in the buffet and might question her about her attitude toward llamas during the opening conversation, the kitchen staff is entirely justified in pleading self-defense, and there’s no actual implication that llamas as a species are any more inclined to criminal behavior than other types of ungulates.
The one common thread linking every review is that some pun attacks that should have worked were unimplemented. There are over 40 puns in the game, some from me, others from my friends, and still others from my beta testers, but evidently this was nowhere close to enough. I’d like to fix this, but so far I haven’t gotten any suggestions from anyone on this thread. If you came up with puns that the game didn’t recognize, please send them to me! I’ll put them in the game and credit you.
If you claim in-game that you don’t know what a pun is, the Old Camel will tell you to look it up in a dictionary. To my amusement, though, none of the dictionaries I looked at had a good definition. They were all similar to what the Camel tells you: "A pun is a form of humor[…] It is when you replace a word with a similar word… which is funny[.]’ As a number of reviewers stated, many of the “pun attacks” are actually just rhymes. Initially I thought it would be best to exclude really bad or questionable puns, but I realize the food fight would have been more fun had I just thrown everything in.
Many players seemed to think that they had to use pun attacks in the food fight. There are many other actions available, like punching, ducking, throwing food, drinking beverages, etc. Some of these are hinted in the Old Camel’s Guide, others in-game. Maybe the placement of the Camel training scene overemphasized this particular mechanic; regardless, the pun attacks became the central aspect of the central scene of the game, and so I think the frustration of being unable to come up with good puns, or having good puns go unrecognized, was in the forefront of players’ minds as they went to log their ratings.
WHAT NOW, POWER PONY?
Submitting A Smörgåsbord of Pain to IFComp has showed me that time, effort, and technical innovations aren’t the most important factors in deciding whether a game does well or poorly. One of my friends said, insightfully, that people seem to have seen ASoP as less than the sum of its parts. Still I wouldn’t call it a failure: if nothing else, at least I have a much greater command of jazz harmony than I did a few years ago.
In the next few months, I’ll make a post-comp release with a few minor changes and edit the OST into a listenable album format. I may return to writing IF in the future, but first I am going to spend some time working on other game development and programming projects.
Thank you to everyone who played, reviewed, and tested my entry. I don’t regret entering the Comp this year; it’s been an interesting learning experience in many ways.
