This article originally ran in Back Alley Games Issue 20, November 2025

Uncle Henry Isn’t Home was one of the standouts of Chicaghoul 2025, a real deal point-and-click adventure game presented in an arcade cabinet and capturing the existential, lonely horror of both games like Myst and H.P. Lovecraft’s mythos. – Back Alley Games Editorial Team

In June, I joined, but did not submit an entry to, Indie City Games’ AllStars 2025. I entered that jam with a mechanic that I wanted to try building and without a clear picture of time management, completeness, or the learning curve involved in making a long-run jam game.

I had just started using Godot after not making any interactive software since college, and it did not go well. I created something, but it couldn’t really be called a game, and it wasn’t something I wanted to share.

This time, a week before the jam started, I reached out to all the people I had good feelings about on the ICG Discord who were looking for teams. I got near immediate buy-in from everyone I contacted, and we were ready to go a week early with ideas burning holes in our cranial basins.

We all agreed nothing made before the jam would end up in the final work. Dani made around 4 times as much music before the jam as during, trying to narrow down the sound. I programmed and scrapped a whole navigation system but learned what structure the real thing would need. I think we all read “The King in Yellow.”

We were extremely prepared for the jam to start.

The first week was sort of lost to me. I was definitely learning a lot about Godot again and I was dangerously unemployed, but while I might have been working on the game all day, every day, I can’t exactly say what I did.

I had this idea for the game to be claustrophobic and unnecessarily archaic in design, so I was researching Macintosh adventure games where the hardware could only handle a subwindow’s-worth of graphics, so the rest had to be text.

I had already set my mind on this format before the story was a twinkle in Seren’s eye, so I was also convinced we’d have more inventory-related puzzles. “Bring A to B, insert in order” deals, but we settled on using dial locks, which was good for me for other reasons. The inventory system was not nearly as robust as the log. 

In the first week, I know I’d finished the basics of the click-to-navigate system (though, without turning) and I had the log populating and playing audio. I made a lot of mistakes with architecture here, thinking I needed a bunch of “manager” Globals, each acting as their own Signal buses, when most things can issue direct function calls to targets.

There were a few events that warranted Signals. One good example was “Puzzle Complete” events, which update the game state, play localized sounds, and alter several bits of the world at once. As I get better at planning out architecture ahead of acting on half-finished plans, this will be something to remember.

If the action required needs to be done by a single, static object, have members that need to use that function hold references to the static object.

If the action required needs to be done by the parent of many instanced children, give the children a reference to their parent and have them call the function directly.

Only if the action is a distributed collection of actions, done by a dynamic collection of unlike members with different functions, and requested by a dynamic set of objects elsewhere in the tree, should Signals be used. If you need to listen for any one of a scattered collection of emitters, and each receiver needs to do its own, special thing, then you can use Signals.

Time Management

I do not like managing projects. I knew from the initial discussion that this would be a lot of work to pack into three weeks. I had nothing else to do, and I wanted to see it through.

In the end, everyone worked when they wanted and made what they wanted to make – at least I hope so. Save for my grinding and trying to check as many boxes off our list as I could, I put very few items on the to-do list for others, and when I did, it was only to fill in placeholders.

This jam, I found it helpful to take breaks from the coding without taking breaks from the project. Our setting was begging for junk, so when I couldn’t handle any more code, I started modelling furniture.

We ended the jam with over 50 unique “furniture” objects, though some of those are posters and rugs. Some of my best work was the Victrola (which has a looping skeletal animation), the 4- and 6-faced dial locks (which use entirely procedural animation) and, of course, “Goobert,” based on a sketch by Void.

In terms of personal time management, I found my best strategy was to redirect, rather than take a break from, the project when I got frustrated or tired. It gave me a sense that I was always making progress even when I wasn’t checking things off my list. I could look at the Git history and see all the green pluses at the end of the day and know I’d added things.

I do not feel that our team crunched. I was working excessively in the second week and certainly wish we could have had more of a complete game going into the third, but by Friday night, I was poking at annoyances (worse ones than the camera turning bug) and flipping idly between code, level finishing, and doodling in Blender.

Normally, a project with a deadline is something I postpone work on until I’m desperate, but since I had been cranking away at the code factory full-time for the last three weeks, there wasn’t a lot of desperation to go around.

I think that I benefited from having a team, because they created expectations and generated feedback. There’s something very important to me about delivering asked-for, positive news to people I want to tell. 

Systems

Everything is a system. Games are systems. Complex systems are interesting. Therefore, the more complex a system is, the more interesting it is. That’s why I built this game’s code to be unreadable.

-Jergling, inventor of cruftbragging

At the outset of this project, I wanted to make something that was system-driven, extensible and broadly applicable in the way that an engine is. The blueprint for the project was about making a system that would work to tell Seren’s story, but every decision I made, I tried to make as if I were designing a tool for someone else to use to make a first-person, point-and-click adventure game.

Until I started running out of time. Then, I skipped all that and started making what I needed right then.

With some cleaning up, I would like to turn this game system into something like a proper template, with tools and a consistent structure designed to let artists and designers build the same kind of experience without much code.

It’s easy to make this kind of game in 2D – it’s essentially a slideshow with hidden buttons, but the jump into 3D requires so much more processing and specification within the game. As it stands, the environment and basic exploration and dialog can be built with no coding knowledge, just a few templates for travel destinations and a JSON “screenplay.” 

The size of our game doesn’t really show off the system. I’d really like to make something in this system with a lot of negative space and large structures with curving gravity. It all has the benefit of running in real time – you can change lighting, play animations, run physics simulations, trigger spatial sound, and will all be consistent between viewpoints, because they’re all viewing the same 3D world.

While the trend right now is to do all exploration via the generic first-person walking controls, I think there’s something very intuitive and human about the way point-and-click works. You aren’t sliding a brick with a camera close enough to a puzzle to open a menu; you’re crouching down to look at a hidden panel or feeling your way down a hall.

The placement of the camera is deliberate, framed just as it is for the player’s use and enjoyment, like a director lining up a shot to show (and leave out) exactly what belongs. I’d like to make more of that.

Closure

Now that the jam is over and the scores are in, the team is all very happy with our placing. Even before the jam started, when things came up that were obviously out-of-scope, we were marking them down for the “full game” release.

We know that some game jam teams love their product and their partners enough to make a commercial release of the jam game, but I don’t think that’s usually decided on before the team has worked on anything. Lucky for them, and I guess for me, we all seemed to enjoy the process and the end product. It felt very good to be recognized and better to be satisfied with the outcome even without praise from peers. 

Some of the team is eager to start on that full release.

I’ve had a few too many hours of grinding at it, and I’ve started to build something else to reset.

We are going to have a great time at the showcase Saturday.

Each member of the development team was kind enough to submit a reflection on their process, though we had to shorten them for length and clarity. Each of them can be read in full on itch.io: https://jergling.itch.io/uncle-henry-isnt-home