I recently argued for Cohabitive Games, games that are designed for practicing negotiation, or for developing intuitions for applied cooperative bargaining, which is one of the names of preference aggregation.

I offered the assets for P1, my prototype, to whoever was interested. About 20 people asked for them. I told most of them that I wanted to polish the assets up a little bit first, and said that it would be done in about a month. But a little bit of polish turned into a lot, and other things got in the way, and a month turned into ten. I'm genuinely a little bit dismayed about how long it took, however:

P1, now Optimal Weave 0.1, is a lot nicer now.
I think it hangs together pretty well.

You can get it here: Optimal Weave 0.1. (I'm not taking any profit, and will only start to if it runs away and starts selling a lot. (release day sale. get in quick.))

There's also a print and play version if you want it sooner, free, and don't mind playing with paper. (Honestly, if you want to help to progress the genre, you've got to learn to enjoy playing on paper so that you can iterate faster.)

There's also a version that only includes the crisp, flippable land tiles, which you can then supplement with the ability, event and desire cards from the printed version and whatever playing pieces you have at home.

(note: the version you'll receive uses round tiles instead of hex tiles. They don't look as cool, but I anticipate that round tiles will be a little easier to lay out, and easier to flip without nudging their neighbors around (the game involves a lot of tile flipping). Earlier on, I had some hope that I could support both square layout and hexagonal layout, that's easier with round tiles, though everything's balanced around the higher adjacency of the hexagonal layout so I doubt that'll end up working)

I'll be contacting everyone who reached out imminently (I have a list).

What Happened

Further learnings occurred. I should report them.

I refined the game a fair bit

There were a lot of abilities I didn't like, and a lot of abilities I did like but hadn't taken the time to draw up, so I went through the hundred or so variations of the initial mechanics, cut the lame ones, added more ideas, then balanced everything so that no land-type would get stuck without any conversion pathways.

I also added an event deck, which provides several functions. It simplifies keeping track of when the game ends, removes the up front brain crunch of dropping players straight into a novel political network of interacting powers, by spreading ability reveals out over the first couple of turns. The event deck also lightly randomizes the exact timing of the end of the game, which introduces a nice bit of tension, hopefully spares people from feeling a need to precisely calculate the timing of their plans, and possibly averts some occurrences of defection by backwards induction (though the contract system is supposed to deal with that kind of thing, for reasons that are beyond me, people seem to want to try playing without the contract system so, here, this might be important).

I found a nicer low-volume prototyping service

The Game Crafter. Their prices are better, uploads are easier to automate, and they offer thick card tile pieces, as well as various figures. I think some of those figures are pretty funky little guys. Those are the ones you'll be receiving.

Their print alignment is also pretty bad. They warn you, so I'm not mad or anything, I just find it baffling. It's especially bad with the cardboard tile pieces. Oh well, everything looks good enough, I'm happy overall, although I do notice that no big popular board game that I've ever heard of decided to publish through this service I guess it's just because they really do specialize in small volume print runs. Although there is one game that seems to be especially popular here that I should mention, Doom Machine, it's a solo game about fighting a deeply misaligned industrial deus going through a slow takeoff. It's really good, from what I've heard.

Automating the pipeline

I did a thing where instead of just drawing card svgs directly, I drew parts, and wrote code that glued the parts together in standard ways and generated card-shaped svgs.

Upside: It meant that I could change details later on without having to redo every one of the cards. This makes some changes mildly harder (defining new cards) while making a lot of other important changes feasible at all. I think it's a good thing to do. There are many things that you cannot know during the first test-print but which you will learn before release, and when you learn these things you'll be grateful for the automation.

Some large tasks that were successfully automated: Changing the clown card marker, the stroke width of the grass tiles, the dimensions of the land tile assets, doing multiple variants of good cards over different elements, changing those elements, varying the number of land tiles to make good use of paper in the print and play version, or the tile slugs in the tactile version, counting and making sure that we have the right number of cards in each deck, generating card backs.

• Later potential automation task: There's another type of card that's tiny and adorable (which is good for conserving on package weight and tablespace) and I don't see a firm reason I shouldn't rerender everything for that card size. I've used cards of this size before, and they're very difficult to shuffle, so it might not be practical, so I'm still undecided.

However, I regret picking Rust as the programming language:

• I was hoping to use resvg to render the svgs to pngs more efficiently than I could by calling inkscape via the command line hundreds of times, but that didn't work out, resvg was missing features, and waiting longer for those renders was never a big deal.
• I think I underestimated the extent to which rust's type/ownership checking is a real encumbrance when refactoring. Rust's static analysis is complex enough that despite their best efforts, there will be situations where it will be unable to communicate what's wrong. You will be saved from bugs at runtime, but before you are allowed to proceed to runtime, you will have to track down new classes of bugs in your types. Language complexity, alas, has costs.
• Should have gone with typescript. Maybe I'll try a LLM-assisted port at some point. Rust is hyper-explicit, so it should be pretty amenable for porting away from.

Final Autumn Together

I made another, separate cohabitive game called Final Autumn Together.

I made it in the hope that by releasing two games instead of just one I could broaden peoples' horizons a little more or avoid ending up with people thinking that some of the arbitrary features of OW.1 were essential or definitional to cohabitive games. I ended up incorporating the best ideas from Final Autumn into OW.1/the idea bag though. But you can try Final Autumn if you really want. Purchasable here. I'll make a version for printers if people ask, but since I don't think there was very much emergence here, it may be enough for a designer to just read the rules below.

It's a game about coming together (or apart) to scrabble for supplies before a perilous winter voyage. At the end of the game, a d20 is rolled, which tells us how long the voyage was. Every player who didn't acquire enough supplies to last through the voyage Loses, and every player who had enough to last the voyage Wins.

This random factor is a simple hack for turning a visceral, absolute win/loss condition into a non-zero sum score outcome. By optimizing your probability of surviving, you will behave just as if you have a linear utility function over supplies.

Eventually players will realize that if they earned 19 supplies, and the dice rolled 20 and they "lost" anyway, they still did very well, and then they will find it easier to understand what it is to be an optimizer, and then they might stop bothering to roll the dice at the end. It is fun to roll the dice at the end, though.

It generally pays to publish your simple hacks, as more sophisticated applications for them will soon follow. In the OW.1 manual, I propose one. "Ending events", a small deck of apocalypses that combine to form a rich distribution of outcomes that project various different risk mitigation values onto the "preparations" players can take over the course of the game.

Final Autumn: Rules:

After 11 rounds, winter will starve the land. 
In preparation, each player will struggle to acquire as many day's supplies as they can, for there will not be enough. As the snow begins to fall, each pair will depart on their ship. 9 days to cross the strait to the continent, and then fortune will ambush each boat, roll its D20, and give the boat so many more days of grim coasting in search of a safe harbor. To survive winter, they must have enough daily supplies to last through this voyage.

In their turn, each player can activate one of their face up abilities from each of their move phases: morning, then noon, then night, and then dream.

Players start with four face up cards: learn, and consolidate for the night phase and another pair of the same for the dream phase. Make sure that no copies of those cards remain in the pool. Players are also given 3 supplies, and 3 random abilities are placed in their stack. These will be learned and replenished as the game proceeds.

At the end of each turn, the player is allowed to replace one means from the stack with a new one drawn randomly from the pool. The lead player must also remember to advance the day counter towards the breaking of winter.

The core mechanism of the tableau are those pairs of conceive and consolidate actions in their night and dream rows, which respectively add a new card to the tableau and turn it face up to make it usable. The most common abilities tend to steal or transmit supplies between players, creating or destroying supplies in the process. Other abilities affect the tableau of other players, regressing, destroying or stealing their abilities.

In the end, though, I felt that Final Autumn did not contain enough surprises, for me. I am always drawn back to the verdant social playground of Optimal Weave.

Now is the time for everyone to join in.

Meal's ready, let's eat! dreamshrine.org/OW.1/optimal_weave

In the least, if you're curious at all, have a skim-read of the rules document and see what you can glean.

As it was before, my work on cohabitive games is going to be sporadic, but I will do what I can to facilitate a cohabitive games community online. There is an element channel that you can join.
Although element is a better chat thing than discord due to element's channel-sharing feature, federated protocol, and end to end encryption, I acknowledge that it's somewhat impractical to adopt yet another new chat thing when it's only like 3x better than discord and when it's only been better for about a year and when near future social technology (which I study) is likely to continue to rove around into yet more protocols and give rise to even better chat things than element very soon. So I'm considering deprecating element and regressing to discord. But I'm really ambivalent about it. The element communities I'm a part of tend to be pretty serious, discord will never meet their needs. I have no discord communities that are like that. Discord is kind of an inherently silly and transient thing, gamer-coded, proprietary, doesn't make any attempt to support transferring out of system, sometimes bans people at random. So I'd need a little bit more convincing before declaring a move to discord.
Regardless, there's already a channel in dream shrine discord for cohabitive games/cooperative bargaining theory, and you can join it if you want!

If this game turns out to be good, I'm going to be pretty enthusiastic about building meetup groups around it and about the underlying philosophy to explore the social emergent effects of giving everyone in a community common knowledge of The Way of Cooperative Bargaining. It could be quite special. If The Way is as strong as one would expect, you'd really want your communities to possess it.