I'm still working on my point-and-click puzzle game made from dioramas.

Often when you watch videos of people doing crafts on the internet, they're people who have been doing it for years. They don't make mistakes, or if they do, they don't really show them to you. I haven't been doing any of these crafts for years. So I've made lots of mistakes, and I want to show them to you, so you don't get the impression that this is easy.

Before you read further: Please wishlist High Mountain Abbey on Steam.

1. Tapestries

Machine-woven tapestries (which I'm using for rugs) are very low-res -- 14ppi (which is, at my scale, 14 pixels per foot, which is not very realistic, but it's probably forgivable). The way they work is really neat (but requires some pre-planning): they have six colors of yarn: red, green, yellow, blue, white, and black. Depending on the color of each pixel of your image, a different color ends up on top. I wish I had known about this in advance, so that I could have designed my images to do my own dithering, but this doesn't seem to be a supported mode of operation for the services I found. I guess palletized pixel work is a dying art.

2. Git hosting

I quickly learned that git hosting was going to be an expense. I started with Gitlab's free tier, but that has a limit of 10GB. I would have liked to give them money, but their pricing for additional storage is $0.50/GB/mo, which is outrageous -- S3 charges $0.023/GB/mo, which is less than a twentieth of the price. I assume that Gitlab charges such high prices to account for the data transfer costs, but my data is basically write-only, so it's a bad deal for me.

With seven rooms photographed so far, my repo right now is 53 GB, since I'm storing all of the photos that go into each focus-stack, as well as the raw (xcf) versions of each shot so that I can edit and color-correct without repeated JPEG compression. I ended up just running my own Gitlab on a cheap Hetzner VPS, which was trivial to set up, and not very expensive. It probably has less reliability than Gitlab's service, but I have Hetzner's backups and also my own desktop's backups, so I am not too worried.

3. Animation

Yossi warned me about this, but I didn't listen: AI isn't actually good at tweening. It worked really well when I just had wool roving moving around:

But then I tried to use it to tween a solid object rotating 60 degrees:

This is surprisingly bad. But I thought: maybe it's just that rotation is bad? So I tried with a door sliding down. Actually I tried it with a door sliding up, but I didn't save the result, and then when I went to re-create it for this blog post, the images ended up in reverse order, so I guess it's sliding down now. I'm not counting this as one of my six mistakes -- you get that one for free.

Admittedly, the motion on the door is a bit shaky (that's the joy of stop-motion), but I would have expected better. I guess the wool only worked because it was already, well, wooly. So I will have to live with a low framerate on most of my animations.

I can sometimes use some trickery to improve the framerate. For the animation of something rotating, what I actually do is have Godot rotate each frame while fading in the next frame. I still have a bit of the stop-motion look, since the object moves unevenly (and it's made out of felt, so it wiggles too). And I still have decent shading, since the keyframes are photographed in situ with the correct light.

4. Shooting in confined spaces

I had thought that I could do all of the photography by placing the camera inside the dioramas. But for narrow hallways, this doesn't work -- the camera ends up too close to the wall to get a wide enough shot.

So I ended up doing something a little weird: I cut holes in the walls, and shot the side views from the outside, through the holes. Then, to make the insides look right, I put paintings or lamps or other decorations over the holes.

That hole fits a camera lens -- I'm still suffering from my camera's narrow field of view, but at least you can see the door. And when I'm shooting from the inside of the diorama, I pop a lamp into the hole and you would never know it's there.

5. Steam marketing

I put up my previous blog post, which got some traction on Hacker News. Great, I thought, everyone will want to buy my game! But I forgot a step: first, people have to learn about the game, and not the seventeen people who follow my blog. It turns out that the way to do this is to get lots of people to wishlist the game on Steam.

So what I should have done is: first, create the Steam page for the game, then post the first blog post. Well, better late than never: please wishlist the game. The more folks wishlist it, the more Steam will feature it at launch, and the more folks will buy it.

6. Veneer

So then I started working on the Steam page. Steam requires nine graphics, each with a different aspect ratio. Normal people make these graphics in Photoshop or Illustrator. But High Mountain Abbey is not a normal game; it's made of physical objects. So, of course, the Steam graphics must also be made of physical objects. I started with a piece of walnut burl veneer. Veneer is supposed to be flat, but burl wood has wild grain, so when I tried to glue the piece down, it warped like crazy. Probably I should have clamped it hard, instead of just tossing a board on top of it and hoping. Or used a non-water-based glue.

Oh well, it adds character, I tell myself.

One mistake I didn't make

I love the idea of Rust: big abstractions, safety, performance. I feel unease with non-memory-safe languages in 2025 even though I actually really enjoy programming in C. But it would have been a mistake to build High Mountain Abbey in Rust. There's always the temptation to make a custom engine for any game. But for this game, Godot is just fine, and I think I regret even the slight amount of weird custom stuff that I built to avoid dealing with Godot's resource format.

Conclusion

High Mountain Abbey will be released in 2026. I can't wait for you to play it.