Fourbyfouria Postmortem

The best possible time for an idea for a sequel is probably right after a competition deadline. The worst is probably a few days before, but it's still pretty good. That's what happened with Fourbyfourian Quarryin' (4b). It didn't have a name then, but I had some obvious questions floating around from Fivebyfivia (5b). What about scenarios with pieces besides a queen and rook? I'd actually done three pawns on three pawns, only it was more a choice-based thing than actually making chess pieces move.

So 4b probably distracted me from what would've been useful fixes to have straight-away in 5b. But when you get a new idea, you have to go with it as much as you can. It was a nice distraction from worrying about I'm glad I was a bit ahead of the curve with 5b, so I could sit down and really think about 4b. The obvious candidates were to have king and two minor pieces (bishop or knight, called B or N below) mating against king. While you can't force a two-knight mate in-game, you can place the pieces so you get checkmate. But it's not really that tough: put a king in the corner, have your king block his, have one minor piece block a fleeing square, and have another give check. That'd be three puzzles. But they were kind of basic, and besides, the result might be ... I don't know? Three 4x4 regions, one for each two-minor-piece combo, to make 16x12?

That felt too pedestrian. I looked for something more exotic and interesting and remembered something odd I figured long ago. A king and bishop could checkmate a (very cooperative) king and opposite-colored bishop. This StackExchange question brought up some other ideas: each minor piece vs. minor piece ending was potentially won, if one side played horribly. The solutions were similar, but it was neat and weird to see that, yes, it could be done. Except bishop vs. knight, because the knight could jump in the way. Still, 3 4x4 boards conquered would make Twelvebytwelvia 16x12. Not bad! Then, I figured that bishop could checkmate knight, but it was a bit tricky. That blew up the 16x12 board , but I realized the three two-minor-piece mates on 4x4 boards could make 16x16, which would be just great.

All this happened on the night of June 27th, or early morning June 28th. ParserComp entries ended June 30th. So I wisely made a placeholder commit on the 28th and did nothing until July 6th.. It was 4I then, as I'd decided "Fourbyfourian Intrigue" was the way to go. I think I had an idea that a 4x4 board would make things extra-simple for the player. They shouldn't have to wander around.

And yet I felt it wasn't enough. Chessplayers might find the two-friendly-piece checkmates easy, and solutions could overlap.

Then I started finding ideas. What if the enemy king weren't in the corner? Maybe because he was suspicious the other Fourbyfourias fell? My commits on July 6th, added the three later puzzles (friendly B/N, B/B, N/N) and the "no-corner" rule. I implemented the Ministry of Unity, giving you some control over which quests you faced, in which order. One useful bit of code was that I gave directions a lot more properties. In 5b, I had, of necessity,

xness of southeast is 1. yness of southeast is -1.

You can see what's going on here: these offsets are how your x-coordinates change if you go southeast. But in 4b, I used them more heavily to track the seven quests.

a direction can be unsolved, solved or stalemated. a direction is usually unsolved.
a direction has a piece called first-piece.
a direction has a piece called second-piece.
a direction has a rule called visit-text. visit-text of a direction is usually the trivially ignorable rule.

There's a lot more. You can see it in "chapter properties for quests" in the source code. But having this structure early on likely saved many headaches. I had to modify code, but I realized how much worse it'd be if I hadn't given directions all these properties. For instance, the visit-text rule would do nothing for the first four quest directions, then check the first four were solved for south and east, then check south or east was solved for southeast--you coudn't get passage there otherwise, given the map.

A thing about the no-corner rule, though: I didn't realize it eliminated all possible two-knight mates. Unless ... well, you found a secret corridor for your king to sit in, then if the knights were just right, it'd work. That was all a bit tangled, so I just went with 5x5 castles and a note that Fourbyfourians thought they might be getting too good for themselves, and besides, on a 5x5 board, I wouldn't have to decide which center square you'd start in.

Along the way I'd added Robin Johnson's suggested "just type the square to move there" fix for 5b, which was trivial in 4b, since you had no crazy horse. I figured navigating the map would not be so bad.

I added more rules, too. I had fun noting what happened if you almost did B vs N right (e.g. the knight could block.) It seemed to fit in with the diplomacy-oriented tone. "See?! You can trust your knight, enemy king. Your knight saved you!" Then I realized the non-corner mates might be something you could duplicate, so I said no hiding behind a bishop. (The knight was another matter.) Perhaps it was a bit mean on my part.

But I still had a problem. I didn't like the whole checkmate, checkmate, victory theme. I wanted a bit more. And it came in the form of -- what if the other countries wise up to their neighbors' kings dying? The kings will be suspicious. They won't want to hide in corners, and they can recognize danger. So, how to do something different than checkmate? Maybe even gain the other kings' trust?

Stalemate. That's where a king is not under attack but has no legal moves. So suddenly, I had an idea: you needed to find 3 stalemates and 3 checkmates. This gave the variety I wanted. But of course there was more.

I wanted to see all the possible checkmates and stalemates to make sure I wasn't missing anything. Writing the python script for that turned out to be pretty fun. And the results included some odd amusing positions I'd never have considered! It seemed worthwhile enough to write up, for those really curious. But it also gave me some assurance that stalemating was potentially easier than checkmating, as you had more ways to do it.

I shortly realized there were a lot of more-or-less duplicates. For instance, some positions just had everyone shifted over one square. Some were mirror images. There weren't actually any rotations, as I only checked for the enemy king on b1 and c1, since he had too many fleeing squares outside the edge, and I didn't put a minor piece past the 3rd rank. (This eliminated some solutions but they weren't new--mostly just moving the bishop along the diagonal. A knight always had to be close, anyway.) This tidied up the list of equivalent stalemates I'd written, and there were still enough. It was one of those projects where I felt good tidying up potential loose ends. Of course, there were others.

This all was fun for a chess player like me, but what about non-chessplayers? I worried 4b would be too hard for nonplayers if it rejected similar mates but too easy for stronger players. And that's where normal and hard modes came in. I in fact was pleased with the design here: normal mode allowed you to skip the two-friendly-piece stalemates, since one piece was unnecessary.

The start had gone so fast, and I had a lot of time for regression testing, so IFComp (September 28) seemed a very real possibility. I guessed I had time enough to merge code from 4b and 5b into a header file. It was the right choice. It shook out a few inconsistencies. For the first time, I uploaded a project to itch.io months before release, with a password--this helped with tweaking the web build. It's the first time I really paid attention to assemblies in advance, and it was nice to be able to fob off some testing on itch.io. Web play for parser games has gotten bigger, and I'd had a few misses with EctoComp, where the organizers were fortunately forgiving.

Tweaking the zip-file assembly and creating the PDF walkthrough took a bit of focus from the actual Inform programming suffer. For me, writing the walkthrough of all stalemate possibilities was more fun than practical stuff. (Oops.) I had an idea I should offer tutorials, but I didn't know what. An early tester mentioned they wanted a story. Make each 4x4ian king different. This was back in August. My brain finally came through a week before! The stories were ... a bit political. Though also I don't think much of golf in general as an old-boys' pastime.

I really should have been more aggressive about asking for testing, or pointing out what was useful. I felt weird submitting 2 chess games in 3 months. I know my games aren't easy to test, but my testers came through and pointed me to ways to give better cluing, even if they didn't think they did. They found the sort of big issues I'd hoped. I had plenty of time to test a few things I knew I should've tested, but I didn't quite. I did well to put aside time on the final week for final stuff and regression testing. I wrote a bunch of regression tests--but of course I didn't write them for trying and failing, so a bug slipped through in my hinting code. It's one I could've caught with more right-after-the-change testing.

The start of IFComp was busy with fixes but not hellish. I had a hotfix for a runtime error in the hinting code, and looking at it revealed something else: I'd implemented a command to take a piece off the board a week before release. (I realized should've done so back in July. I suffered a horizon effect here--5b's puzzles were timed, so you couldn't remove anyone, and I assumed 4b shouldn't allow it, either.) This opened a whole can of worms with discovered checks or whether you should be able to move a piece. It required pulling three very similar code paths into one. It's something a lot of people might not see, but all the same, I wanted to do things right. I was able to put a "warning! If this breaks, reset the quest" band-aid on it, while blocking off the bad special cases, before taking a few days to verify my new code for shuffling/removing pieces did, in fact, look at everything. The regression scripts I wrote were good enough that I was able to extend them to test this pulled-together code that eliminated bugs in the piece-shuffling code.

Sadly I took forever to tweak some out-of-world help text that needed it. It's surprising how long trivial changes took. I think trying to review all the other IFComp games got in the way of fixing my own bugs. But I also think it was good to have that distraction, so I didn't tinker and worry about what fixes I should sent to IFComp and which should wait until post-comp.

Of course, there was that one bug that slipped by. My test scripts were good but not quite good enough! I dismissed the idea of testing mirror-image solutions just to be sure, and because of that, I missed that this code was wrong:

to decide which number is basic-dist of (r1 - a room) and (r2 - a room):
    decide on (absval of (xval of r1 - xval of r2)) + (absval of (yval of r1 - yval of r2))

You see, Inform goes parentheses then left to right, not PEMDAS. To make matters worse, it worked most of the time, so it was hard to catch!

Still, I felt good enough about what I had that some of the more arcane code refactoring  was pushed to post-comp. For instance, referring to the Fourbyfourian King as "k4" made my code a lot tidier, as did "p1" as a shortcut for "first-piece of quest-dir" and "p2" for "second-piece of quest-dir".

I missed a lot, but I found enough that I was able to relax and be able to look at all the other IFComp entries.