Something is Wrong with the Chickens

Game homepage

Something is Wrong with the Chickens is a single page TTRPG in the vein of Honey Heist. Very few rules, just a handful of dice, and a madcap premise. Our session was run by the author, Elliot Davis.

In this game you play a randomly-selected chicken (or turkey, or duck) that has acquired a randomly-selected Eldritch Trait. Tentacles, spikes, that sort of thing. If you want to know how this came about you're asking too many questions. Suspension of disbelief is mandatory. The party barrels through a randomly-selected scenario as they try to get revenge on Bryson Foods for their crimes against chickenkind.

Chickens has a single, simple dice mechanic that handles all skill checks as well as the push and pull between your chicken nature and your eldritch nature. There are three outcomes: A success (yay!), a chicken failure, and an eldritch failure. If you roll an eldritch failure you gain a (randomly-selected) eldritch trait. If you roll a chicken failure, you lose one instead. Gain too many traits and you transcend this world, removing your character from the game. Losing all your traits makes you too delicious and you are immediately taken away to be turned into nuggets. This also removes your character from the game.

I liked this system a lot. It feels silly to talk about 'depth' in a game featuring eldritch chickens but there are legitimately times where you're hoping for one kind of failure or another to keep your traits balanced out. Narrating failures based on the trait lost or gained was also a tonne of fun.

Chickens was great, and I would 100% play it again. One thing I think would be worth doing is expanding the list of traits that your chicken can acquire, as after a few rounds of losing and gaining them there was a fair amount of duplication between players. Rather than d6, a d66 or even a d100 table of traits would make for a richer and more surprising game, but then you'd need a second page for it so maybe that breaks the rules. Perhaps you could ask the players to come up with some at the beginning of the game?

#BreakoutCon2026

Sock Puppets

Game homepage

Sock Puppets stands out amongst the games I played at Breakout. It has no character sheets, no stats or skills, and you don't roll any dice. The game is basically one long improv scene acting out an episode of a dysfunctional children's TV show, and I had a great time playing it.

Our session was run by the creator of Sock Puppets, Kurt. He took us through the game's few rules, and regaled us with stories from its development while we made our puppets. The first half hour of the session was spent cutting and sticking brightly coloured paper, foam, and googly eyes to a brown paper bag that we then wore on our hands for the rest of the session. Here's my creation, Pip.

Each player had a couple of prompts to seed the game with, which include relationships such as one player being another's step-parent and agendas like slipping in 'subtle' product placement messages. I had to try and shoehorn in references to Luxembourg while trying to one-up everything another player did. Then Kurt said “Go!”, started a timer, and the rest of the game was us improvising an episode of children's television in real time.

This was as chaotic as it sounds, and definitely not for everyone. Without the common structures of most TTRPGs, and no GM to help distribute focus (Kurt made a puppet and played a character along with the rest of us), each player needs the discipline and awareness to share the spotlight without prompting. There's also the classic “Yes, and” rule of improv which I think would be worth calling out at the beginning if you run this game yourself. Our table did a good job with these things about 80% of the time, I reckon? Pretty good for a group of strangers at a con.

Sock Puppets was a unique experience for me, and I am glad that I got to play it with the creator. It's definitely not a game I'd recommend playing remotely over a video call though, you'd lose 90% of the fun that way. If you've got a local group and some craft supplies handy though, I'd say go for it.

#BreakoutCon2026

The Wildsea

Game homepage

I travelled to Breakout with my good friend Carson, who runs SSTO Press. On the drive back he told me about playing the LotR RPG The One Ring. A particular point he raised was that he quickly felt at home because the game was set in a world with such well-known lore. Lord of the Rings is the lore in many cases. It is the most familiar fantasy format and tropes found there make their ways into almost all fantasy media.

The Wildsea is the opposite of that. Every aspect of the setting is novel. The world is a sea of trees that the players traverse on ships that are also giant chainsaws, cutting their way across the canopy. There are humans, but they're joined by cacti, funguses, moths, and sentient colonies of spiders(!) as playable character types.

One downside of this is that there is a fair bit of terminology to learn up front. Ektus, Char, Tallshank, The Thrash. It was a little overwhelming looking at my pre-generated character sheet. Standard RPG terms are also thrown out for the most part. You don't have attributes, you have Edges. Injuries become Mires. Rather than an inventory you have Salvage, Specimens, Whispers, and Charts. I still don't understand all of those.

Our Firefly (that's what Wildsea calls the GM) was fantastic. She had all the information we needed about our characters and the world at hand and did a wonderful job of introducing us to the game. Ektus? Cactus person. Char? A ship's cook. I learned afterwards that she writes games too, so check out Mint-Rabbit over on Itch.

Once over the initial terminology hurdle, the novel setting of The Wildsea means that there's a lot of space for the players to add their own details. Being a narrative-focussed game we spent a lot of time asking and answering questions about the situations we found ourselves in. We made many decisions about the world that would already have been answered had we been in a well-known setting. What we built over the three hour session was ours, and I enjoyed that a lot.

My Wildsea session was definitely a high point of the convention. If the opportunity to play again comes up I'll definitely take it.

#BreakoutCon2026

Brindewood Bay

Game homepage

In Brindlewood Bay you play a team of little old ladies who solve murders in the titular coastal village. It's got all your daytime TV and literary mystery tropes, with each player choosing a “Maven Move” named after an iconic fictional detective. I chose Ms Marple, which meant that I could breeze my way into any location regardless of whether I was supposed to be there or not.

The game revolves around collecting clues, which are vague enough that they don't narrow down the list of suspects too quickly. In fact, the key thing is that there isn't a pre-written solution to the mystery. It is the player's job to concoct a narrative based on the clues they find. The more clues they incorporate, the greater the bonus they can add when they make a “Theorize” move to try and solve the case.

Building this narrative was satisfying, and the scenes where we gathered clues were a good mix of investigation, interrogation, and intrigue. Things escalated quickly and the pace felt well-suited to a game based on hour-long TV episodes.

The one thing that I didn't grasp especially well was when or how we were should transition from gathering clues to solving the mystery. Given that we'd stand a better chance of succeeding in our Theorize roll with more clues, we wanted to gather as many as possible. We had over a dozen when we reached the end of our session, which allowed us to solve with ease. If we hadn't had the constraints of the convention schedule I felt that we'd have continued picking up clues until we simply couldn't fail. In theory there was a narrative time pressure too, but that didn't really come into play.

Essentially, it never felt like it made sense to Theorize while the option of searching for clues was present. Maybe that's not a choice that the players are expected to be considering. Without a 'real' solution to be uncovered there's no “ah ha!” moment where things fall into place. That's a big part of the material this game draws from, and I felt its absence.

I really enjoyed my session playing Brindlewood Bay. If someone in my home group picked it up I'd be very happy to play some more. There's a whole overarching mystery that I haven't even touched on here which you'd uncover as you play through the course of a campaign.

#BreakoutCon2026

The only thing I've been spending my time on so far is the underlying encoding/decoding implementation. I've found this slow to complete for a couple of reasons.

As I alluded to in the last post, I'm unfamiliar with the environment. GDScript, the built-in language Godot provides, has enough little differences from my preferred language (ruby) that getting to grips with simple tasks is non-trivial. Consider joining the elements of an array into a String. In ruby that would by my_array.join(","). In GDScript, join is an instance method on String, so you write ",".join(my_array)" which throws me off every time. It also has significant whitespace which is just evil.

I have a bad habit of over-optimising code before even writing it down. My first implementation of the encoding had an array whose values were Godot Key constants, which are integers. This storage efficient, but required extra steps to actually use as the values had to be converted back to printable strings through another lookup table before they could be displayed. Storage efficiency isn't even a good thing to optimise for here! This array will only ever have a couple of hundred of entries at the absolute maximum, so organising it to make it easy for me, the developer, to work with is far more important.

Now I store the actual character I want to print at its corresponding index in the array. so my encoding might be ["a", "b", "c", "d"]. To encode a piece of text I simply run a find for each character, convert the index to its hex value, and throw that into an array. When I've finished I join the array into a space-separated string and I'm done. The reverse is also easy. Split the incoming string on spaces, find the decimal values of each item, and use those to index into my encoding array. String goes in, String comes out, with only one intermediate representation required. Much better.

It's been a longer haul than I expected getting to the stage where I can start working on actual gameplay, but I think it's close now. We'll see. Sitting down to do the work is proving difficult, so I'm not spending as much time as I want on the project and the gaps are long enough that I have to reorient myself each time I start. I'll have to see if I can improve on the frequency with which I spend time on this.

If you haven't, then perhaps you'll know what ASCII or Unicode is. Because of how text is stored on computers, each character is assigned a number. Sometimes it's valuable to display those numbers, and thanks to the underlying binary representation, this can be done compactly by using the hexadecimal representation of the number. This is much easier to understand with a picture:

Source: https://en.wikipedia.org/wiki/ASCII#Character_set

Converting hex values to their character equivalents is trivial when you have the appropriate lookup table, like the one above. My question is, would it be an interesting puzzle to build that lookup table yourself based on some encoded input?

The gameplay I'm picturing is this. Each puzzle is a block of hex data which you know represents the text someone typed, and you have to build the lookup table to decode it. You'd be able to make some deductions based on common themes. If you know the code for d, then your next step should probably be to try assigning increasing numbers to e, f, g, and so on. There wouldn't be hard logical steps to solving each puzzle like you'd get with a Nonogram or Sudoku. Rather it would be obvious when you're making progress because the output text would become more and more readable. I imagine you'd need to start out with a few characters placed on the lookup table to get you started.

A concern is that the novelty might quickly run out. With that in mind, I'm working on a small prototype that will let me quickly create these puzzles and then put them up on the web for people to explore. I'm working with the Godot engine for this. It's still very new to me so I'm at the stage where every line of code I write requires me to look at the documentation. The going is slow, but I'm making progress. Here's an underwhelming screenshot of where I'm at today:

With any luck I'll have something to actually show off by the end of the week.

#GameDev #GodotEngine #IndieDev

The big thing I did was download and play custom maps. The quality was all over the place, but there were some real gems. I remember one in particular that was a series of connected rooms and corridors that you had to clear of soldiers, and each time you played their placement was randomised. To control this, the player spawned in a small chamber that contained a mounted machine gun pointing at a blank wall several feet away. The wall had several invisible buttons on it, each of which would spawn some soldiers in the main level when hit with a bullet. Because the bullets fired in a random spread pattern, you'd get a different set of spawns each time. Even better, the longer you fired the gun for before leaving, the harder the level would be. Genius!

Half-Life shipped with a level editor, which was called WorldCraft at the time. I spent many hours building my own little levels, learning about its capabilities and limitations. I built everything in the editor, I don't know if importing meshes was even a thing back then. Whenever I've looked at 3D game engines more recently, I'm daunted by the prospect of so much work being done to build meshes in external programs and then bringing them in.

I never published any of my work, and I have to imagine that the hard drives they were on are long gone. Making my own games has always remained a “one day” thing at the back of my head. I've learned how to program and made it my career in the 25+ years since I last touched a Half-Life level. Several times I've thought “Now's the time” but each time I've opened up Unreal Engine (or other 3D engines) I've been scared away by the complexity.

There's a mantra in film-making that I learned recently, which goes “Only write what you can shoot”. This makes sense, and made me realise that I should apply the same idea to my own attempts to make video games. For me, this means ditching the third dimension and looking at 2D games. In fact, the real-time aspect can probably go too. I'm a big problem solver, so maybe some kind of puzzle or mystery aspect? Games like the Golden Idol series, The Roottrees are Dead, and Type Help are some of my favourites that don't have complex technical systems behind them (not to diminish the work that went into them, of course. Just that the kind of work is more up my street).

Spoilers: Yes. That's the kind of game I'm exploring. I'm slowly picking up the Godot engine, which has robust 2D capabilities. I hope to write more about that in the future through the lens of the game idea(s) I'm exploring.