Sometimes I can’t tell whether something is a joke or not. I couldn’t tell whether Semantle was a joke until I started getting fan mail. And speaking of podcasts, apparently I’m not the only one with this problem. I just heard on 99% Invisible that when Tez Okano pitched Sega on Segagaga, one of the last Dreamcast games, the execs thought his entire pitch was a joke, so he had to pitch it again.

I’m not as good a writer as Ross Sutherland. That’s why a lot of people didn’t see the humor in my post about the (fictional) 1989 Blue Prince, and thought I meant to actually fool people. Fooling people was really an accident – I just put in a little bit too much work on the visuals. Actually, I meant the commentary as a serious critique: Blue Prince has a very high busywork-to-puzzle ratio, and this is its weakest point (also see my previous note on gambling; Blue Prince literally has slot machines, and it’s sometimes optimal to use them). But there is a lot of puzzle there too – several people assumed that the floppy disk flipping bit referred to one specific room in the actual Blue Prince. Nope. I hadn’t gotten to that area at the time I wrote the post, and I still haven’t solved that puzzle. Instead, I was inspired by learning about Karateka’s upside-down disk Easter egg on Lateral. Yep, another podcast.

Sometimes I feel like I’m wasting my time listening to all these podcasts, but I was heartened to see that Adrian Tchaikovsky mentioned that his Philosopher Tyrants series was inspired by Empire and Revolutions. It’s among Tchaikovsky’s best work, and I can’t wait for the next one. And nobody can accuse Tchaikovsky of unproductivity. To bring it full-circle, science fiction also inspires podcasts; after ten seasons on actual historical revolutions, and after a two-year hiatus, the Revolutions podcast returned with a season on the Martian Revolution of 2247, presented totally straight-faced.

Two more notes that didn’t fit anywhere else:

1. I actually used cool-retro-term, not RetroArch, which is why the font isn’t quite right. I thought about using RetroArch but it looked like it was good to be a hassle to get an Apple II running, plus then I would have had to maybe write Applesoft BASIC. Anyway, I decided to settle for good enough. So that’s why the font isn’t quite historically accurate.

2. I really enjoyed reading Egypt Urnash’s IF-style Blue Prince scene. I did consider whether an IF Blue Prince would be better, but I think seeing the map is really useful, and while you could incorporate a map into an IF game (as Counterfeit Monkey does), it sort of strains the medium a bit.

Here are some things I like about the original:

1. This is a bit of a spoiler, but one puzzle required you to reach an object on the ceiling of one of the rooms. To solve it, you had to take the game’s actual floppy disk out of the drive and put it in upside-down, which turned the whole room upside down. It’s perhaps the best lateral-thinking puzzle in any game I’ve ever played. (Admittedly, I didn’t fully solve it myself – my next-door neighbor Stephen, who was year or two older, had to give me a hint). Of course, the 2025 version can’t have that puzzle (well, I guess it could use a laptop’s accelerometer, but it might be a bit hard to turn a desktop computer upside-down), and the replacement, which I won’t spoil, isn’t as good.

2. Rooms directly described their contents. So the Security Room’s feature which tells you what objects you missed was much less necessary (it’s still there because of spreading, but you only need it later in the game). Does someone actually enjoy using the metal detector to hunt around every room for coins, at least after the first time?

3. The game was much quicker to play. Instead of having to wander around a (beautifully rendered, admittedly) 3d space in order to explore a room, you could just read a few lines of text, and press an arrow key. The keyboard is, of course, wonderfully responsive. This is my main complaint with the 2025 remake: why use all of this 3d technology just to make the game take longer to play?

Anyway, if you bounced off the Blue Prince remake because of the slow pace, do yourself a favor and try the 1989 version. Once you get used to the minimalist aesthetic, you might like it better. The floppy-disk image is available on any of the usual sites, and it can be played on an Apple emulator.

Anyway, here are some responses to the Hacker News comments:

Veneer

I arbitrarily picked the number six for the number of mistakes, but I’ve actually made way more than that. For instance, when I got my veneer, what I should have done is asked my dad how to use it. He’s a real woodworker, and undoubtedly the advice he would have given would have matched that of mauvehaus on HN: a complicated gluing and clamping procedure for a tricky material.

I also probably could have gotten away without gluing the veneer at all, but I was worried about it wiggling around while trying to position things on it.

Non-Steam versions

Someone asked if I would release High Mountain Abbey anywhere other than Steam. Definitely – it’s the right thing to do, it’s not much more hassle, and maybe it’ll get me some more sales. I’ve created an entry on Itch. Note that the price may change – I have very little idea how to price games.

Wild walls

gmueckl made two suggestions:

His first was “wild walls”, a film production technique where walls can be removed. I’ve consider this, but:

1. This screws up the lighting much more than holes. I think film has really bright lights, which means any light leakage through a wild wall would be minimal. But getting that kind of lighting into a tiny diorama is tricky.

2. If my dioramas were really precise, there wouldn’t be gaps between the wild wall and the rest of the set. But they’re not. It’s particularly tricky to avoid gaps in the cave walls, which are not at all flat.

3. I actually do this where it’s feasible. For instance, in one room, the floor is “wild” – the rest of the walls lift up. Rocks hide the seam. In another, the ceiling lifts off. And in a third, the side wall is wild, and I hide the edges with some columns.

Git

User gmueckl’s second suggestion was to use a SCM other than git. If I were collaborating with other devs using this SCM, I would worry about what was best for collaboration, or maybe, most space- and bandwidth-efficient. But I’m honestly mostly using a SCM because it’s how I’m used to building software. I almost never need to look at history. And in the unlikely even that my primary dev machine dies, and I need to clone a few hundred gigs to restore it, I can afford to wait a few hours or even a day – I’ll just spend the time working on some other part of the game.

The big advantage of git is that I know it really, really well – I’ve even contributed a little code to git myself.

Someone else suggested using git-lfs. This would, in theory, help – I wouldn’t need to download all of the raw assets if all I need is the game portion. But I can already do that with partial clones. Github has some better pricing for LFS storage, but (a) I prefer to avoid Github because I think monocultures are bad for the web, and (b) most of my files aren’t actually large – it’s just that there’s a large number of moderately-large files (about 20k files so far) and (c) I don’t trust git-lfs because of their treatment of a bug report I filed. I recognize that this last one might be somewhat petty – after all, lots of people successfully use git-lfs. But I get frustrated by having my bug reports closed without anyone checking if they’re still bugs.

Qualifications

Another commenter wrote:

Yeah, this plus the apparent lack-of-planning regarding lenses & field of view make me wonder if OP had any of the background they should have had in stop-motion animation?”

This one is easy to answer: absolutely not! Instead, I have relentless enthusiasm and a willingness to make mistakes. It’s working out well so far!

I’m a mostly self-taught programmer. This has given me the arrogance to believe that I can do almost anything.

Dioramas weren’t my first choice for art. They were my third choice, after finding two illustrators who failed to work out. I think if I had had the choice, I would have rather signed on to this particular game as just a puzzle designer and programmer, leaving the art and story to someone else. But that didn’t happen, so I’m muddling through. I think the results speak for themselves: nearly everyone I’ve shown this game thinks it looks cool.

I say “do almost anything” above, because there are at least two things I know I can’t do: illustrations and music. My inability to illustrate is why I’m using dioramas. For music, finding a composer has been really tough – between a small budget and rather idosyncratic tastes, I don’t have a lot of options. I’ve actually got a composer under contract, but I don’t want to say more until I’ve got at least a few rough mixes in hand.

Anyway, the point of the post is: you can make a lot of mistakes and still succeed in making a cool game.

The process

A few folks mentioned enjoying learning about my process. For you, here are two videos:

• Kerning, the hard way
• Making books for High Mountain Abbey

Speaking of comments, someone at a meetup suggested that I should film my work process, because everyone likes YouTube craft videos. It’s easy, he said. Well, no, it’s not easy – it’s yet another craft.

That kerning video, for instance, omits the bit where I fix up the kerning after taking a photo, because it turns out that it’s not quite right for the aspect ratio Steam wants. And the books video took me three tries, because the first time, my hands ended up out of the frame, and the second time, the hands were out-of-focus because the camera (that is, my phone) preferred to focus on the background.

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.

(OK, I’m not really calling it “Real Engine”; Epic please don’t sue me).

What’s the Real Engine? Simple: instead of modeling a space in Blender and then texturing it, I’m building a diorama and taking some pictures of it. Then I import it into the point-and-click game engine I built and connect up the pictures into a space. If something needs to move, I either do stop-motion animation, or I photograph the components separately and animate it within the engine.

Here’s an example:

Why?

Why would I do a cockamamie thing like this? Well, it’s not the first thing I tried. The first thing I tried was reaching out to an artist whose work I’ve been enjoying for decades, who lives in my city, and who claimed to be inspired by Myst. He agreed to work with me on the project, which was just perfect.

Then I guess he thought better of it, and he ghosted me.

So I found another artist who wanted to work with me. He didn’t ghost me. He just didn’t do the work, and eventually told me that he wasn’t going to do the work. I think there was some sort of illness involved. So we parted ways. It’s too bad, because he clearly understood where I was coming from, and had some great ideas.

So at that point, I could have gone and found yet another artist. But if two artists had failed, why would I think a third one would do any better? As Einstein supposedly said (but didn’t actually), “the definition of insanity is doing the same thing over and over and expecting different results.” Also, I had to consider my emotions: it’s heartbreaking to think you have a partner, and then realize that, actually, you don’t. I didn’t want to put myself through that again.

Now that I’ve started working on this myself, I realize that it’s possible that I was asking too much of the artists. I’m going to end up spending three times as many hours doing the art as I’ve spent on the code, at least. I’ve had thirty years of experience as a programmer, and much less as an artist, so it’s not really a fair comparison. But it’s still the truth.

How long will this take?

To get started, I prototyped a single room. Actually, I only did one end of the room, because it was just a quick test. My prototype only took a few days. So I thought that maybe it would only take a few months to do a full game. I was wrong. Here’s the room:

Looking at that image, I hope you’ll see why I thought this was a good idea. But look a little closer, and you’ll see why I was wrong about the timing. There are four major issues (and some minor ones):

1. Light leaks. The edges aren’t well sealed, because I wasn’t thinking hard about light.

2. You’ll notice that you can see a nubbly gray thing behind the scroll niches. That’s a random blanket that I put there to block light. I actually needed to do a bunch more construction to hide that background correctly (replacing the blanket with duvetyne would help too). Anyway, the visual design of that scroll case could use some work – the niches should be diagonal, and go less close to the walls.

3. The table has tiny dowels for legs, and the top is plain construction paper. I would rather have something that looks a little more like wood, and legs that aren’t so spindly – even if it’s just faux finishing.

4. The windows don’t have glass in them, and in fact, the muntins (or cames, or whatever the bits between the glass are called in this context) are made of the same paper as the walls.

5. The ceiling is flat and boring.

6. The depth of field is not great, about which more later.

This is the same problem that AI art has: it’s fine on first glance, and then you get closer and it all falls apart. As John Salvatier notes, "Reality has a surprising amount of detail".

The thing is: I could fix most of these – but fixing them basically means rebuilding the entire room.

So “a few days” becomes a few weeks or a month, and now I’m looking at a much longer timeline. Fortunately, nobody is going to scoop my idea, because nobody else is insane enough to build a game this way.

Prior Art

OK, maybe someone else is. There’s Harold Halibut. They’ve built real objects and then used photogrammetry to put them into a traditional 3d engine. It’s a neat idea, but my idea involves one fewer step.

Update: Also apparently Lumino City, Papetura, and The Neverhood use similar physical modeling techniques.

Why not Blender?

Why don’t I just use Blender like everyone else?

1. I hate Blender. I mean, I understand that it’s the standard thing that everyone uses, and I know that I would eventually get used to the UI. But almost every time I use Blender, I end up mangling the geometry in some way that requires either me to take a hundred years of clicky work to fix it, and in the end I wish I had remade the part from scratch.

2. I’m not much good at textures. I could just buy a bunch of textures, but getting them to look nice together would be tough. And I would still end up with a bunch of repetition, because there’s just no way a solo dev can get enough textures. Cyan manages it – when playing Firmament, I didn’t notice any texture repetition (I did notice that the music was an incomprehensible drone, except for the totally perfect VNV Nation track at the end). But this seems to scale with studio size. In this screenshot from Quern: Undying Thoughts, take a look at the wood texture on the dock. They get a little extra mileage by mirroring the texture on alternate boards, but it’s still the same texture:

Zadbox, which created Quern, is smaller than Cyan. Going down to a single-person studio, Haven Moon is a noble effort, but I got awfully bored of seeing the exact same brick wall in dozens of places.

I didn’t want to do that to my players. The whole point of games like this is to explore a new world. But if you’ve already seen all of the textures on the first island, then you’re not really exploring a new world.

By contrast, here’s what my staircase looks like (before I install it – it’ll be in a stone tunnel, so the details might be harder to see in situ):

Every stair is different. Some of the angles are a little off square, which is totally fine, since it’s supposed to be sort of beat up and ramshackle.

Why not AI art?

I’ve addressed this before. But also consider the following prompt:

Painting based on Goya’s Saturn Devouring His Son, but with a giant eagle eating a tiny headless monk in a brown robe. The eagle holds the monk’s in its giant claws. Crimson fluid leaks from the monk’s neck.

So, AI is bad at prompt following. But also, it would be really hard to have it do two images of the same room from different locations. I would probably have to generate one image, then convert it to a 3d model, and then use controlnet. I’m not sure this is less work than any of the other methods.

And even if I did build a gray box model to use with controlnet, Midjourney doesn’t even understand that if there are arches and columns, the arches have to be on top of the columns.

Process

So given that I’m going to use the Real Engine (Okay, okay, Epic, I’ll stop now), how will I do it?

What kind of space?

Myst and Riven are set on a series of islands. Haven Moon is set on a series of islands. Quern is set on a series of islands. Firmament is set in… well, I won’t say to avoid spoilers, but a small number of relatively enclosed spaces. In a game like this, any time the player tries to walk off the edge of the map and just hits an invisible wall, it’s immersion-breaking. That’s why there are so many islands.

So I needed space without a lot of freedom. I decided on an abbey high in the mountains. The mountains will be a matte painting, and most of the game will take place indoors. It’s not exactly an original setting for a mystery, but I think I’ve put my own twist on it. The setting then gave me enough inspiration to put together a story. And the story has then suggested certain aspects of the puzzles.

Roughing out

First, I drew a floorplan in Inkscape. (I’m not sharing any maps here because I don’t want to spoil the fun of exploring the space once the game is released). This just marked out the walls and doors of each room, so I could get a sense of how the pieces fit together.

Then I copied that floorplan into Blender, building up the volumes of the space. This let me more easily see how the roof lines would appear, and fly around to get a sense of scale. I guess some people can do this mentally from just a floorplan, but since I plan to have complex roofs, Blender was easier. I left some interior spaces out of the model, since they don’t have roofs.

Scale

Dollhouse scale is usually 1:12 (for a delightful note on this, search this page for "Mervyn O’Gorman" ). This makes the arithmetic easy for Americans like me who grew up with “customary units": an inch is a foot. And it’s workable for interiors: you can fit a large room on your table, if you have a big table, and you can fit a phone camera into a small room and still get things in focus.

But if you want an exterior of the entire abbey (and you definitely do!), you either need a bigger workshop than I have, or you need to take a hint from model railroading and go to 1:48 scale, which the model railroading folks call “O scale”. Having two different scales is annoying, because it means that you can’t seamlessly blend – if you want a door from the interior at 1:12 to the exterior at 1:48, you can’t just put the two dioramas next to each other, you have to put a green screen on both doors and then later paste in to each the appropriate photograph of the other one.

I think I actually will end up using a third scale because 1:12 is too teensy for some of the really complex bits, but hopefully that’s just for a room or two.

For another wonderful article of scaling, see John McPhee’s article The Ships of Port Revel, in his collection Uncommon Carriers. “At scale the mallards are thirty feet long,” is a line I often think of as I work on this project.

Photography

I had initially planned on shooting the whole thing on my phone camera. There’s a problem with this: my phone is six inches wide, and the camera is at one end, so if I have a narrow hallway, I can’t have the camera centered unless I hold it vertically (which loses resolution, since the game will be designed for 16:9). Also, the phone camera is very smart, which means that I’ll be constantly fighting it to get consistent lighting. I know there are APIs for manual mode, but building a custom Android camera app would be a lot of work.

A SLR was right out; they are giant compared to the space I’m shooting, and even macro lenses typically have too-large minimum focal distances.

Keep in mind: the camera must operate inside an entirely enclosed space, and I need to see the pictures as I go in order to make sure I’m getting what I want, and I need to do this without picking up the camera to look at a screen.

So I decided to build a camera. Well, I bought a Raspberry Pi camera module (and then a second one when the first one wasn’t good enough), and built a tiny Flask app which runs on the Pi to take pictures and allow me to adjust the exposure and focal length over wifi. The Pi is powered by one of those phone battery packs, which is cheap and runs about all day before needing a recharge. It sits on some wooden blocks so that the photos are all from the same eye level. The camera is a bit noisy, but long exposures help a lot.

Actually, I ended up buying a third camera and a second Pi. The OwlSight only has a 68 degree horizontal field of view. My aspect ratio is 16:9 (1.77:1), but for most shots it’s actually 1.956:1, because I leave a little margin around the edges so that I can show it as you rotate, making the direction of rotation clearer. So I ended up having to move the camera very far away from the wall to get enough into view. With a second camera at a slight angle to the first, I can stitch two photos into a panorama.

I’m also doing focus stacking. The idea is that a macro lens has a relatively shallow depth of field. This is a distinctive look: things shot in macro look like they are shot in macro. If you want to make large things look like macro, you use tilt-shift photography to fake this effect. If you want the opposite, you use focus stacking: take photos at multiple depths of field, and choose the in-focus parts of each. The stacking happens before the panorama, since then I don’t have to worry about panotools picking the same points of correspondence for each image pair in the stacks.

The Pi doesn’t have enough RAM to easily run focus stacking software, so my Flask app just scps the files up to my desktop, and then runs the focus-stacking software there. Then it copies the composited image back for display. Then if I like the pic, I can press a button to copy it back into the game’s assets directory (named appropriately). I also save the images from which I built each focus stack, in case I want to do more editing later.

The whole thing is slightly janky, but there’s a trade-off between spending time improving the app and actually making the game. By nature, I’m very excited about working on tools. As an indie game dev, that’s a trap. Because of the long exposures at multiple focus levels, I do have a bit of time between shots to futz with the camera code and write the post that you are reading now.

Every room I build, I learn something. For instance, the OwlSight camera’s auto white balancing seems to blow out reds. I didn’t notice that until I tried to shoot some red-orange needle-felted balls. So I’ve added manual white balancing control.

The second room I built has a rough floor. This means that the camera stand (which is literally some random wood blocks that I had laying around) doesn’t sit flat. Or maybe the floor just isn’t level to begin with – there was definitely some warping when I applied the air-dry clay to the masonite, and I’m not sure gluing braces on later quite got it all out. Mostly, I don’t care if if the camera is a bit off level, but in one case, I have a machine on the wall that needs to be dead square to avoid annoyances during animation. So I built a camera leveler with another wood scrap. It has threaded inserts at the corners, so I can turn screws to adjust the height of the four corners of the cameras.

The third room ended up having insufficiently bright lighting. I bodged together a partial solution, but it’s still going to be the dimmest room in the game. Next time I’ll use brighter LEDs.

Architecture

Architecture is really hard. Consider the chapel: I picked the shape for it based on where it fit into the rest of the monastery. There are some subtle constraints – like, I really wanted one of its walls to be blocking the view from the door to the front hall, because otherwise that door would open into the garden, which is at O scale. And I did a flat angled roof because a gable roof would be hard to square with the six-sided floorplan. Also, I think a gable roof with elaborate decorative skylights might be weird, and skylights are the only hope for lighting a room of this size.

After examining the model in Blender, I decided that it could be a chapel. A bit 1960s looking, but OK. Unfortunately, this meant trapezoidal walls, and compound angles.

The skylight wasn’t going to be quite enough light, so I added a bunch of fenestration. I decided on stained glass, and tried several ways to make it look right. In the end, one of the windows has a complex pattern which I printed on acetate, and the others have simpler patterns which are alcohol-based ink on acrylic. The acetate is brighter, but the acrylic is good enough and comes in larger sizes.

Of course, the windows have to be high enough that you can’t see much out of them, because outside the windows is the garden, which is still a different scale. I guess I could have just planted some trees right outside, and built two scales of tree, but then I wouldn’t as much extra light. With high windows, the sky will still be visible. So I just painted a rough blue-white gradient on some cardboard, which, through the acrylic, is good enough.

If this were actually built in the 1960s, the windows would be aluminum rectangles. But rectangles are boring. I went with bird-inspired shapes, which are hopefully a bit Gaudi-esque. Birds are a big theme in this game, for reasons players will discover.

I made the chapel floor with “stone” tiles. To make tiles, I used poured paint on paper, cut into squares. This was a bad decision, because I had to pour like a dozen sheets to get enough squares, and then I had to glue them down (I used gray paint as the glue, so it could double as mortar). The good decision I made was to align it diagonally, which meant that I could hide some of the unevenness. But then I didn’t do a great job of getting straight lines, so I had to trim some of the tiles. Probably nobody will notice. Also the tiles peeled some, which means that the floor looks kind of cracked. Fortunately, the story of the game makes this not totally unreasonable, so I’ll just knock over some of the pews and throw some prayer books around, and say there some sort of catastrophe here.

The walls are covered with Thai kozo paper. But where the paper joins, it doesn’t look great, so I built some columns to cover those places up. The columns are foam covered with more kozo paper. For a couple of the interior corners, I used some wood framing. There are a lot of little decisions like this: I need to cover an edge or a corner, so I add a little trim, which ends up adding visual interest to the space.

Tools and materials

Premade dollhouse furniture

No. If I do that, my game will look like everyone else’s dollhouse. Also, in theory it’s copyright-infringing, although in practice, I’m unlikely to get sued. I tried to use some lighting marketed for dollhouses just to avoid wiring my own LEDs, but they ended up not being bright enough. Dollhouses usually have one open wall so that you can get Sandy Toksvig inside them, so lighting inside a dollhouse is for looks not for illumination. So I won’t try that again.

3d Printing

I want to avoid 3d printing as much as possible, because 3d printed stuff lacks that handmade look. Also, it means I have to use Blender. Well, when I’m lucky, OpenSCAD. I have needed a few prints. First I ordered online, then I borrowed my brother-in-law’s, and now my wife brought me home a 3d printer that someone in her office was just giving away for some reason (this is how the rich get richer).

The other bad thing about 3d printing is layer lines. I had some bench parts printed, and I thought I could cover up the layer lines with acrylic paint, but it it turned out that even two layers of gesso followed by two layers of paint didn’t solve the problem. When your camera is four inches from the subject, every little line shows. The actual solution is XTC-3D, which is a rather unpleasant product: expensive, short pot life, hard to apply thinly, and weird-smelling. But it does the job, which is the important thing.

Speaking of extremely fine details, my workshop is unfortunately also inhabited by two long-haired cats. Every time I see them, I think “Did he who made the lamb make thee, and if so, why did he make you shed so damn much?” Keeping the hair out of the dioramas is quite tricky, and I often find that I have to remove a stray hair and reshoot.

Clay

Even though I have a full pottery studio with a kiln, I’m going to use very little ceramic clay for this project. One reason is that the cycle time is high: I need to accumulate enough stuff to fill a kiln, and then run the kiln, and then glaze, and then run the kiln again.

Ceramics has a very distinctive look, which is mostly not what I want for this space. I do have plans for a couple of pieces – which, given the cycle time, I should probably start on.

Some of the door moldings are made from DAS air-dry clay. It’s nowhere near as nice to work with as real clay, but it’s surprisingly strong – you can pick up a piece of molding that’s 1/16” thick and 7” long by one end, and it won’t break. Try that with green stoneware clay and you’ll have a bad day. And you can cut it with a knife even when it’s dry. I also made a vase out of it, but getting something round at that scale with that clay is tricky. I should probably just use real clay for that.

Epoxy clay is really nice to work with, if you’re quick. I made doorknob parts with it, and filled in some of the cracks in the door moldings. It’s hard as a rock once it’s dry, so you don’t want to be too sloppy, but it remains sandable when hard.

Needle felting

Instead of glowing screens, I’m probably going to do most of the screen-like puzzles using needle felting. I think in my ideal world, every puzzle would have a reasonable and diegetic hardware manifestation, but that’s not quite how the puzzle design ended up going.

So far, it’s a lot of fun. I’m not anywhere near the level of Andrea Love, but I can make cool stuff. For my first animation, I made ten frames (for each of the three animations), then I used RIFE to add three frames in between each of my originals. I think this was especially helpful at the end of the animation, since my animation loops back to the first frame, but the felt didn’t end up exactly perfect. At 20 FPS, it still looks like stop-motion, which I think matches well with the handmade look of the rest of the game. I’ll probably reduce the frame rate of the other animations in the scene, and add a little jitter, to match.

(This video has a white rim which will be masked out in the actual game – doing alpha channels in video is tricky, so I’ve just written little shader which applies a mask at runtime)

Release

I’m really excited to be working on this project. I go to work every day happy, and I fall asleep thinking about what I’ll do next. I can’t wait to show you the world I’ve built.

High Mountain Abbey will be released once I have designed, constructed, and photographed a lot of dioramas. Hopefully 2025 but early 2026 is more likely.

Dominus told me that Bill Gosper was also inspired by …MEOW…, and made a version of this game. His version allows only four-letter substrings, and allows those substrings to occur anywhere in the word (so GULC would be valid). When Dominus mentioned Gosper’s work, I assumed that it was in, like, 1983, since Gosper is fifteen years older than my parents, but it was actually just a couple of years ago. So I’m not that far behind the curve. Update: No, actually I am way late. Dominus further informs me that he learned about it in More Mathematical People(1990), p 114. Gosper attributes it to a friend of his.

A former co-worker mentions Wordiply, a Guardian game with non-unique middles. I hate it, because the longest words are very often a mess of affixes. Consider “utel": the best word is “absofuckinglutely”, which contains both an infix and a suffix; the best word they are likely to actually accept is is “irresolutely”, which contains both a prefix and a suffix. And they let you riff on affixes, so you can do things like remitting, remittingly, unremittingly; this is often a totally reasonable strategy. There’s nothing wrong with affixes, but there’s also nothing interesting about affixes.

A game that plays somewhat like Middles is Superghost; Jed Hartman describes it nicely; there, the goal is not to make a word. Another friend mentioned it in the context of a James Thurber piece from 1951 (paywalled; your library may have New Yorker archive access). The logical next step is, of course, Superduperghost, which allows inserting letters at any position. Jed Hartman also describes this version; Wikipedia says it wasn’t invented until 1970, which seems surprising.

Hartman also mentions “the occasional several-minute wait between letters”, which points to a problem with this whole category of games: without a time limit, you can often spend hours thinking about a turn. Gil Hova’s Prolix solves this problem with a timer. This is a problem I complain about whenever someone wants to play Codenames. Yes, Codenames comes with a timer, but nobody uses it, and it’s too long anyway. This is one reason I wanted a game like Surfwords.

There are often a lot of ways to approach the same game concept. Today I was at MoMath and discovered Balance Beans. I had definitely considered making a game on this premise, but mine was going to be a computer game, and it was going to involve trucks trying to drive across the balance beam, with some slop in the system to allow a truck to be driven onto just one side. Also, my trucks were going to have different weights at the same one-square size, as opposed to having size and weight conflated and having connected groups. After playing it, I think their choices might be better. But mine would have offered some neat sequencing puzzles. (Just a note: their physical design is a bit crap; if you aren’t careful while removing a piece from the heavy side, the motion will disrupt some of the other pieces).

PS: I’ve also corrected a flaw in Middles. Dominus and another player mentioned that yesterday’s EYAN could be the somewhat obscure word ABEYANCE instead of the expected CONVEYANCE. I’ve added a button for this situation, which lets you enter an alternate answer and (if your alternate answer is on my long word list and you entered a letter that would have been correct for the alternate answer) gives you a point back. This is a weird solution, but I didn’t want to just accept alternate answers as you type them, since that could lead a user to a word that they think is obscure.

A while ago, I worked a company whose initials were TS. This led to some fun times: Accounts that started with TS were assumed to be system accounts, so when a human named Tsutomo (or something) joined the company, his account got treated weirdly. IIRC we renamed his account rather than changing the system.

I was working on version control, and we wanted to find a name for the new system, so I suggested “nuTShell”, being the best word I could find that contains the letters “ts” in the middle. My team lead immediately replied, “O God, I could be bounded in a nut shell and count myself a king of infinite space.” Which is exactly what I was thinking. But nobody else seemed to appreciate the Shakespeare, so we went with a different name.

And then there’s this Tumblr post. (It will probably get lost, so for future reference, it reads: “List of words containing “meow”: meow, meowed, meowing, meows, homeowner"). The original version of that Tumblr post (since deleted) is from 2016; I don’t remember when I saw it. But it’s been living in my head ever since, and eventually, I realized that there was a game there.

The game works like this: I give you the middle of a word, and you try to guess the rest, one letter at a time. Every time you guess wrong, you lose a point. At zero points, you lose. The secret word is chosen so that its middle is unique among commonly-known words (ignoring plural nouns and singular verbs). For instance, the middle OBC appears in the common word BOBCAT and no other common singular word (it also appears in the uncommon word MOBCAP, a kind of bonnet that nobody has heard of).

There are a lot of words that have unique middles that nonetheless are bad candidates. DUSTRIO is bad because it’s obviously INDUSTRIOUS. WJ is bad because it’s NSFW. INGEM is bad because while INFRINGEMENT is the more common word, IMPINGEMENT is common enough that some players will know it. For this determination, I used a combination of Brysbaert, M., et al and my own personal judgement (they think impingement is non-prevalent, but I think it’s prevalent, possibly wrongly, because it’s something I’ve experienced). Also, Brysbaert is lemmatized, which makes life harder.

But I have about 4,000 words (I still might remove some when I take another look), which is over a decade of game before repating. Not quite Wordle, but not bad.

Give it a try.

Here’s the set-up. Actually, here’s the pre-set-up: puzzles in the game are both entirely arbitrary and entirely diegetic: some asshole has stranded you on this puzzle archipelago and is forcing you to solve his puzzles.

OK, now the set-up: You’re on an island. There are two other islands, one to the South and one to the North, and you can’t presently get to either island.

There’s a green laser thing shooting out of a crystal. You can rotate a reflector doohickey to make it point to another crystal on the North island, at which point you can press a button and “ride” the laser across. There’s also a crystal on the South island, but you can’t point to that one because it’s too high up. There are other reflector doohickeys visible but not reachable.

When you get to the North island, you find a machine (actually, two, but they function in tandem), and more reflectors. The machine controls (in a way that I will leave vague) the enablement and orientation of all of the reflectors. You also find a piece of paper which describes a particular set of reflector orientations that it wishes you to achieve.

If you manipulate the machine appropriately, you can make the reflectors assume this orientation (and enable them all). This machine is pretty cool. Not the world’s most innovative puzzle, but (unlike many of Quern’s puzzles), not readily susceptible to brute force. I did not regret the minutes I spent figuring out how to make it do the thing.

Completing the pattern gives you a new way to travel back to the central island. It also makes a lever pop up, which lets you adjust the initial reflector upwards so you can hit the crystal on the South island.

This is stupid.

The path that the new pattern sends you on takes you around the otherwise inaccessible back side of the central island. Instead of having the South island crystal high up, they should have had it obstructed so that it could only be reached from the back. You would still need to do roughly the same reflector manipulation, but instead of doing it because a piece of paper told you to, you would be doing it because it would directly let you reach your goal. There’s no need for the lever, in that case, and no need for the piece of paper. (This also requires either a slight change in the mechanics of crystals, or one more crystal, but neither would break the rest of the game).

This would have a subtly different effect, in that you couldn’t travel directly from the central island to the South island. But that’s not a path you need to take more than once (OK, twice, I didn’t notice something the first time I was there). And anyway, once you’re there, a fast return path could have been provided (Quern does a lot of this).

The reason my design is better is:

1. It is more interesting to figure out how to use a tool to accomplish your goal than it is to figure out how to input a pattern because a piece of paper told you to.

2. The lever is an unnecessary piece of hardware that doesn’t contribute to making the puzzle harder or more interesting.

Possibly even better would be to have the reflectors arranged roughly as they currently are, but while you’re riding the laser the long way around the back of the island, you can see something that you would then need to use to decide how to change the routing. I am not sure this idea would actually be better, because I found the laser-riding to be headache-inducing. But at least it would have fully used the possibilities of the set-up.

Maybe you could argue that it’s diegetic that the puzzle has this weird lever epicycle (because the dude who has trapped you here is just not a good puzzle designer), but that is the last refuge of the scoundrel.

Before I begin, let me say that I’m not dissing Generated Adventure or the people who created it. They made a very impressive tech demo in 72 hours, and if you don’t look too closely, it’s rather pretty. They were under tight time pressure, and they were specifically aiming to use only AI tools. They did better than I would have in 72 hours (although as a parent, the idea of devoting 72 straight hours to anything is totally unimaginable). It’s good enough to make me consider Deform over Godot for a project like this (I’m sure either could handle it, but they did it so fast!).

But I feel like something that gets lost in the discussion of AI-generated artwork is the turds. Here’s an example of what I mean: it’s one of the sets of images that Midjourney generated for Generated Adventure (I don’t think any of them ended up being used for the game).

At first glance, it’s fine. But then you notice the turds.

Here’s what I mean. Green marks blurry object edges, which I’ve complained about before. Some of these might be the webp compression of the image from the Medium post, so I haven’t been too harsh here. Purple marks bad angles: shadows that don’t match, a wall that’s also a floor, and different-length legs on a … well, I have no idea what that thing is. Blue generally marks things that are unidentifiable, although in the top-right one, it marks the only floor-tree (?) that has a pot. Unidentifiable stuff is a venial sin; it’s a fantasy game, and sometimes there’s weird stuff in a fantasy world.

Red is the real turds. Stuff that is so our-of-place as to break immersion. Often it’s unidentifiable, but sometimes it’s just in the wrong spot (like the faucet in the top left which isn’t over a sink). The bottom left has a fractal turd: the roof of the hutch has a weird asymmetrical fold at the top, but also, a bedroom should not contain a hutch with an outdoor roof.

Once you start looking at AI-generated art, the turds are everywhere. Midjourney often “solves” this by doing images that are impressionistic rather than representational. I googled for “Midjourney dragon”, and this was the first hit:

Other than the inexplicable human figure (?) in the center of the image walking on water, this doesn’t have major turds – but it’s also clearly intended to impressionistic rather than to represent a real scene. I should note that several of the other images from that source do have turds, such as phantom Chinese-looking characters. Side note: I wonder why the dragons are disproportionately looking to the left. In one image, the main dragon head is looking to the right, but clearly that was unacceptable, so there’s also a secondary head-turd looking to the left.

Music

I’m not any good at music, so I can’t immediately identify the musical turds in the AI-generated music from AIVA. This is what Generated Adventure used. AIVA seem to be generating MIDI files, so they won’t have the same sorts of errors as AI image generators, which operate on a pixel level. But I can say that their prompt following is bad. I uploaded the first track of the Surfwords soundtrack to AIVA. Here’s what it sounds like:

That’s a track composed by a human. One of the tracks that I sent him as inspiration was this one (skip to 0:24):

He nailed it! Patrick’s track is maybe a little less skrawnky, but it definitely captures the feeling and instrumentation.

Compare AIVA (I uploaded Patrick’s track rather than the Moon Hooch as a “influence”, since I have the rights to it):

Sure, the BPM is the same (according to a random online BPM detector). Maybe the key signature is also the same? But it’s not even the right instruments – AIVA suggested “Clean Rock Ensemble” for this track, but my track is brass. (AIVA’s generated tracks with the same influence on the Brass Ensemble setting sound even less like the original).

If you don’t have a vision in mind for what your music sounds like, AIVA is maybe fine. Like, it sounds like generic music. But if you do have a vision in mind (as I did for the Surfwords music), AIVA is not there yet.

Conclusion

Please don’t tell me about how I could fix this by twiddling the Midjourney or AIVA prompts.

AIVA’s config options seem to be designed for people who understand music much better than I do. Maybe it’s a good tool if that’s your situation. But why offer to let me upload an influence, if you aren’t going to do anything other than extract the BPM and key signature? At least get the instruments right!

And yes, you can paint out the turds in Midjourney and tell it to fill in the area again until it gets it right. But the shadows are still going to be annoying, and the iteration time is painfully slow.

Soon, this might be fixed. But not today. It’s frustrating to be so close, and to have everyone hyping how close we are, and to be stuck with turds . (Also please don’t say mean things about the Generated Adventure folks, who set out to do a thing and successfully did the thing; none of this is directed at them).

About the game

Deco Deck is a new kind of logic puzzle. If you like KenKen or Two Not Touch, you might like Deco Deck.

Here’s what a mini puzzle looks like:

Every card has one of five suits, and a number from 1-9.

The goal is to link up the cards in connected groups of five, such that each group forms a valid “hand”. The hands are: straight, flush, full house, five-of-a-kind, and rainbow. A rainbow is one card of each suit.

Each puzzle has only one solution.

To solve, just link up the cards:

Of course, they’re not all that easy. That puzzle is easier than any puzzle in the game itself. It is the trivial puzzle that I use in the tutorial. I chose it so that there’s no way to go down a wrong path. And it’s got the flush of blue hexagons, which the tutorial is able to describe as “blue” (for people with normal vision), or “hexagons” (for colorblind people). The other shapes don’t have short, unambiguous names.

Here’s a harder puzzle:

Both of the above hands, marked in gold, are valid hands – but one of them isn’t part of the actual solution.

Puzzles come in four sizes. The above is a “large”, which is 90 cards. You already saw mini (30); there are also medium (60) and huge (120) puzzles. Of course, it would be possible to make puzzles of nearly any size, but it wouldn’t be reasonable to put them on a phone screen. Even the huge is pushing the limits of finger dexterity on smaller phones.

Design

As I mentioned at the end of my post about Mosaic River, a dilemma in the design of the tile placement subgame put me in mind of logic puzzles. So I built a puzzle generator. The first version just spat out the puzzle in tab-separated value format:

Then I popped it into a spreadsheet and used the coloring functions there to mark the hands. (I guess I could have printed it and used a pencil, but I don’t keep my printer connected). This proved that puzzles were (a) solvable by humans and (b) fun to solve. I immediately sent the uncolored spreadsheet to some friends, with instructions. But then I realized that building a front-end in Godot would be really easy.

OK, not the most beautiful, but it only took me a few hours to bang together. Godot spat out a HTML5 version, and I told my friends to disregard the spreadsheet and try the interactive version. The feedback was positive. One friend noticed that the difficulty range wasn’t very large – later, I’ll explain how I solved that.

I decided to put in some more work to make it prettier:

I recognize that this is not in fact much prettier. I wasn’t really sure what it should look like. Then a friend introduced me to his friend, who happened to be a graphic designer. I hired him to do the visual design. We considered all sorts of themes: Japanese flowers, butterflies, amoebas, and 90s cyberpunk. But I decided that I liked Art Deco best. It’s very much a programmer’s sort of art – produced by the intersections of simple shapes at common angles. Designed to be built by craftspeople rather than artists.

Without Benjamin, Deco Deck would not have looked nearly this good. I tried to make some Deco-style cards, but they ended up visually busy, and not really very Deco (that is, not vertically symmetric). It’s actually a little tricky in 2023 to do Art Deco, because our eyes have been trained by modern styles. So, we expect bezier curves instead of circular arcs, since that’s what’s easy to do in vector editors.

Later, I tried to design the card backs (a visual flourish seen only for an instant during loading), and instead of Art Deco, I ended up with Fart Deco.

So I’m very glad that I had a good designer to work with.

Rainbows

When I first designed the game, I didn’t think of rainbows, because they’re not a standard poker hand. If they were a poker hand, they wouldn’t be a strong one: with this deck of cards, they would lose to a straight. But I got to thinking about how suits were only used for flushes, and what a shame that was, and then I remembered that I had five suits. Once I added rainbows, I found myself hooked. The rainbow’s weakness as a poker hand is its strength as a puzzle component: it increases the number of hands that each card can be part of, making the puzzle harder. This fixed the difficulty range problem that my friend had identified.

Puzzle generation

Building a puzzle generator was straightforward: I started by building a little library that would generate a random pentomino tiling of given dimensions. The simplest representation of such a board during the generation process is a bitmask (which fits in a register for even huge boards, so long as you’re willing to use SSE registers).

Then I implemented the constraint propagation algorithm from Norvig’s Sudoku solver, with the additional wrinkle that it would report if multiple solutions were possible. Instead of marking squares with a list of possible numbers, I marked cards with a list of possible “situated pentominos” that it could be part of. A situated pentomino is a pentomino, possibly rotated and reflected, with a given top-left coordinate. Or, if you prefer, a list of five coordinates, which are orthogonally connected. Propagation consists of two different inferences: (1) if a card is part of only one pentomino, then no different pentominos may contain that card. (2) if all pentominos for two cards share some third card, then the third card can only include pentominos from the set of shared cards. The second of these isn’t strictly necessary, but it does make solving much faster.

So generating a puzzle works like this:

1. Tile the board with random pentominos
2. Generate a random hand for each pentomino
3. Check how many solutions the puzzle has.
   1. If zero: there’s a bug.
   2. If more than one: pick a random card which could belong to multiple polyominos; re-randomize the polyomino that it’s supposed to belong to.
   3. If one: ship it!

Of course, there was a bug in my first version of this – the annoying kind of bug which causes correct results, but too slowly. So I thought, “oh well, I’ll have to reimplement it in C++”. Half way through the reimplementation, I went to sleep, and when I woke up I realized what the bug was. So I threw away the C++.

As I generate puzzles, I also track the maximum depth that the search has to go down to. The theory is that deeper searches correlate with harder puzzles. So does a wider set of initial possibilities – that is, more possible pentomino per card. In theory, I could have tracked the size of the entire search tree, but in my testing, it didn’t seem to make much difference (and the size of the tree depends on the search order, since a lucky search choice can propagate out to eliminate zillions of possibilities). This is one of the two axes on which I rate puzzles.

The other axis is quality. A puzzle that has all of its complexity in one corner is boring. A puzzle that’s mostly one color is ugly (and the solve gets easy once you know the trick). A puzzle that has flushes on the top and straights on the bottom is less good than one that has them intermixed. I have eight quality metrics. A weighted sum of these metrics is the puzzle’s quality. I generated millions of puzzles, and the final game contains only the top few percent of them. (Of course, it would have been possible to change the puzzle generator to incorporate the quality metrics, but by the decide I knew what the quality metrics should look like, I had already generated zillions of puzzles).

Money

I decided to try a third revenue model. I was inspired here by Knotwords: daily free puzzles, and a subscription for addicts. Like the New York Times Crossword, and like Knotwords, Deco Deck puzzles are easy on Monday and get harder as the week goes on. Unlike Knotwords, Deco Deck puzzles don’t get bigger as the week goes on. The mini is always free, and each day, one of the other three sizes is free; I loop through them. So, on day 1 there’s a free medium, on day 2 there’s a free large, on day 3 a huge, and on day 4 back to a large. So free users get to experience all of the sizes at all of the difficulty levels over the course of three weeks.

The Steam version is just a straight up one-time payment. I didn’t feel like dealing with a whole other in-app purchasing system.

I do all of the puzzles very day (although I do sometimes use a hint on the large or huge Saturday or Sunday puzzles). I’m totally hooked, and I hope you’ll get hooked too.

Development

This one took much longer than expected. When I started this project, I told my wife that I would aim for four or five games in my first year. I’m barely hitting three. One reason is that my kid’s preschool unexpectedly shut down for a month, leaving me with extra childcare duties.

Also, getting the visual design right took a long time. One minor example: on the Monthly puzzles screen, it needs to be clear that you can scroll within each difficulty level. So the layout needs to be tweaked so that, regardless of screen size, a puzzle is half-exposed on the right.

There are also two exciting new developments in my practice: First, I discovered Post Horn PR, a group that does PR for indie games. So as this blog post goes out, a press release will also hit hundreds of game journalists’ inboxes. I’m grateful to them for their help.

Second, I was playing Deco Deck on the train while taking my kid somewhere, and she wanted to try it out. She is four, so she doesn’t fully get what’s going on. But she can enjoy the sensation of linking and unlinking the numbers, and watching them turn colors. And as I suggest connections, she is learning: now she knows what a flush is. I think she especially loves Deco Deck because it’s something her dad made.

Most of the other tablet games that we’ve found for her are, frankly, crappy. There’s the awful critter one which really wants you to spend money on one or more of their in-game currencies. There’s the one that’s supposed to teach math, where getting the question wrong offers a more fun animation than getting it right. Also, one of its subgames is supposed to teach something about even numbers or division, but actually just teaches trial-and-error. Oh, and it had a gratuitous Christmas thing. I’m an evangelical atheist. I don’t need my kid being proselytized to. Can’t we have math without religion? (I wouldn’t object to the existence of an explicitly Christian math game, but I also wouldn’t get it for my kid).

Oh, and then there’s the one that’s supposed to teach reading, where after every lesson, no matter how badly you do, you get a sticker which you then have to place in your sticker book. Sticker book? Who needs a fucking sticker book? Reading is the key that opens the world of books! You don’t need a sticker: your reward is that you accomplished the task. You learned that C makes the sound at the front of “cat” (it’s always “cat”. Always.) Also, it doesn’t do voice recognition, so it can’t possibly teach reading, and also also some of its early tasks are timed, which makes no sense at all for a tiny kid first learning a skill.

And there’s another that has a bunch of different subgames, but one is so much more fun than the others that they have to gate it: you have to play a bunch of the less-fun games before they let you have one go at the fun one. Their actual reason is probably that the fun one is this: you draw on an egg, and then the egg hatches into a critter with your drawing mapped onto its skin. Then they have to store that critter and display in your menagerie, and they don’t want to use up all of your storage space. But that’s not the right solution: the right solution would be to have a hard limit on the number of critters. Then either allow re-coloring an existing critter, or allow you to send excess critters to a farm upstate.

So I am going to make a game that I want my kid to play. It’ll be between ten and twenty small games or other activities. They will mostly not be explicitly educational – no arithmetic worksheets or anything like that. But they will require cognitive skills. They will have intrinsic rewards: yes, there’s a fanfare sound when you solve one, but the real reward is that you did the thing. You accomplished something hard. So far, I’ve got prototypes of four of the games: a working memory game (the game gives you a sequence, you repeat it), an inductive logic game, a game where you move a chess knight, and a graph isomorphism game. What’s a graph isomorphism game?

I’m glad you asked. My original idea was that you would have two graphs, and you would have to prove that they were isomorphic by rearranging the nodes in one to match the other. (I had this idea because I was thinking about how the aspect ratio on modern phones is roughly 2:1 and I wondered what I could do with two squares). But when I showed the original concept to a friend, he didn’t really get it. And then I realized that I could just do direct manipulation, and that the concept was simple enough for a four year old.

One nice thing about building a game for my kid is that I have a tester right there, and she is very excited to try things out. So I get immediate feedback on what’s working. And also unsolicited advice: everything in the game has to be bugs, because once she saw the bees, she got excited.

Intrinsic (working title) is coming probably in late 2023 or early 2024. Tablets and desktop only.

Before I even go into some other game mechanics, I want to digress a bit about poker.

Everyone knows that poker is pointless unless played for real money. This is because the right thing in poker is to fold most of the time, but folding is boring. The only thing that will convince you to play right is the prospect of losing money. But what if there’s another way? Imagine a game that plays exactly like Texas Hold’em (no-rebuys and tournament-style, meaning that everyone starts with the same amount of chips), but with the following change: when you win a hand, the chips you win get turned into victory points and added to your VP total. You can’t use them as chips again. Now, if you go all-in, you will not play another hand even if you win. But maybe you will win enough VP to wind up the eventual game winner. This game still sucks by modern standards, because it involves player elimination, but I wonder if it could be the basis of a more reasonable game. You could fix the player elimination by giving everyone a few chips at the start of every hand, but then you need some way to end the game. Maybe the first one to 500 points wins?

Ok, end digression. On to some infrequently-used game mechanics.

Perception

Some time ago, I invented a game where you try to determine physical quantities. Like, you’re given a box full of weights, and you have to determine how many grams it is, just by hefting it. Or you’re given a rod and asked to figure out how long it is (probably no touching or measuring against your hands allowed). You could do temperature (but only within a narrow range, and it would be tricky to implement), luminous intensity, and time too. My friend Jay suggested absolute pitch, which I hate because I am totally non-musical, but it clearly fits the game.

One of my favorite experiments involves pitch (in some sense): it turns out that the frequency of the tingle of Sichuan peppercorns is 50Hz.

One of the few perception games I know of is played in Ethiopia. A friend of mine went there to design games for girls. She said that the girls never wanted to use randomness in their games. To select a first player or whatever, they would instead hide three stones in one hand and four in another, and ask another player to figure out which hand had more stones. Of course, this is also a deception game.

Short-term memory

Many card games that involve counting use the short-term memory. But I’m imagining something where the memory is explicitly the mechanic. Like Simon, but multiplayer.

Watch a chimp kick our asses at a short-term memory game.

Pain tolerance

Dominus suggests a version of chess where you can make your opponent take a move back by chopping off one of your fingers. This is rather permanent (at least for humans). But what about temporary pain?

In Philip K. Dick’s Eye In The Sky, a character sticks his hand over a cigarette lighter to prove how holy he is.

“Ordeal by fire,” Brady explained, igniting the lighter. A flash of yellow flame glowed, “Show your spirit. Show you’re a man.”

“I’m a man,” Hamilton said angrily, but I"ll be damned if I’m going to stick my thumb into that flame just so you lunatics can have your frat-boy ritualistic initiation. I thought I got out of this when I left college.”

Each technician extended his thumb. Methodically, Brady held the lighter under one thumb after another. No thumb was even slightly singed.

“You’re next,” Brady said sanctimoniously. “Be a man, Hamilton. remember you’re not a wallowing beast.”

This is, of course, not about pain – the technicians really are being protected by God (or, what passes for God in the reality that Hamilton finds himself stuck in). But it gets the idea across: this is a game that people could play, if only we weren’t such wimps.

If you wanted to make a safe version of the cigarette lighter game, you could use the thermal grill illusion. I would actually buy a thermal grill illusion device if someone made a commercial version.

The World Sauna Championships were, I guess, a version of this. One competitor described it as “quite possibly the world’s dumbest sport”. As you can probably predict, someone died and they canceled the event.

Robert Yang made a game about a video of men hurting each other. Competitively? Definitely in some sense. Hard Lads is among the safest-for-work of Yang’s games, but I still would not watch it in any office I have ever worked in. I don’t claim Yang’s game itself is an instance of pain as a game mechanic – but rather that it might portray such a game.

Conclusion

I mostly just wanted an excuse to quote PKD and link to Robert Yang and the Sichuan peppercorn thing.

I just released a new game!

Mosaic River is a mobile solitaire game. You’re an archaeologist, sailing down a river, collecting mosaic tiles, and placing them into a triangular grid to make melds (straights, flushes, etc). Tiles have bonuses randomly assigned at each game.

You can try it now: it’s free (ad-supported) on iOS and Android.

It’s perhaps easiest to explain by describing some of the influences.

Influences

The first is Uwe Rosenberg’s Patchwork, one of the finest board games ever created. In Patchwork, the acting player can choose any of the three tiles in front of a marker, and choosing a tile advances the marker to that position. This means sometimes you might want to take a suboptimal piece to skip over a piece that would be really good for your opponent. In Mosaic River, you draft by sailing across the river and choosing one of the next three tiles. Choosing a nearer tile will allow you to collect more tiles overall, but it has a cost. Choosing a further tile might mean that you skip tiles you want, but in return you gain more optionality later (or, at worst, a few extra points).

Another influence is Diffusion-limited aggregation (DLA). In DLA, particles move around randomly and then connect. You end up with these tree structures. This influenced the design of Mosaic River’s connectivity rules. Half of tiles are “center” tiles, which need to be next to two other tiles, and other half are “edge” tiles, which need to be next to only one. The idea is to create a similar bushy structure. But since you only end up taking a small subset (perhaps a third) of the available tiles, and because center tiles want to connect in multiple ways in a compact cluster, we need to give a little bonus to edge tiles to get the desired shape.

Of course, Lost Cities is also an archaeology-themed card game with five suits, but it wasn’t consciously an influence. It’s just that every kid dreams of being Howard Carter or Indiana Jones. I’ve been listening to the History Of Egypt podcast too, although I think I am likely to give up, since there’s often proportionally more focus on the pagentry of Egyptian religious celebrations than on the narrative than I would prefer.

Ads

I’ve decided to try a different revenue model with Mosaic River than with Surfwords. I’m doing ads. This sucks, and I hate it, but since Surfwords isn’t selling, I’m going to try something different.

It was pretty easy to get AdMob working with Godot, but the plugin is a little dumb: it doesn’t seem to understand that you need different admob ids for Android and iOS but that you otherwise want (usually) the same codebase for each. (Actually, looking at the config, maybe it does understand this, and I’m just doing something wrong.)

I guess we’ll see how ads perform financially. My next game (see below) will try the freemium model and maybe that will do better.

Challenges

Scaling

As with Surfwords, getting graphical elements to scale nicely to different screen sizes is a hassle. I ended up having to adjust the dimensions of the mosaic to accommodate older (wider) iPhones. It looks like phone manufacturers are starting to standardize somewhat on very skinny ratios, roughly 2:1, but older iPhones and Android phones still exist in the world and must be usable. The long skinny shape is actually somewhat restrictive as a game developer – as a random example, on some modern phones, anything circular can take up at most 35% of the screen (for a 4:3 screen, it’s 58%).

As usual, Godot’s layout model is not as user-friendly as one would hope. It even makes me miss CSS, which is saying something.

Google’s Kafkaesque process

Google refused to approve my app, because it was crashing on startup. Weirdly, this didn’t occur during their pre-launch checks. During pre-launch, crashes are reported with logs. During approval, you can’t get logs. This makes no sense. I uploaded a new version with some random added logging, and of course the crash went away. But please let me know if you run into a crash, and, if you can, send me an adb logcat.

Godot-Admob bugs; Apple bugs

edit

Of course, as soon as I released, someone pointed me to an issue that didn’t exist on any of the devices I tested on (and that Apple somehow totally failed to flag – so much for the supposed quality review). Then when I went to upload a hacked-together fix, I ran into a random Apple bug that Apple, of course, didn’t report on their system status page. It eventually fixed itself. The fixed version is now released.

end edit

Art direction

It turns out that I do not enjoy art direction. This is about me: I don’t want to tell an artist that I don’t like their work, and that they have to do it over again. I think I would feel differently if an artist were a true partner in the project, instead of a hired gun.

I’m working with a designer on my next game (see below). This will, I hope, be a different experience, since instead of requesting spot art, I’m asking someone to work out the entire visual design of the game. It’s still a contractual relationship with me taking all of the risk, but it feels like a different story, since it’s not someone working to a specification, but rather someone creating their own visual story.

Shader performance

I used Material Maker to create the two main backgrounds of my game. This is a model that I really like: you plug some nodes together, maybe write some light math, and out comes an image at whatever scale you like. But it’s also somewhat opaque: when it performs badly, you have to go into a bunch of generated code to figure out what’s going on.

The marble-ish mosaic background ended up just baked into an image. Easy, and performant. The river background was way more complicated, since I wanted something animated and not obviously repeating. The problem is that phones have very crappy GPUs, so doing anything at all complicated blows the framerate budget out of the water. I didn’t really expect this, since the game does not have a ton of visual effects. So maybe I’m doing something wrong, or maybe Godot is. Or maybe GPUs are really good at slinging a lot of pixels around but not so good at generative stuff.

I definitely noticed that Material Maker does not have the ability to optimize one common case. And there was another missing feature too, which I just hacked around in the end.

Scoring and bonuses

I redesigned the scoring several times. While working on the code to compute straights, I noticed that a single tile could be part of multiple straights. This meant that the most optimal strategy was to ignore all other melds, and just try to maximize the number of straights. I fixed this by adjusting the scoring: I made straights score linearly rather than quadratically in length, and made them slightly lower scoring on average than flushes or n-of-a-kind.

Deciding which tiles got bonuses was also a little tricky too. Initially, I randomly allocated bonuses. But this didn’t work for “meld bonuses”. Meld bonuses are a kind of bonus which stick to the tiles. They are represented by scarabs, feathers, and eyes. If you have all three tiles with scarabs (say) directly adjacent, you get a lot of points. But you can’t do that if all three bonuses end up on edge tiles. So then I moved the bonuses so that they were just on center tiles. But you could still end up in a bad situation: if two identical meld bonuses end up directly across the river from each other: you can’t (except with another bonus which you might not have gotten yet) collect both. This felt unfair, and thus unfun.

I thought of a number of complicated ways to allocate bonuses to try to avoid this, but none of them seemed likely to work. So I decided to just reshuffle the deck until that situation was avoided.

Discovering America

While I was thinking about how to score intersecting straights, I considered a rule that a tile could only count for one meld. But then the melds would have be chosen carefully. There were three unpalatable choices:

1. The player could choose the melds at the end of the game (creating a tedious task right when the user wants the reward of seeing their final score).

2. The player could choose them during the game (interrupting flow and forcing them to make choices that they would likely regret).

3. The game could consider all of the possbilities and choose the best (creating an opaque scoring system).

I decided to do none of these, and to just allow intersecting straights. But I realized that, on its own, the decision problem was actually interesting – it just didn’t fit with the vibe of Mosaic River. So my next game will be about deciding how tiles should be arranged into melds. I’ve tried it out, and I’m really, really excited about it. Watch this space for news!

Dan Luu posted it to Hacker News, and there were some comments. Here are some responses:

Comments suggesting img2img, masking, and AUTOMATIC1111: that’s what I was doing, as I think the images in the previous post make clear.

Comments suggesting that maybe my prompt was no good: I didn’t put in anything like “oneiric”, or “blurry”, or “objects bleeding into each other”, or “please fuck up the edges.” So I don’t think it’s reasonable to blame my prompt for the particular problem that I was complaining about. One commenter suggested that I should have said “pier” instead of “dock”, but actually, judging by Google Images, I was locking for a dock (a place you tie up your boat).

Comments suggesting learning to draw, or that the problem is that I’m not an artist: actually, I am a bit of an artist: I make weird pottery.

I’m just not just not an illustrator. I have dysgraphia, which makes illustration challenging. The example I like to give, when I explain this is: I go to write the letter d, and the letter g comes out. That’s not because I don’t know what the difference is, or because I can’t spell. It’s because somehow my hand doesn’t do what my brain wants. Also, even if I were an illustrator, I would still like to save some time.

The problem isn’t that I can’t figure out the composition of scenes: as the post shows, I was able to adjust that just fine. The problem is that the objects blur into each other.

Others suggested that I could save time by using 3d rendering, as Myst did. This seems preposterous: Myst took a vast amount of time to model and texture. Yes, I would only have to model a place once to generate multiple images. But the modeling itself is a large amount of work. And then making the textures brings me right back to the problem of how to create images when I can’t draw.

Some commenters suggested that in fact I could get away with fewer than 2500 images. On reflection, this might be right. From memory (it’s been a while since I played Myst), the four main puzzle ages each have maybe 20 locations, with an average of, say three look directions per location. Then there’s D’ni (only a few locations), and Myst Island itself, which has roughly one age worth of puzzles per puzzle age. That would be about 500 images. Maybe they are counting all of the little machine bits as separate images? Maybe I am forgetting a whole bunch of interstitial locations? Still, 500 images is also outside of my budget, though less so.

Comments suggesting that it takes a lot of selection: yes, this is after selecting from roughly a dozen images each time. Generating and evaluating hundreds of images would not be a major time savings. If the problem were that I’m particular about composition, it would be reasonable to search through many images to find a good base (and, indeed, that was the part of the test where I was casting the broadest net). The problem is that I’m picky about correctness, and picking through a bunch of images for correctness is slow and frustrating.

Comments suggesting photoshopping afterwards (as opposed to “just draw the approximate color in the approximate place” during img2img refinement): If I could draw, I would just draw.

Comments suggesting many iterations of img2img, photoshopping, back to img2img, etc: 1. Ain’t nobody got time for that. 2. My post shows me trying that: it doesn’t solve my fundamental problem.

Comments suggesting MidJourney: It’s basically a fine-tuning of the Stable Diffusion model, so it’s likely to have the same problems with blurry and incoherent objects. Its house style is pretty fuzzy, which hides some of the incoherence, but for a game like this it’s important to know exactly where you are, and where an object’s edges are. The Colorado State Fair image (which was generated in part by MidJourney) shows some of the incoherence: look at the woman in the center – what’s that stuff on her left side? Part of the lectern? A walking stick held by the third arm coming out of the waist of her dress? Also, trying to do any refinement through a Discord chat seems even more painful than trying to use AUTOMATIC1111, which is already pretty slow and clunky.

One comment with an improved image: well, it’s a physically plausible object now, if you don’t mind that the dock is now made of stone instead of wood. I wonder why I was unable to get that. The image:

Also, the rightmost post is still sort of fading into the dock at the top. Maybe I was just unlucky? I don’t think the prompt was any better than mine. That gives me hope for the future. Next time a new model comes out, I’ll probably try again.

I am willing to accept compromises on precision: If the palm tree ends up on the left side instead of the right, that’s OK. It’s even OK if it’s a date palm when I visualized a coconut palm. I might even settle for a willow.

But it’s important that it looks like a place you could be in, and that the objects look like objects that could physically exist. This is why I’m so frustrated with Stable Diffusion. It’s so close to giving me what I want. But it’s not there yet, because it does not comprehend physical objects.

I asked for a dock at the bottom of a cliff. It gave me some stairs at the bottom of a cliff (admittedly, some of the other images had some vaguely dock-like things, but none had the perspective I wanted: almost nobody takes a picture of a dock from the water).

Ok, the stairs look great – I’ll just paint in where I want a dock, and have it clean up that part. (I also rearranged the composition a little to make room).

Here’s what I got:

OK, that’s sort of a dock. Like, there’s nowhere to tie up your boat, and it’s got weird protrusions, and it’s somehow below the waterline, but I can work with that. I’ll erase the protrusions, fix the rear, and add some posts.

Then I’ll tell Stable diffusion to just clean up those parts:

Oh look, it decided to put a weird vertical line in the middle of my dock. Why? And also, it keeps wanting to fuck up the right side of the dock. OK, I’ll clean it up with the clone tool:

Sure, we lost a post, but at this point, I don’t care. Stable diffusion, please clean up the clonejunk….

No! You fucked up the right side of my dock again! Don’t you know how solid objects work?

Aargh, I give up. I’ll just hire Mœbius to do the artwork for my game. What’s that you say? He’s dead? Noooooo!

(Yes, I could pay an artist to make art for the game. But I’m not yet good enough at game marketing for this to make sense: The original, 1990s Myst had 2,500 images, which would cost me more than I expect to make this year. Also, it would take an absurd amount of time. So I won’t do that … yet.)

I didn’t start out with a demo, because I was worried that it would cannibalize my sales. I am not worried about that anymore, because to a first approximation, I have had no sales. Surfwords briefly reached #7 on the iOS paid word game chart. This is hilarious, because I’ve sold less than 20 copies of Surfwords on iOS (and less on all other platforms put together).

To me, even before I wrote it, it was obvious that Surfwords is the sort of game that I would want to play. I like very hard word games. I know that Super Hexagon is good. Ghost is fun (if you’re stuck in a car and bored of Botticelli). The combination is just obviously going to be fun.

So why haven’t I sold a zillion copies? Or even enough copies to pay the bills? I don’t know, but I’m going to see if having a demo helps.

And then I’m going to go back to working on my next game.

I love words, and I love word games. My favorite is Montage, which is a cross between Taboo and a crossword puzzle. You have to figure out a playable word, clue it, and have your partner guess before both opponents do, all within a one-minute timer. That’s the level of intensity I crave.

I was also inspired by Super Hexagon: it’s simple, you lose a lot, and with practice, you can improve. Surviving for a minute is a real achievement. One thing I like about Super Hexagon is that it more-or-less could have been written for the Vectrex in the eighties, but in fact it wasn’t released until 2012. This gives me hope for the world: there are games out there that are destined to become absolute classics, that we could be making right now.

Surfwords is a fast-paced word building game. Letters drop from the top of the screen in two columns. You have to choose which column to take at each row, in order to build up a series of words. It’s dead simple: you can pick it up and immediately start playing it. But it’s not at all easy.

I want to talk about some things that went well, and some things that went poorly, in the hopes that I can learn something from the experience.

One of the easiest things was buying music. I had a bit of a false start: I reached out to a band I like to ask them to make music, and didn’t hear back. Then I reached out to another band I liked, and they quoted me a price which, while totally understandable, was outside of my budget. But then a friend pointed me to Patrick Cornelius. I sent him a “mood board” of tracks that I liked, and he wrote me original music with exactly the sound I was going for, at a price I could afford, and within my timeline. Working with a true professional is wonderful. Next time, I will start buying music and images first thing, to give the maximal possible lead time.

A surprisingly annoying thing was the word list. I started with the word list I had used for Semantle, which I had cobbled together from a variety of Internet sources, but it quickly became clear that this was not going to work: it had too many words that no word game player would like: “nd” (as in 2nd, but without the 2) or “nco” (presumably, an abbreviation for non-commissioned officer, except that would be uppercase, and word games don’t usually allow initialisms). So then I tried the venerable “ENABLE2K” word list, but it was also filled with junk. Oh, unscrupulousnesses, sure, unscrupulousness is a noun, it must be pluralizable. No. Also, as the name implies, it hadn’t been updated in a while. So, no “twerk”, or even “blog”. In the end, I did a ton of work to manually remove thousands of bogus “ness” plurals and add in modern words. Of course, the work is never done: while writing this diary, I thought up a more few missing words, and so I had to go in and add them. There’s nothing more frustrating than a word game that won’t allow a word that you know is real. I have some experience with this: I once sent some raffia to Will Shortz to protest the word’s non-inclusion in Spelling bee.

For Surfwords, it would be equally frustrating for the game to expect you to know an obscure word. When you fail to make a word in Surfwords, the game tells you what you could have done:

But if it shows you a word you didn’t know, you’ll get annoyed. Oh, “pseudocholinesterases”, sure, I definitely should have gone for that. So Surfwords has two word lists: words it expects you to know and words you might know. The first is derived from Google n-grams, but n-grams has a lot of flaws: often a word will be present, but its plural won’t. And some short words are supposedly common, but are actually likely common because they’re typos or OCR errors for more-common words. Finally, some words that I think are commonly known aren’t: several of my testers didn’t know the word “fen”. I readily accept that I have a larger-than-average vocabulary, but I think “fen” is a perfectly ordinary word, and I am baffled that it has turned out to be so obscure.

Today, I’m announcing the release of my word lists. They are licensed as permissively as possible, because I would like them to become standard for word games, to replace the Scrabble word list, which is not freely licensed.

So much for the content. Now, on to the technology. I chose to use the Godot Engine. I’ve been supporting them on Patreon for years, and the price is certainly right. Godot has a decent user experience: it’s got a built-in editor, which is fast and responsive. The built-in debugger is usable, although I miss the ability to evaluate arbitrary code at breakpoints ("wait, what did that function return?").

Godot has its own programming language, GDScript, which I have been describing as “shitty Python": it’s a colons-and-indentation syntax with optional static typing. But it doesn’t have function pointers, and you can’t always refer to a class from inside itself.

GDScript is also quite slow. Surfwords stores two sets of words, described above. They’re not exactly big data – the lists total under 200k words, under 2 megabytes. In memory, they’re stored in a trie. But building the trie in GDScript took about 20 seconds on mobile processors. So that had to be fixed. Godot has optional C# support, and the interoperability between GDScript and C# worked fine for me. So my first rewrite of the trie code was in C#. Unfortunately, when it came time to build custom binaries for Android and iOS (stripping out all of the 3d stuff that I wasn’t using to save space), I had a really hard time with the C#.

So I rewrote the loading code again: first, I made a preprocessor in Python to convert the word lists directly to tries (sharing common suffixes) and spit out JSON, and then I wrote code to load the JSON and generate GDScript objects, which Godot can save and load natively. Unfortunately, that was still too slow: each trie node was an object, and the overhead of constructing all of those objects was too high. So my third rewrite stored everything as four large integer arrays (Godot has support for a few types of strongly-typed arrays which are memory-efficient and don’t require boxing). The arrays are: for each trie node, a pointer to its list of children, the number of direct children, a count of total descendants (with the sign bit used to track whether the node can end a word). And for the trie node children, pairs of [letter, child index].

Loading these four arrays could be just a mmap each, although in practice there’s probably a memcpy in there. Finally, it’s fast enough! This has the obvious disadvantage that the code is now incomprehensible gibberish. On reflection, I think I might be able to reduce it to three arrays. But at the beginning of the project, as I wrote my todo list, I wrote a final item: “It doesn’t have to be beautiful code. It has to work.” And the code works now, so I am not going to mess with it to shave a few millisecond off of the game’s load time.

I know that the code works because I have a suite of unit tests. Godot has a third-party unit testing framework, GUT. GUT has a ton of whizzy features, but I mostly just wrote three dozen manual tests for the parts of the game that were easiest to test and hardest to get right: letter selection and failure explanation. I also wrote one exhaustive test for letter selection, which turned up an interesting case that I’ll describe later. But first, I have to explain why letter selection is so tricky.

In the first draft of the game, what’s now called “hard letter selection” was the only setting. This drove testers crazy, because of the problem that I initially called “bash/hue”, but which I now call “hash/hue”, since “bas” is apparently not a common word (what do you mean you’re unfamiliar with ancient Egyptian concepts of the soul? Didn’t you go through an Egyptomania phase as a kid?).

Here, you might be tempted to go for “hash”, since longer words are worth more points. But if you do, you’ll be doomed: none of UZ, UE, QZ, and QE can start any words. So you have to end “has” and start “hue”. This is fair: you can see it coming. But it’s super hard.

Instead, in normal mode, when picking a new letter to add, I consider all four possibilities: - A: prefix + two next letters, then end-of-word - B: prefix + two next letters, continuing - C: prefix + one next letter, then end-of-word, then starting a new word - D: end immediately, then start a new word.

For each of these possibilities, I have to consider each pair of next letters. So, A is really: prefix + left bottom + left middle, prefix + left bottom + right middle , prefix + right bottom + left middle, prefix + right bottom + right middle. Whichever of these choices you make, you need to be able to continue. Case A is easy: any letter can start a word (although there are only three X words in the short list: xenon, xylophone, and xylophones). The other cases are trickier. Here’s one especially tricky one that my exhaustive testing turned up:

What letters should we give here? The user might be thinking of “bail”, or “bails”. But what if they’re thinking of “bailiff”? There’s a problem: if they go for “bail”, the only continuation is “ifs”, so we have to give them a “s”. If they go for “bails”, the only next word must start with either F or X, so the next letter must be one of AEIJLORU (J? oh, fjord, sure). That doesn’t leave room for the terminal F of “bailiff”. So we can’t always support the all of user’s possible choices. But we can support “bail” and “bails”, so we’re still OK.

There’s a related problem with explaining what happened after the user fails: given that we sometimes use random letters, and given that those random letters sometimes make unintended words, how do we tell the user what they should have done? The answer is, frankly, the yuckiest code in Surfwords. It’s totally unprincipled. But it does seem to work, and I’m glad to have the unit tests to prove it.

There are a fair number of things in Godot that don’t work well. Some of them are fixed in the next version, 4.0. I decided not to upgrade yet, because 4.0 is not released, and I think it would be a mistake to depend on pre-release software. Among the issues I hit:

• On a M1 Mac, building for the simulator doesn’t work.
• Rounded corners on mobile devices are not well supported
• General polyline badness
• Slow text rendering (if you notice some choppiness during the splash screen, that’s what’s going on in the background). I wasted like a week trying various ways to get around this, including doing my own text rendering, but in the end, I gave up and accepted that I would have to have jank somewhere and put it in the splash screen.
• Regular Buttons don’t support different icons for hover. TextureButtons do, but they aren’t styled like buttons.
• No built-in set data type
• The Google Play Games Services plugin has three different versions (corresponding to different Godot versions, none of which is the current version), and they’re all based on v1 of the API, which requires full internet permissions. To be fair, Google’s Play Games Services examples are, as of this writing, also based on v1, and Google’s messaging on this could use some help. In the end, I rewrote just the portion that I cared about to use v2.
• Out line font fading doesn’t work right. I decided to just live with this, but it is ugly.
• Full screen didn’t work on OS X due to some random setting (possibly window/stretch/aspect="keep") – I just differentially debugged until it started working.
• Dialogs get weirdly long

Speaking of Google Play Games Services: making that work was a total nightmare. Admittedly, some of the fault is mine: in one case, I typoed a method name. But that should have caused Godot to give me an error, and instead, it just silently did nothing. Another time, I wasted a bunch of time because I used the wrong kind of OAuth token. The docs were clear, but the token type was counterintuitive (of course you have to use a “web” token rather than a “Android” token for your Android app). And the docs were very clear:

Note that the Intent returned from the Task must be invoked with Activity.startActivityForResult(Intent, int), so that the identity of the calling package can be established.

Yep, that’s right, it inspects your call stack to figure out your permissions, rather than doing something sensible, like taking permissions as an argument. And it can only inspect that call stack if you use the method that does a callback (even though the callback is not used for anything). That’s quality engineering.

But actually, the design of Play Games Services is evil: it automatically installs a provider, playgamesinitprovider, which asks my users to log in before they even start the game. This is an atrocious user experience: my users don’t know if they care about leaderboards until they play the game. When I remove the provider (using horrible Gradle hackery), logging into Play Games doesn’t work unless the Play Games app is installed, and sometimes it doesn’t seem to prompt the user to install it (sometimes it does – I’m not sure what the difference is).

I think one possible lesson here is that I should have just written my own Play Games Services plugin from scratch to start. And another lesson is that maybe I should have just used dreamlo. But I didn’t want to deal with the identity management, so I didn’t.

Another thing that didn’t work: I wanted to do a cool flowing wave background. I was using Material Maker. I ran into a few minor issues with Material Maker itself – for instance, a slight annoyance which required me to manually hack my shader after export. But it was pretty easy to use, and the model is easy to understand.

The background was going to be really pretty! And working on it was lot of fun, if somewhat time-consuming. Honestly, I was never 100% happy with what I had made. But eventually, I hit the “good enough” point. And that’s where things went wrong. When I exported to Android, I was getting like 30 frames per second on my new-ish phone. So I dug into the generated shader code, and found several micro-optimizations with how gradients were handled. After several hours of messing around, I managed to increase the performance… to 32 frames per second! I scrapped the feature. If I were doing a non-phone game, I would try Material Maker again. But honestly, I think maybe next time I should just find an shader artist to make me a shader.

Speaking of my terrible choices: I decided to make the UI adjust to the screen size. This led to a bunch of last-second changes as a playtester requested screen rotation support for tablets. My UI code was generally terrible. Some of this is due to one of the aforementioned Godot bugs. Some of it is just that I didn’t have a good sense of what sorts of UI interactions I would need, and how they would interact with Godot’s scene system. So I have a lot of special cases where I ought to have a general system. I spent a few hours debugging a case where I set rect_size before rect_min_size (which doesn’t work: rect_size is clamped to rect_min_size). And some of it is because making the game portion of the UI adjust is really tricky: what size do users actually want?

But Godot generally doesn’t have great support for fine-grained manipulation of UI. For instance, I wanted a little breathing room around the dialog describing “hard endings mode”. Normally, one would do this by adjusting the margins, or padding, or something. But the margin settings didn’t work. The only setting that worked was the expand_margin_* settings – which move the border outside of the requested area of the dialog (requiring the dialog to be manually shrunk to accommodate it).

Playtesters had several useful suggestions. Next time, I’ll definitely start with a color palette in mind, rather than building one as I go. I’ll also think about the tutorial from the beginning; because I added Surfwords’s late in development, it’s not as interactive as I would have liked. I am very glad that I got Surfwords in front of an early tester back before I had done any visual design, since that helped uncover the has/hue problem in time for me to spend a bunch of time fixing it without delaying the release. Special thanks to playtesters Dan Luu, John, Sky, Josh, Praveen, and Rachel for expecially useful feedback, but thanks to all playtesters.

Surfwords is now available for Windows, Mac, and Linux, as well as iOS and Android

For me, Bridger’s narrative-warping powers destroyed Perhaps The Stars as a novel. I don’t think it was the only flaw – but it was the flaw from which the novel could not recover.

The problem with narrative-warping powers is both that it destroys the characters’ agency (even, in Perhaps The Stars, over their own psyches). Narrative-warping powers aren’t the only thing that can do this: sufficient alien mind-control works too. I basically had to pretend that the entire bit about Shards in Worm hadn’t happened so that I could stand to finish it.

It didn’t matter that Mycroft made decisions which lead to his death (twice), because the plot demanded that he return.

To be fair, Mycroft’s second return, in the chapters leading up to and including “No One”, was rather well-written. The way that the prose shifted to include more and more of his distinctive style, leading up to the moment when the fateful words “No one” were uttered, was quite delightful. But I don’t think that impressive prose style is enough to carry the novel; we had already had three volumes of that.

It didn’t matter what arguments Faust made, because he was destined to be Priam. If Faust knew who Mycroft was, how did he not know that he himself was Priam, and Gordian Troy? And if he knew, how did he not expect a Trojan Horse? (For that matter, how did the Trojans not expect a Trojan horse? There’s an earlier Egyptian story, The Taking of Joppa, in which the Egyptians use a similar tactic, and which pre-dates the fall of Troy by hundreds of years. Maybe Priam hadn’t read The Taking of Joppa, which is not an excuse that Faust has available).

So why did Worth The Candle work? Degenerate Cycles (perhaps the bleakest cosmological concept since quantum immortality) showed the GM’s thumb on the scales. It worked because the stakes in Worth The Candle were not whether Juniper would get the good ending. The stakes were whether Wales could come to terms with the loss of his friend. That’s why Fenn’s resurrection wasn’t a cheat. Fenn was resurrected. Arthur wasn’t.

These are stakes that are particularly poignant to me this past week, as I think about the end of Terra Ignota. First, I remember coming upon my copy of Too Like The Lightning when I was cleaning out my brother’s apartment after his death. I didn’t realize it was mine, and we gave it away, and then I had to buy it again to reread in preparation for the release of Perhaps The Stars. And then Tuesday, I was in court fighting my bullshit unreasonable noise ticket (I won), and I remembered the last time I had been in court over some petty bullshit (my landlord dropped my air conditioner out the window and then blamed me for it), and my brother came up to watch, and I know he would have wanted to come up to watch this one too.

I think people will vary in how much the narrative-warping bothers them. If the story had otherwise worked, I think I would might have been willing to treat the entire Homer thing as a symptom of Mycroft’s insanity. But I also was struck by a few more problems that made the whole thing fall apart for me.

Frist, Gordian. Prior to Perhaps The Stars, I sort of assumed that they were a self-improvement cult, like EST or NLP. But actually they’re more like the Bene Gesserit. Or are they? For instance, if they’re so smart, how come they ain’t rich? This is a real question: they’re clearly resource-limited, which is one reason they envy Utopia.

I just started listening to Your Undivided Attention, and the first episode discusses how casinos manipulate players into spending more money. They give an example that Felix Faust would love (my brother would have loved it too):

A good example of this is, I think we talked about this once, that in psycholinguistics if you have two theoretical pain medications, one’s called Pavel, and one’s called Bavel. Which one works faster?

I’m going to leave their answer off, because I replicated this at a very small scale and 4/5 people agreed so and I’m pretty sure that you will too (it helps if you say them out loud). Bouba/Kiki is a more famous example of a similar phenomenon, but nobody is trying to sell you a bouba. The podcast isn’t really about casinos qua casinos. It’s about the tech industry. As Jeff Hammerbacher (of Facebook) noted: “The best minds of my generation are thinking about how to make people click ads.” If Gordian has such a deep level of insight into humanity, then why aren’t they using it to either (a) make money, or (b) become more popular?

(I want to exclude the possibility that the answer is actually the same as Louis Jordan’s original answer: I don’t think 50 hours a week of hard work beats 20 hours a week of Jedi mind tricks).

Also, if Gordian techniques really work, the fact that they are in German wouldn’t stop people from learning them. Like, I understand that in 2012 (when Terra Ignora was initially conceived), machine translation sort of sucked. And I’m sure that it’s very hard to translate deep psychological insight. But if the techniques work well enough to win a war against Utopia, then the incentives are certainly strong enough to get a translation. This article aside, generally useful technologies spread unless something stops them. And German isn’t enough.

One thing that could stop technologies from spreading is patents (especially if they were longer-lasting than our current patents). And this gets to a problem with Terra Ignota as a whole: while it examines religion, history, gender, and government, it seems to treat property as a given. I think it would be uncharitable to say that this is unsurprising from a professor at the University of Chicago, but I do admit that the thought crossed my mind. Two of Kohaku Mardi’s three triggers are about property. But the nature of property is entirely unexamined. What sorts of things can be property? What sort of right is a property right? This is especially hairy in a poly-legal system: I say you’ve trespassed; you say you’re practicing your freedom to roam. I say you’re infringing my eternal patent; you say that patents on mathematics are illegitimate and anyway your patent expired after seventeen years. All this is to say that a land value tax would totally fix the Mitsubishi problem. And some wishy-washy corporate social responsibility thing, which is what they ended up with, would totally not.

One possible explanation for this omission is that the philosophy of property didn’t really get interesting until the 19th century, while Terra Ignota’s philosophical core is in the 17th and 18th centuries. I don’t know if this is actually true: maybe there’s a bunch of interesting stuff in the 18th century, but the 19th has JS Mill, Karl Marx, and Henry George (and arguably William Foster Lloyd). Schelling, in the 20th century, provides another novel argument. But Thomas Carlyle was 19th century, so I’m not sure that the date theory works. Palmer has collaborated with Cory Doctorow, who has certainly written plenty about the nature of property, so I have to admit that I don’t understand this omission.

This also feeds into the weakness of the ending. OK, so Utopia has surrendered – but why doesn’t everyone just quit Utopia and join a new hive, Utopia B, which doesn’t recognize Utopia’s surrender? After all, they’ve already lost their space elevator and given away most of their patents. What’s left that Utopia has that Utopia B doesn’t? Mars itself? But if you believe that Original Utopia owns Mars, then you’re back to geographic nations.

Let me also say that an ending in which J.E.D.D. Mason was successful in reforming the hives was completely unexpected, and rather unsatisfying. What I expected was something more like the ending of The Wave: J.E.D.D. Mason tells everyone that they are fools to follow him no matter his personal charisma, that the idea of salvation is a myth, and that any change that he could impose by fiat would be better imposed through democratic means.

I wonder if this is just a failure to suspend disbelief. Like, I recognize that there’s some special thing that J.E.D.D. Mason has, and that somehow everyone who meets him recognizes. In a real sense, he’s not just one of us. So maybe if I had met him, I, too, would worship. But maybe not. Even if I accept that J.E.D.D. Mason is a god (and I think it’s far more likely that he’s simply the normal, extra-terrestrial-but-not-extra-planar sort of alien and that the entire scene with his death and resurrection was theater; the fact that it is possible to reverse-engineer Bridger’s technology is some evidence for this), that doesn’t mean I have to worship him. I think a lot of people would object to being ruled by an alien god, and I think they would be right to.

I often feel, in philosophical fiction, that my position is not well-represented. This was one problem that I had with Ken Liu’s Reborn. Perhaps The Stars didn’t really have that problem with respect to my political view: my position in the war was that of the the Blacklaw Hiveless: I would have just wanted to be left alone. (I’m actually somewhat sympathetic to OS, but only in the context of a philosophical novel; in actual reality, the unaccountable killers who claim they’re protecting us are stunningly incompetent). And I also understand that my position is unpopular. War is popular. Last Thursday was Veterans Day, and even otherwise sensible people posted bullshit like “thanks for your service” instead of what they ought to have posted, which is “fuck you murderers, I’m not celebrating you.” Which is, somewhat surprisingly, ultimately with J.E.D.D. Mason said.

But my religious views were rather unrepresented: everyone seemed to believe that (a) J.E.D.D. Mason was in fact a god, and (b) that this meant that he was worthy in some way of respect. It seems possible that this was supposed to be unbelievable. That is, whether by questioning Jehovah Mason, we are supposed to question Original Flavor Jehovah, and the logic of theocracy in general. Like, “this is what believing in God looks like from the outside”. The thought experiment carefully separates out a lot of the baggage of religion: there’s no tradition, J.E.D.D. Mason isn’t our creator, and you can’t object to any particular thing that he represents because (until the end), he refuses to tell you what his plans are. I don’t understand why nobody – no Utopian, no Humanist, no Gordian said, “well, imagine that you are some kind of God. So what?”

And “So what?” is, unfortunately, my reaction to the entire denouement of the book.

A few more things:

1. Whenever I saw Sniper being thwarted, I couldn’t help but imagine Dora the Explorer saying, “Sniper, no sniping!” (She even speaks Spanish, like a good Humanist!). I would have liked to see more of Sniper.

2. I was extremely surprised to see something named after Aung San Suu Kyi. At least I assume that’s what was going on? That was definitely confusing.

3. Huxley should have replied to Faust: “Yes, we will bring Distance, but so will you. How much faster will emulated brains run? Reykjavik to Antarctica is already 60ms - but if ems run faster, that would feel like minutes, or hours, or days. And if they run slower, then we waste lifetimes as the sun darkens.”

4. There were some really good bits: the Odyssey set-piece was fun, Dominic’s return was beautiful, and I enjoyed that Thisbe, being a cinematic sort, had to do a villain speech and that’s what did her in. Oh, and J.E.D.D. Mason’s speech about killings during war is the sort of common sense that is under-appreciated.

Before I left Brickhouse, I started collaborating with John Seroff. I build pieces, and he decorates the surface. This is generally his practice – he has worked with several other artists at Brickhouse as well. So now he comes by my place once a week and we hang out and play with clay. Working with John is tremendously fun. We each admire the other’s work, and neither of us is afraid to take technical or aesthetic risks on a piece. And it’s fun to hang out in the studio and discuss culture and world events. I have to mention this up front because my work with John is a big part of the story of this year.

I have not posted recently because I am a perfectionist, and none of my work is perfect. I keep thinking that the next kiln load will have the perfect piece and then I can finally blog. But my art is improving, and I want to track that. I also keep thinking that I would finish the project of building handles for all of my kitchen cabinets and then post the complete set. But instead, I have mostly been making vases. I am still short three handles, of which two are merely awaiting glaze firing and mounting.

So I am going to start by showing all of the handles that I have completed, and then come back and silently update the post once I finish the last few. Can you spot the one that’s driftwood instead of clay?

Making these animal and human forms was fun, but I sort of burned out a bit on it. So those handles are mostly from late 2018. And a lot of the animals are nonspecific. Oh, it’s a critter, sure. But I think I could get a stronger effect by increasing the mimesis. The hand and foot handles are my favorites, and I think a lot of their power is because they are sculpted from life. The elephant seems to be everyone else’s favorite. I have started to get back to figure sculpting in 2020, but don’t have anything out of the kiln yet.

The bulk of my work lately has been slab-built vases. I can trace two threads of development: first, stacking slabs, and second, polyhedral pieces with tar paper. To start, I want to show my two stacked slab pieces from late 2018. First, I stacked slabs with some overlap.

Then I did the same, but with one vertical strip.

Then I added a head and some arms, to make a finial for one of my fenceposts. Now I just have to make like twelve more finials.

My next idea was to stack without overlap. This is considerably more difficult, because the seams have to be neater. First, I made these two vases that love each other very much. John Seroff did the carving.

Then I made a taller vase with the same general concept. It barely fit in my kiln.

I also made a lidded jar. I actually made two, but the first one was too squat and the glaze didn’t come out the way I wanted it, so I rebuilt it. This one is about 16 inches tall. And of course now that I’m looking at the photo, I see a crack, probably where I inserted the dart to bulge that section. I may have to make a third one. With a less shiny black glaze.

The end, for now, of that line of development is this nine-necked vase. It was in the last kiln of 2019, or, perhaps, the first kiln of 2020, mid-firing as the clock struck midnight. It will be shown at Back to the Table, an exhibit of tableware at the Plaxall Gallery in Long Island City.

I had a really hard time visualizing how the base of this was going to work, and in the end, I had to add that extra foot. I think part of the problem is that building up at an angle tends to cause sagging, so I started out straighter than I had planned. I’m pretty happy with the glaze, especially the mossy green. But I think that this is about the last piece in this line that I will make for a while.

The second thread started with a funerary urn that I made. I wanted something monolithic and stark, and it needed to be fairly large (about one cubic inch per pre-cremation pound of body-weight). So I cut some tar paper forms, and used them to hold up slabs. The result was not amazing, but it definitely looks sufficiently bleak.

John had been watching me grow as a potter, and asked me if I wanted to collaborate. I built a teapot using tar paper templates, and one of my first animal heads. I was going for a fox, but I was not yet strong enough to get there. So I declared that the result was a coyote. The body has pentagonal symmetry. This is a good choice for me, because my work is always a little sloppy. A sloppy square is obviously sloppy. A sloppy hexagon has non-parallel opposing sides. But a sloppy pentagon is basically fine. John’s photo:

Then I got to thinking about what else I could make with this technique. I realized that pottery rarely has what origami artists call “valley folds.” You can get mountain folds by paddling a thrown piece, or by joining slabs. But valley folds require a bit more thought, because they are hard to press together to get a good joint. So here is my first piece with valley folds. It’s foreshortened in this photo and since I gave it away I can’t reshoot – it’s actually quite a bit slimmer than the photo implies:

John next suggested that we do a series, and the first complete set that came to mind was the platonic solids. So I built some platonic solid teapots, and John decorated them. His process is slow and he likes to work with a wide variety of people, so I think I ended up making the pieces a bit faster than they could get decorated. So only two and a half of the five are done (John’s photos; the last one needs to be glazed):

The logical conclusion of this was to go into Blender and design a stupidly complex 36-piece vase, and then have John decorate it. So that is what I did. John’s photo:

It soon became clear that the tar paper is really only necessary for the dead-flat surfaces. By instead bellying out the slab as one would for a pinch pot, I was able to assemble large vertical surfaces. One of the first of these was a nudibranch-inspired vase. This one doesn’t really have true valley folds, as the “wings” are accessible from both sides, but it does use vertically-joined slabs.

Finally, we reach the point where the two threads converge: a piece with multiple necks, bulged vertical slab sides, and valley folds: Cathedral Vase I. Also, I now have enough work that I need to think of names. I am very happy with the glaze on this one even though the teal-and-orange combination is a bit of a cliche.

I say Cathedral Vase I, as John is working on the surface of II now. Hopefully, I will manage to file another update before 2021. No promises.

My answer was that I don’t know how to solve the unwanted communication (spam, brigading, etc) problem.

I don’t think anyone else does, and I think most people are unaware of how hard it is. That’s because it’s a problem of mechanism design in addition to being a problem of engineering. And most people are just not devious enough to design mechanisms that are resistent to adversarial usage. A while ago, I brought the issue up on the mastodon issue tracker, and did not get much traction.

Someone recently proposed an option to diable replies on Mastodon posts. This is, abstractly, not a terrible idea: I don’t have comments on my blog, and I could imagine making certain social media posts where I don’t want comments. There was even the really neat follow-up idea of “no replies except for people who are @mentioned”. But what does “no replies” mean? To understand this, you need to know a little bit about how Mastodon (or, more precisely, the underlying ActivityPub standard) works:

There are a number of servers (e.g. mastodon.social, oulipo.social, etc), and each user belongs to one. If I post an “activity” (roughly, a tweet), it goes into my public outbox, and anyone who has read access to my outbox can read it. A reply is just an activity with the inReplyTo field set. If you post a reply, it (a) goes into your public outbox, and (b) goes to my inbox on my server. My server might, when receiving a reply, forward it on to the folks who saw the original message (that is, my followers, who would otherwise not notice it in your public outbox unless they were also following you).

So things that disabling replies could mean include:

1. I configure my server to not notify me about replies (i.e. they do not appear in my inbox)
2. I configure my server to not forward replies.
3. I add a field to my message indicating that I do not wish for people to reply to it, and other servers will enforce this in their UI.

All three things of these things are reasonable to want, but the third only works for “well-behaved” participants. I put “well-behaved” in quotes here, because of course if someone says something mean or false about me and then sets it to no-reply, I might well wish to override the “no-reply” setting so that at least my followers can see my rebuttal. So it was quite surprising to me to see, here, someone suggesting requiring ("must”, in RFC-speak) the third, unenforceable option.

I also saw a suggestion to implement a proof of work system, Hashcash, to reduce the frequency of direct harassment. This seems extremely unlikely to be useful for this, because Hashcash is intended to stop large numbers of messages, but even one message per sender is sufficient to harrass people (the most common risk is one message per person from a thousand people). Also, Bitcoin has shown us that there are something like seven orders of magnitude between the hash rate of an ASIC and that of a typical CPU. This makes setting a correct Hashcash cost impossible. A memory-hard hash function might reduce this gap, but probably not by enough. Also, most “clients” are actually someone else’s server, meaning that the effect would not be felt by the message sender directly.

I wish I knew of better solutions, but at least I am glad that I don’t falsely believe that good there are solutions out there that nobody has the will to implement. That would be depressing.

We’ll start with a recent one that I’m proud of:

Yep, it’s a vase with rats coming out of it. The black glaze is Marilee’s Lava with 7% Mason 6666 black stain, which I put together myself. I have now manufactured a few glazes, including this; a lichen glaze which slid so dramatically that I haven’t dared to use it on a real piece; and a supposedly mint green which actually came out so much more matte than the reference photo that I suspect I must have fucked up somehow. I’ve also played with oxides some and gotten results varying from unnoticeable to garish to awesome. I’m not sure how I feel about a process with such high-variance results but I’ll probably keep exploring anyway.

Here’s the first piece I made that I still like:

Probably I’ll stop liking it once I improve further. I enjoy the texture, but I wish it were more precise. I still don’t really know how to get precise lines – somehow, even with a ruler, it always comes out messy. So I’ve been trying to learn to make pieces that embrace the mess.

I also made vases as holiday presents for everyone on my team. The project we were working on is called The Aleph (after the Borges story), so all of the vases have Alephs on them. This is my favorite:

One co-worker in particular got excited about the pottery, so I made her a casserole:

My cats insist on photobombing my pottery photos. This is the rare Mutex photobomb – it’s usually Semaphore. The texture on the casserole was made with an old daisy wheel. The piece is really quite large – it cooks^Hholds almost 16 lbs of cat. I used S762 kitchenware clay, a buff stoneware with fine grog. It reportedly goes happily into a cold oven without cracking, so I guess the body lives up to its name. Unfortunately, most of the studio’s glazes, and some commercial glazes come out muddy or crazed on this body, so I’m pretty limited in where I’m willing to use it.

One piece I made out of it was my second orcish teapot. But before I get to the second one, I have to show you the first:

The body here has exactly the hue I wanted, but about two shades too light. That’s significantly better than some other possible outcomes: the glaze combination I used is a bright green celadon on top of a chameleonic red-brown. Too little green, and you get mud; too much and you get blobs of snot.

Other folks insist on calling this a warthog teapot, but what does a warthog need with a teapot? Maybe the orcs used warthog tusks to make it. Another potter at my studio had been doing a bunch of stuff with spikes, and I was a bit inspired. Peter’s spikes are broader than mine, and straight rather than bent. He throws them on the wheel, which I did for these and for my doorknob, but which I’ve since given up: handbuilding them is faster for me. And it’s easier to get close-to-identical copies, at least at my skill level.

I like the idea of a second draft of a piece, and wish I had the patience to do it more often. The casserole above is actually a second draft: the first one was too thin and ended up cracking. The second one has straighter walls and better texture, and I think the handles are nicer too.

Here’s that second orcish teapot:

.

The second orcish teapot did not come out the way I had planned, but I am not disappointed, because it’s pretty metal. Literally: the black glaze is primarily black copper oxide, and the horns have some red iron oxide stirred into the clear. Copper oxide usually produces green, and I had hoped to reproduce something like the original glaze by adding a bit of copper oxide to a not-green-enough glaze. You can see the normal copper green where the oxide has bled into the white interior glaze. That’s not the color I wanted on the outside either, but it’s attractive if not particularly orcish.

Britt suggests adding bentonite to oxides to get a more even application. Brickhouse’s studio oxide washes don’t have this, so they settle out very rapidly, making it hard to get an even application. I made up a copper oxide wash with some methylcellulose (AKA “CMC gum"), which I have used in the kitchen in the past. It burns off in the kiln, but suspends the oxide enough to get an evener application. However, I think I might have more oxide in this wash than I really want. Copper oxide is quite corrosive: one little drop of the oxide glaze slid off my piece and ruined a kiln shelf.

I know that the standard approach here is to glaze a bunch of test tiles, and not glaze the final piece until the test tiles are done, but the turnaround time on test tiles can be up to three weeks, so I often test on finished pieces. I do take glaze notes inside a crappy webapp I threw together, which at least helps me avoid making the same mistake twice.

All of these horns got me excited about animal forms, so I went back to handbuilding. The rat vase was the first thing I made with animal faces. Then I made a skunk mug:

I have to admit that this one, too, was partially inspired by [Peter]((https://www.instagram.com/potteraguero/)’s work – he had been doing “eat, fart, love” mugs ("I don’t pray”, he explains). So when I made a skunk mug, the “eat, spray, love” slogan came to me in a flash. The face has kind of a funny shape, but I think it’s not too far from what a real skunk’s face looks like. It’s just that our mental image of a skunk has been warped by Pepé Le Pew.

Another thing that inspired me to make animal forms was this Pikamug:

Once I had made this for one cousin, I knew I would have to make something for his sister, and their mom suggested Ponyta:

One rule I have is that everything I make has to be at least somewhat functional. This constraint is somewhat arbitrary – just about anything hollow could be a vase. But it does mean that I am forced to pay attention to how a piece could be used, and think about smoothness and weight. I should probably institute a “no vases” rule at some point, since I basically never use a vase for anything. Maybe I’ll ban teapots too, except that I have yet to make a teapot that’s technically even base-level competent yet. For instance, the first orcish teapot doesn’t pour very well because the glaze covered up the holes. The second’s spout is too low. So I may have to make a few more of those.

Here’s a completely boring bowl where I like the glaze; it reminds me of a night sky:

The waiting is a real struggle: the most recent work I can show is some jars that I threw in late December, and then sculpted the lids of in January, and then glazed a few weeks ago, and just got out of the kiln. In fact, the third pot’s lid didn’t look great after glaze firing, so I’ve reglazed it and am refiring it. Here are the remaining two jars: a French bulldog, and a demon:

This delay means I can’t show you my alligator teapot or my Baba Yaga’s hut teapot, or my seed pod vase, or my second doorknob, which is completely different than the first one. So I guess I’ll have to post again.

Technical details:

I’m working at Brickhouse Ceramic Arts Center in Long Island City. My primary clay body is the studio’s brown stoneware, but I’ve also used Laguna B-Mix and S762 from Ceramics Supply. The studio fires at Cone 6 in oxidation. I use the studio’s glazes, as well as some commercial glazes from Amaco, Mayco, Coyote, and Potter’s Choice. If you like any of the glazes above and want more details, let me know and I’ll happily share.

First, I’ll briefly explain the rules of Lost Cities, and then the changes in Keltis. Then I’ll explain why these changes produce lower variance. Finally, I’ll explain why I’ve been thinking about this.

The Lost Cities deck consists of twelve cards in each of five suits. Nine cards per suit are numbered 2-10; the rest are identical “investment” cards, which multiply a player’s score in that suit. Each player has a hand of eight cards. On their turn, they either play or discard. Plays and discards are both by suit. After playing, they draw either from the deck or any discard pile. As soon as the last card is taken from the deck, the game ends. There are two things that make the game interesting: 1. You can only play cards in each suit in-order: first any investment cards, then the numbers in ascending order (with gaps permitted). 2. If you don’t play any cards in a suit, you get zero points for that suit. Otherwise, your score in a suit is negative twenty points plus the sum of the values of the cards played in that suit. This generally means that you only open a suit if you’re pretty sure you’re going to make 20 points in it.

Keltis has a few differences from Lost Cities, but from our perspective, the most important ones are: 1. The value of each card is approximately the same. Cards still have numbers, but the point value for a suit depends only on the number of cards in that suit. 2. You can play a suit in either ascending or descending order.

Here’s how this leads to lower variance: In Lost Cities, opening with a hand of, say, the 9 and 10 of each of four suits is somewhat unlucky. You don’t want to discard anything, because your opponent will snap it up from the discard pile. But you also don’t particularly want to open a suit, because you’re guaranteed to lose a point on it. In general, getting cards in the wrong order can turn what would be a good suit bad. There’s nothing more frustrating than ending the game with the 7-8-9 of a suit and missing six points just because of bad timing. In Keltis, that would be an acceptable opening hand, since the 10s are all immediately playable.

And in Lost Cities, if you have 3-4-6 in a suit (13 points already), you’ll surely open that suit since you expect to get approximately two of the 7-8-9-10 cards. But in a quarter of games you’ll get just one, and in a quarter of games you’ll get three. And it’s possible to get zero or all four. In Keltis, this is approximately true as well (the card distribution is a bit different, so not exactly). But in Keltis, this will result in a swing of a few points – not 30 points (or more with investment cards).

It’s always nice to have data to back up a theory, so I found this page. It claims that, in fact, Keltis (listed as “Keltis Card") is lower-variance. Well, more precisely, it makes a more-complicated claim about Elo ratings, but I think the effect is the same.

Subjectively, I think Lost Cities might be a slightly more fun game, and this says bad things about me. There’s a real excitement as things come down to the wire: will I suck out and get that blue ten (which is now worth 40 because of investments), or won’t I? That part of the game is pure gambling, and while it’s fun, it’s not something I feel proud of enjoying. But at least I’m not alone: Keltis gets 6.7 on BGG, while Lost Cities gets 7.1.

I have been thinking about this because I just had opposite feedback about dynamic range in two of my prototypes. In Sekhmet, the range was considered too low: a given tile could score between 1/2 and 2 points. In Banshee, the tile values are between 1 and 10, and the player who happened to draw the 10-point tiles was very likely to be able to use them and win. Similar problems don’t necessarily demand parallel solutions, so while I’m going to replace all the 1s with 2s in the next test of Banshee, I’ll probably fix Banshee by completely replacing the way that tiles score – and in the process, maybe reduce the range.

First, make a new image with the same size as your original image. Fill it in totally randomly.

Now, resize your random image to have twice as many pixels in each dimension. Each 2x2 pixel square of the resized image gets one of these “macropixels":

One has the top-left and bottom-right pixels black; the other has the top-right and bottom-left pixels black. Let’s say that we’ll replace black pixels with the left image and white pixels with the right image. Your new image will have exactly half of its squares black, and the other half white. This is your key (although it doesn’t actually matter which side is the “key” and which is the “data"). Here’s an example:

Now, take your original image, and encode it like this: where there’s a black pixel, take the macropixel that’s different from your key, and where there’s a white pixel, take the one that’s the same as your key.

Notice that this new ("ciphertext") image has no information from the original image. If your original pixel was black, there’s a 50-50 chance that it will be the same as the black pixel from the key, and a 50-50 chance that it will be different. It’s the visual version of an xor-based one-time-pad.

Now comes the really cool part: to decrypt the image, you can print the key on a transparency, and overlay it on the ciphertext:

You’ll see fully-black macropixels where the original image was black, and half-tone where it was white. No special hardware needed – just apply eyeballs.

As part of the Museum of Math’s opening puzzle hunt in 2012, I used this to create a fun reveal. They had transparent disks designed to be overlayed to display moiré patterns. Instead, I encrypted a puzzle answer, and printed the key on one disk and the ciphertext on the other. When the disks were rotated to the right angle, the answer image would pop out. Of course, this isn’t very secure – if you look at the images, you’ll see the grid axes, and then there are only four possible rotations. But if you don’t have one of the disks, it’s totally secure. And it’s a cool effect. When I visited the museum recently, the museum staff mentioned that the Fitzwilliam Museum had been inspired by my little toy, and have a version of it in their upcoming codebreaking exhibit (opening October 24th). So if you happen to be in Cambridge (the one in the UK) between next week and next April, please drop by and take it for a spin.

Step one is to just scan the whole board, without any particular feature in mind. This strategy will almost never find sets for new players, because they haven’t got their pattern recognizers wired up right. But it’s good to do anyway, because you’ll need it for the next step.

Step two is to look only at the most-common attribute. If there are six red cards, pop out the reds and look just at those. Since you’ve just scanned the board, you’ll be able to find the attribute quickly. Among the cards with that attribute, you’ll be able to see a set if there is one. If not, you can quickly check the greens and purples. If you still haven’t found a set, you’ll know you need differing colors. Here, it’s often easiest to start with the smallest two categories: if there are three green and three purple cards, you only have nine pairs of cards to look at. And since you’ve scanned the board, you can often simply remember whether a pair’s third card is available.

When new cards are dealt (especially when there are no sets among the twelve cards on the board), it’s a good idea to look at those cards first. And if you’ve been tracking the distribution of attributes, you’ll know what’s common. On a board with lots of ovals, a new oval is exciting because it’s very likely to complete a set.

At the beginning of the game, the average number of sets on the board is almost three. Pretty often, even if someone else got one, there will still be one remaining.

As an aside, very few board and card games discuss strategy in their rule books, which I think is a shame. Sure, there’s some fun to learning the early tricks on your own. But with most games, the real depth happens after you’ve played a few rounds. Adding a tiny strategy guide to game manuals would help new players to enjoy games more.

Dominion is a very robust design. They recently reprinted the base game, and replaced six of the original twenty-five cards because they were too underpowered or too situational. What other game could not only survive having nearly a quarter of its components being nearly useless, but manage to sell millions of copies despite this? Maybe we can look at some of the reasons behind this robustness, and learn something that we can apply to our own games.

1. Underpowered is better then overpowered. If Rebuild had been in the base game, folks would have complained a lot more. It’s a one-card engine that’s basically a must-buy.

2. High variance adds to robustness. It’s harder to detect a bias in a noiser signal.

3. Nobody is forced to take a bad card (except through something like Swindler, where the availability of bad cards is arguably a perk). Having a choice available that nobody ever takes are is terrible. The effect is that the designer has wasted some time, and there’s a bit of additional cognitive load. Otherwise, it’s fine. If there’s a whole subgame that’s useless, that’s bad because players shouldn’t have to learn a useless subgame. But if the choice is just one card vs another, it turns out, it’s workable to have a few less-good choices.

There are other reasons that Dominion is a great game, but I don’t know if there are other reasons why it’s a robust game.

It’s OK for a game to be less robust. With a less robust design, the flaws in those six Dominion cards might have been discovered during development, and they would not have been printed. But I think that overall, robustness is a virtue. Once a game gets out into the world, players will discover, over the course of many years, how the game ought to be played. A robust game will better survive that experimentation process.

I was inspired by nostalgebraist (re)posting this image, entitled “A cube and its greebled version":

Of course, mine is more regular (but, being handmade, is also much more irregular). It’s slab-built: first I carved an annular sector and a circle on a slab. Then I cut and rolled the sector (making a truncated cone), and molded the circle over a dome to make the bottom. I attached the two pieces, and cut a hole for the spout. The spout is a coil with a hole poked through it, hand-molded, with both carving and additions to get the greebling. The handle was a thinner slab, also with both carving and addition. As the piece was drying, the handle cracked, so I had to repair it with paper clay (which, as far as I can tell, is some kind of magic). Then I had to make a lid, and I realized that I had not thought at all about what the handle should be like. So I just whipped up something that would work with the texture.

The glaze is three coats of Coyote’s Really Red (two on the bottom, which turned out to be plenty). I thought that a complicated form should have a simple glaze. Also, having spent like fifteen hours greebling the thing, I wasn’t about to spend another fifteen painting it. And I recently had some bad luck with the studio glazes; I tried to make a mug that was yellow, black, and red-brown, and got greenish-brown, brown, and green (respectively) instead. So I stuck with something I knew would work.

I’ve been messing around with ceramics for nine or so months now, and this is the piece that I’m proudest of.

Also, I had a code review recently where a co-worker asked me to change some hard-coded strings to be constants. The strings, in this case, were argument names for a JSON API. So the API took e.g.

{
    "function" : "launchMissiles",
    "args" : {
        "target" : "Moscow",
        "type" : "ICBM",
        "count" : 17
    }
}

The co-worker wanted all of the strings to be constants (except I think “Moscow” and “ICBM” came from user input and were thus variables). I thought it was reasonable to have “target”, “type”, and “count” be hard-coded. That’s because:

1. Imagine that they were constants – what would you name them? final String ARG_FIELD_TYPE = "type"? That seems to make the code harder to read. Also, it repeats the value of the constant in its name. If tomorrow the value were changed to “model”, should we also change the name of the constant? To do so would be insane: changing a constant’s value shouldn’t entail changing its name. But to leave it the same would be monstrous: future readers would have no way of matching the function call to the API docs without resolving the value of each constant.

2. Would it prevent misspellings? Not really. You could just as easily misspell a constant’s value as a hard-coded string’s value. If the string were repeated often, then maybe it could get occasionally typoed, but these weren’t repeated very often.

3. And even if they were repeated, there would be no logical connection between the instances. The launchMissiles function happens to have a target argument, but so does the strstr function. But in the next release, maybe they’ll correct strstr to have better names (needle and haystack are the only correct names for strstr’s args).

Anyway, the point is that constants are often valuable for things that we do expect to change, and often less valuable for things that we don’t expect to change. So the “constant” name is a little funny too.

Anyway, C claimed that this was disrespectful, since the benefit was intended for religious minorities, but I was taking advantage of it. I pointed out that being atheists are in fact quite a small religious minority. This is somewhat disingenuous as, normally I consider atheism to be a lack of religion. But when we discuss matters of religious discrimination, atheists are a group against which there is discrimination on the basis of religion.

I guess maybe there was one fewer ice cream available for folks who keep kosher, but (a) I don’t think they measure the exact number of folks who keep kosher and order precisely that many units, and (b) this was a zero-sum situation; one of us was going to go without and it didn’t really matter which, and (c) they could always just order more next time and (d) I work in the software industry and basically all of my co-workers can afford more dessert than they could possibly eat. (Since this ice cream thing is not the real thing that C and I were discussion, the details aren’t really important; the actual situation was non-rivalrous but I also didn’t have the lactose intolerance excuse. I just wanted the benefit).

In my conversation with C, I also mentioned a hypothetical, which I think I took from Eugene Volokh but now can’t find the source for. The idea is that some company ordinarily requires everyone to work on Saturday. They grant an exemption to Michael, because he’s an observant Jew. But Frank is a divorced father, and his custody arrangement only lets him see his kid on Saturdays. Why is it fair that Michael gets the exemption, but not Frank? From an atheistic perspective, Michael is making a non-existent being happy, while Frank would be making his actually-existing kid happy. Of course, that’s not how Michael sees it! But the point is the at people have many compelling reasons to want exemptions to generally-applicable rules, and while it’s quite reasonable to grant these exemptions liberally, it’s problematic to do so only when the exemptions are religious in nature.

I don’t think any of this was super-convincing to C.

Anyway, I was telling E about this conversation, and E pointed out that when we think about rules, there are at least three levels: the letter of the law, the spirit of the law, and broad moral principles. I tend to care about broad moral principles and about the letter of the law (which I was, in the case at hand, following; the hypothetical ice cream was labeled as “kosher”, but not labeled as “for observant Jews only"). But the spirit of the law often moves me less. C, on the other hand, cares a lot about the spirit of the law. It’s unsurprising that I care strongly about the letter of the law, as both my parents worked as lawyers for most of my life. Also, I’m a software engineer and software is a field that is about the letter of the law (though recent discussions about undefined behavior in C are often about how strongly to adhere to an ill-thought-out standard, so maybe this isn’t a universal professional deformation).

I also think it’s possible that there are different moral principles at play. Religious folks (I don’t know whether or not C is religious, or has this belief) often think of respect for religion as a terminal value. Some non-religious folks think this true. So if, for example, someone describes the Book of Mormon as kind of Bible fanfic, that comparison will rankle (even if they personally believe that in fact, Mormons are mistaken and that Joseph Smith composed the Book of Mormon himself). This generic reverence for religion is not a value I share. Of course, if it comes up in conversation that someone is a member of religious group X and your first response is to say “X is false and bad”, that’s just being a jerk. But in an abstract philosophical conversation, I don’t think there’s a huge problem with comparing religious texts to non-religious texts – even low-status non-religious texts like fanfic. (The low-status bit is actually pretty important; the title of The Greatest Story Ever Told compares the Gospels to literature, and it is not regarded as disrespectful).

Also, I think that even among people who do have this value, it tends to reinforce existing power structures. For example, I have read that no non-Christian group has ever won a free exercise clause (of the US Constitution; RFRA is different) Supreme Court case. So it seems to me that one’s idea of which religious practices fit into this sort of reverence is colored by one’s personal experiences of religion, and those that one is exposed to through mainstream culture. That is, it often ends up being a facet of status quo bias: an inability to look at things with fresh eyes.

I don’t really have a conclusion here. I just thought E’s comment was so interesting that I decided to dress it up in a bunch of bloviation.

There was just one problem: a throwaway line about Carolina. That’s the state formed, in this alternate history, by the merger of North and South Carolina. This would never happen. The US political system gives more power to smaller states. What state would give up a senator (and maybe a representative) to join another? None. Ever. And this gets to the heart of why there was a Civil War in the first place.

In 1860, the (then chiefly southern) Democratic party had won three of the past six presidential elections. The slave states had between them about 40% of the Electoral College votes. They had about 45% of the Senate. But they only had about 1/3 of the population (and under 1/4 excluding slaves, who certainly weren’t going to fight for the South). The combination of the three-fifths compromise and the Electoral College led the South to dramatically overestimate their true strength. This, in my view, was a major cause of the Civil War. Nobody starts a war they don’t expect to win. But it’s very easy to fool yourself into thinking that you might win.

The way that democracy helps prevent civil wars, is that a faction that loses an election knows that it’s outnumbered. By screwing with this function, the Electoral College increases the odds of a civil war in this country. (So do weird ways of counting prisoners). Leaving aside the fundamental unjustness of it, this is the true reason we ought to get rid of it.

Side note: The fourteenth amendment made the Electoral College unconstitutional at least at the current population numbers, but somehow no court has noticed this yet. Reynolds v. Sims found a state-level Electoral-College-like system unconstitutional. But there’s no reason that the logic of the case doesn’t apply to the federal system as well. The Senate too, of course.

All this is to say that you should read Underground Airlines, but ignore the Carolinas bit. It doesn’t affect the story at all.

At Practice, I was asked to describe the difference between SVN and Git, and also between Perforce and Git.

The answer I gave goes like this:

“A Guide to SF Chronophysics” describes four types of time travel plots. Type 1 is deterministic – whatever happens, was what was destined to happen. There’s only one timeline. Type 3 is the one where someone steps on a butterfly and Trump is elected president. Type 2 is half way in between – you can change things, but they tend to converge back to the original timeline. And finally, type 4 involves multiple universes – every change (including time travel) creates a new timeline.

SVN is type 1. Git is type 4. When you “amend” a commit in Git, you actually create a whole new commit, forking off from the same parent as the previous one. You can use your time machine’s “reflog” functionality to see the old one. Similarly, rebase creates a new timeline from some point in the past.

Perforce, I’m told, is somewhat like git, but it treats changesets rather than snapshots ("commits” in gitspeak, although in ordinary usage the term commit often refers to a changeset) as fundamental.

This is an instance of the mathematical notion of duality. The first example of duality I learned was polyhedra: if you swap the faces of a polyhedron with vertices, you get a different polyhedron. The dual of a cube is an octahedron (known by gamers as a d8). Instead of six faces and eight vertices, it’s got eight faces and six vertices.. The dual of a dodecahedron (d12) is an icosahedron (d20). The dual of a tetrahedron (d4) is itself. The Japanese addressing system is almost a dual of the US addressing system. In the US, we give addresses in terms of strees. In the Japanese system, blocks are the fundamental unit. I have been meaning for some time to design a game around the concept of duality, but I have not yet figured out quite how to do it.

Anyway, the graph of changesets is just the graph of snapshots with the vertices and edges swapped. Duality.

There is a ton of symmetry between messaging and late binding at the core of OOP, and private name spaces in Plan 9. With messaging in OOP, the decision about what code to run is made dynamically, as late as possible. With private name spaces, each process sees a its own file system hierarchy. The /foo/bar/baz that I see might not be the same one you see. In a sense, private name spaces late bind file contents. This is a big deal when all system functions are accessed using files.

There’s a great quote from Kay in the Early History of Smalltalk, that I still don’t fully understand, but I think applies here.

“Smalltalk is a recursion on the notion of computer itself. Instead of dividing ‘computer stuff’ into things each less strong than the whole–like data structures, procedures, and functions which are the usual paraphernalia of programming languages – each Smalltalk object is a recursion on the entire possibilities of the computer.”

This seems pretty reasonable descriptively, but not really great software engineering.

Recently I submitted a bug fix which illustrates one case of this: jgit was willing to write git tree entries with zero-length names. These entries represent, roughly, filenames. So by removing power, I was able to reduce bugs. This is sort of a small case of a power reduction – previously, the domain of the function was approximately all strings; now it’s all-but-one.

But let’s look at a stronger case: OpenSSL. OpenSSL famously had a wide surface area which allowed all sorts of use cases. Unfortunately, most of those use cases were wrong, from a security perspective. Maybe there’s room in the world for a security library where everything is permitted. But mostly I would rather use the library where only correct things are possible.

I guess this isn’t always true – I use a lot of Python, and when I’m writing Python to write SVG files, I don’t bother with an interface that would prevent me from making formatting errors. I just use print statements. But I probably would prefer the interface if I were programming for external consumption, as opposed to hacking together some throw-away code to get something else done.

Those are some special cases, but the most general reason for limiting what your code can do, is that limits make analysis easier. Valgrind has to do a tremendous amount of work to show that one particular run of your C code doesn’t have memory errors. Java simply never has that problem (C++ references don’t either). Regular expressions are far less powerful than full parsers, so it’s easier for a human reader to understand what they’re doing. Pure functions and immutable data structures are weaker than impure/mutable – but if you use a lot of them, it’s easier to track down where that stupid variable got changed. You can also build abstractions like map-reduce on top of them.

Which I guess gets to a point that David makes later:

I think the key idea is find uniform interfaces (the message, the file), make them as dynamic as possible, and build a system around that. Another striking thing about Plan 9 is that everything uses 9P – the remote file system protocol – both locally and remotely. If you didn’t have to interact with the outside world, you’d basically have only one network protocol for all services.

But this also reminds me of the STEPS project to build a complete system in 20,000 lines of code (also Alan Kay, et al). To do that, you have to discover powerful abstractions and use them everywhere. Having just one network protocol is a good start.

[rearranged from earlier]

Consider the Plan 9 window manager. It consumes a screen, a mouse, and a keyboard from the computer, (/dev/draw, /dev/mouse, etc.)… …and then re-exports virtual screens, mice, and keyboards to each of the windows that it makes. The programs in each window don’t know they’re in a window. You could run them w/o the window manager and they’d take up the whole screen.

In indexed-color (e.g. 256-color) graphics, which Plan 9 supported, there is a difference between being full-screen and being windowed; when you are full-screen, you have full control over the palette. When you aren’t, you have a sad negotiation problem.

Also, in a windowed mode, you can be partially covered up and then exposed, while in a full-screen mode, you can’t. So either the full-screen interface has to contemplate this possibility, or the windowed interface has to be artificially weakened.

Anyway, a file (or series of files) is the wrong interface to a screen. You want a higher-level interface that can do things like scrolling, or playing movies, or drawing textured triangles. These are both often hardware-accelerated, and this matters a lot for smooth graphics. This sort of rich interface is best accessed through a series of functions, which communicate, in part, by reifying objects ("a window”, or “a button") so that they can be referenced.

Because I can write any old string to a file, there is nothing that will check for me whether I have written a string that does something meaningful (until I run my program). Plan 9’s use of C’s file reading APIs makes this even worse: are short reads or short writes possible? What do they mean? Sure, you could document that, but you shouldn’t have to; a good API is the documentation about what’s possible.

And to a reader of code, uniformity makes navigation difficult. What’s this piece of code doing? The same thing as all of the other code: reading and writing some files. At this point, strace is a more useful debugging tool than grep, since at least I can see which file is being read/written by a particular piece of code. Larry Wall once said, “Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in.” There’s more to life than visual appeal, but I do think there’s something to the idea that different tools should look different so you don’t accidentally grab the scalpel when you wanted the cautery pen.

I also don’t believe that local resources should be treated the same as remote resources. This is a seductive idea – they’re just streams of bytes, who cares where they’re stored? And sometimes, it’s reasonable: when you’re building casual software where you’re not going to think too hard about failure cases. But when engineering something that will see heavy use, it matters whether a read failed because of a network failure vs a disk failure. Network failures are recoverable; disk failures more-or-less aren’t. And often a stream isn’t the interface that you want for network communication anyway – something that’s datagram-based and best-effort is better for games and telephony.

And this is why basically nothing is 20,000 lines of code, and if anything is 20,000 lines of code, it’s “by shaving off as many requirements of every imaginable kind as you can”. As programmers, we deal with extremely heterogeneous systems. A carpenter might pound a thousand identical nails; we just write a nail-pounding function. So it’s not surprising that we end up with specialized rather than uniform interfaces, and it’s not bad either.

When I told some folks about this at NYC Playtest, I was told that people who like set-collection games don’t like lying games and visa-versa, so nobody would ever play it. But in fact all of our playtesters liked it just fine. Also, poker is kind of that.

Random side note about poker: the notion of a game that is (almost) exclusively played for money is bizarre. Remember when MtG started there was this notion of playing for ante? And then people tried it and it was terrible and it never caught on. If someone invented poker today, as a Euro-style game, would people think of the real money thing as a gimmick? Would it be almost an art game, like Cordial Minuet or Train?

We didn’t do nearly as much playtesting on Whipsaw! as I’ve done on Loading Zone. It’s a much simpler game, and we were on a pretty tight timeline. It’s definitely not perfect: in playtests, players didn’t lie as much as we wanted them to. That might be because it’s hard to convince people to lie (or hard to do so in a set-collection game!). Or it might be because the incentives are wrong. But we weren’t able to figure out a way to improve the situation.

The game works like this: you’re trying to build parkways (there are four). The scoring is roughly quadratic: most parkway cards give victory points for each card in that parkway. So you would rather have all of one parkway than half of two. The cost of a parkway card is some number each of legislators, judges, and bankers. You have a hand of these resource cards, and draw more every turn. They’re played face-down, so you can lie about what you’ve played. Each type of card can also be played as an action: bankers lend money (which acts as additional bankers but costs points at the end of the game), legislators call bluffs, and judges temporarily block legislators, giving you a chance to “make it right”. To make lying more interesting, the resources have colored backs which give incomplete information about what they are. So, the cards with black backs are mostly judges – but not all. The game has a little more complexity, but that’s the gist.

Whipsaw! came together pretty quickly: I wrote up a first draft, then Ed and I tested it. My version was too long: it had six parkways instead of four. And it had a weird complication: instead of judges blocking bluff calls, special lawyer cards would do it. Lawyers could also block opponents’ lawyers. (In this version, instead of using legislators to call bluffs, you would do it by paying the cost of it yourself). Scoring was roughly linear (and Lost Cities-inspired: you could actually go negative if you didn’t have enough cards in a parkway).

My notes on this playtest say that the major fun parts were: - It played pretty quickly. - Getting away with lying was fun. - Strategizing about lying was fun. - Lawyers were probably the most fun part. - The colored backs made lying more interesting.

And the notes say that the major flaws were: - It was too long – 30 minutes would be better. - There was maybe not enough lying.. - There was definitely not enough calling of bluffs (in part because it was expensive). - Some of the complexity was silly. - And it was maybe hard to know what resources to save in your hand, and in general save vs spend was not an interesting decision. - Set collection wasn’t that interesting. - It was hard to track what other people were doing (too many cards, in part).

Ed’s second draft fixed most of this. He added more of a narrative arc by dividing the game deck into three “years”, with more-expensive properties available in the later years. He reduced the number of roads, and adjusted the scoring. And he invented the rules about how legislators, judges, and bankers worked. The game was pretty close to the final form at this point.

I ran a few more tests – at NYC Playtest, and at Recurse Center, and made some minor tweaks. And then we declared the game done and submitted. We should probably have done some artwork.

Want to give Whipsaw! a try? Here are the print-and-play rules and cards.

Set is played on ℤ₃⁴. There’s a variant called Projective Set, which is played on something called a finite vector space – 𝔽₂⁶. Basically, that’s the six-bit numbers (but Projective Set excludes the zero card). The rule is that N cards can be removed if, for each bit position, the cards sum to zero mod 2. Or, perhaps more simply, each symbol appears an even number of times. Any seven distinct cards contain at least one such group.

These four cards can be removed.

One of Danielle’s co-workers lamented not being able to buy a copy, so I decided to make some. Unlike the one shown on the Wikipedia page, mine are accessible to the colorblind. I guess I should note that my version is in fact just called “Projective”, as Set is a trademark of Set Enterprises and I don’t want to annoy their lawyers any more than my applet already has. So now you can buy a copy. I’m not making money off of this because doing so would be a hassle; the price is what The Game Crafter set. I got mine yesterday, and it looks pretty good. Danielle beat me up some, and I enjoyed it.

This got me to thinking about what other mathematical objects could be used for pattern recognition games. I immediately thought of quaternions, and then got Hamilton stuck in my head. Did I mention that I’m not great at math? I had forgotten that the quaternions are non-commutative, making the game much trickier to design. But I guess I don’t need to be totally accurate to the math. As long as I keep i²=k²=k²=ijk=-1, everything will probably work out. The idea will be to find N cards whose product is one. I’m thinking of calling it Uno.

I even came up with some icons, based on the Swedish point of interest symbol:

Notice that each of i, j, and k can be combined with a rotation to form the -1 symbol, and i, j, and k can be overlapped to do the same.

This might be too easy, so maybe I’ll need to do ℚ² or something. Or just go straight to 𝕆, whose multiplication table is too big to remember. But you can always use this simple and easy to understand diagram (from Wikipedia):

It’s kind of fun tho.

Play it here.

I’m downloading and processing the 3-grams now, but they’re really big – like several terabytes of data. Then I guess I’ll merge the 1-grams, 2-grams, and 3-grams, so that you can have interesting matchhups like “conformity” vs “the policy of”.

About fifteen years ago, I got into an argument about this in the context of a video game. The idea was that the game would have guards which would punish you if you did something illegal. The problem was that the game supported building machines, and Turing proved that no computer program can, in the general case, figure out what a machine will do. So if you built a sufficiently complicated machine, either you would get away with murder or be wrongly convicted.

Humans, of course, have the same problem, but we pretend not to.

Self-driving cars are a relatively easy case: only a monster would program in anything but pure consequentialism. Especially since, as a practical matter, self-driving cars are likely to be much safer than human-driven cars.

Before computers can replace lawyers in the the general case, they will have to understand human language (in order to interpret contracts, laws, and precedents). This is the single hardest problem in computer science. We have made almost no progress here. If we can solve this problem, we have achieved general intelligence, and within a year or two nobody will have a job.

There are areas now where computers could assist us. For instance, let’s say we’re considering Solomon’s case: which of two women is the mother of a child. Imagine that one woman is has brown hair and brown eyes, and the other has blonde hair and blue eyes. The child has brown hair and blue eyes. (We don’t have a DNA test for some reason). How do we combine our two pieces of data? There’s a fairly simple formula that does it precisely (given some odds of the various inputs). But right now, in order for a jury to use this formula, we need to call a statistician to the stand. And if the jury finds one of the women twice as credible, they don’t have a way to incorporate that data, even though the formula could easily do it. This would be a good first step, but for political reasons it would be shocking to me if we took it.

I should have added: This thing where the law is designed to be interpreted by humans is famously hard for programmers to grasp. I had forgotten that the thing where computers are bad at interpreting language (yet good at following rules) is just as hard for lawyers. I think the lawyers’ confusion is part of what’s behind the recent encryption debate (roughly 40% members of congress have law degrees).

I think Feld is good, but mostly his games weren’t for me. Still, I learned something about what I like in games, and that’s valuable. I had been slowly working on designing a more Euro-style game, and now I have a stronger sense of what sort of play I want to encourage.

In all of games I played, there were multiple ways to score. I do like games that have multiple viable strategies, so this should have been appealing (and in fact it often was). But one play was not really enough to learn to keep track of all of them (in some of the games), or figure out which I should be focusing on. Can you win at Bruges without touching your canal? I don’t know, but I sure didn’t!

I played:

• Bora Bora: A clever action selection mechanism: each player rolls three dice, then takes turns placing the dice on various actions. Higher numbers are more powerful, but you can’t place a higher numbered die after someone has placed a lower number on a given action. The game had a lot of bits: cards, tiles for women, men, tasks, jewelry, resources, fish, offerings and turn order, along with dice, (cardboard) shells, and various wooden pieces. There was a satisfying variety of actions, but I found it a bit overwhelming to pay attention to all of the ways to score. I guess a second play would have helped here. It didn’t seem reasonable to put together a coherent strategy up front, because the dice and opponents’ plays could easily screw it up. Being forced to react to changing circumstances is something I like. This was probably my second-favorite of the games, although I think with more play, Trajan might displace it.

• Trajan. The key innovation of Trajan is the Mancala-like action selection mechanism. Mastering this mechanic would allow more planning about what actions to take, but it seems like a pure computation exercise. I guess that could be fun – in theory, portions of my game-in-progress, Loading Zone, are like that. Unlike Loading Zone, you might want to explore a broader tree for Trajan’s Mancala, since you might want to be able to react to your opponents’ choices. Still, the Mancala thing was neat, which counts for a lot in a first play-through.

• Strasbourg was my favorite of the games I tried. It’s got an all-pay auction mechanic that I really dug. As a first-time player, I managed to screw up and make one of my goals impossible in turn one – I didn’t realize that I would need to win every meat auction. I wonder if somehow moving the goal choosing later in the game would reduce the variance. But maybe if I were a stronger player, I would have chosen more goals and been less sad about losing one.

• In the Year of the Dragon. A disaster aversion game. It turns out that I really don’t like games where you can end up in an unwinnable state and then have to sit there losing for the rest of the game. That didn’t happen to me; I did get a little screwed but mostly lost through some poor choices. But it was even painful to watch it happen to another player. I’m OK building something that’s less than optimal (but still scoring some points). And I’m OK with getting destroyed. But if I’m getting destroyed, I want it to be over quickly. In a two-player game, I can just resign, but Feld’s games seem mostly to be intended for three or more.

• Bruges. Another disaster aversion game, although less so. The push-your-luck aspect made disaster aversion much more painful; it feels hideously unfair when you were playing pretty cleanly but just rolled the wrong six. Worse, there was one card which was basically a “screw your neighbor” (and another which made one player much more resilient), each of which seemed to dramatically change the game. The game seemed to want me to primarily build my canal and only secondarily recruit people, but the people were so much more interesting than the canal. I never seemed to have enough actions; each (4-action) turn you can actually recruit fewer than one person on average, since you will gain 1⅔ threat tiles and you need at least 3 actions (half of a worker-creation, one house, at least half of a money-action, the person) to recruit. I know that making hard choices is the essence of gaming, but I wanted to feel like I had lots of good choices, instead of having to constantly spend all of these interesting people I could be living with.

Across all of Feld’s games, I liked the multiple small decisions (especially in the rare cases where they were decisions under uncertainty). I generally liked the feeling of abundance – there are lots of things I could do! The two games I liked least had less of the abundance feeling, unsurprisingly. But because it was generally hard to choose actions (because I had to fuck around with Mancala stones, or hire workers, or have the right dice), it was hard to build up a strategy. The only choice was to be mostly reactive. By the “abundance of actions” metric, I think Bora Bora was the strongest of the games I played, followed closely by Trajan.

Overall, I’m super-glad I spent nearly twelve straight hours playing these games, because I know I’ll be thinking about them for a long time.

Thanks to Daniel for organizing, and to Brooklyn Game Lab for hosting.

I was inspired by a lamp that hangs outside of my favorite ramen joint. I had originally intended to make something much closer to the original, but I wasn’t able to get a satisfying design. So I decided to go with something with more curves.

To design the lamp, I wrote a crappy Python program filled with magic numbers. It generated two files: a POV-Ray scene description, and a SVG for the laser cutter. This let me rapidly iterate on the design. Here’s a video render of an earlier version (I didn’t bother to make a video of the final version):

I hadn’t touched POV-Ray for like fifteen years, but it came back to me pretty quickly. It was pretty much exactly what I needed for a quick visualization of 3d parts. As an aside, my usual approach for both POV-Ray and SVG is to just use print statements. Yeah, there’s no guarantee that you’ll be generating correct output, but if you make a mistake, it’s usually visible and easy to fix.

I initially planned to have the lamp be made entirely out of laser-cut wood, with a standard press-fit tab/slot arrangement. I prototyped this at NYC Resistor, and discovered that fitting 25 slots into a ~60 mm ring was not going to work well. The wood was just too fragile.

So I bought some stainless steel rings, cut them open, and and cut circular holes in the ribs. The holes are sized (after some more prototyping) so that they fit quite snugly onto the rings, which made assembly kind of a pain. I think next time I would cut the holes looser and use rubber o-rings to constrain the positioning of the ribs. It’s not expensive to get Viton o-rings in an appropriate size (Viton was the material used for Challenger’s infamous o-rings, but hopefully nobody will be launching my lamp into space).

I did the final laser cut at Ponoko, because I didn’t want to try to track down an appropriately sized/shaped piece of wood for Resistor’s laser. One kind of stupid thing is that fitting the lamp ribs onto Ponoko’s largest (P3) sheet was a manual process. Each rib is individually shaped, so they don’t nest cleanly. I guess I probably could have coded some solution which nudged the pieces around until they fit, but it was quicker to do it manually.

I’m pretty happy with the end result. The photo at the top of this post was taken immediately after turning the lamp off; because it has an incandescent bulb, you can still see a bit of the glow.