I happened to get to play Optimal Weave today and really liked it. I don't normally go for... well, board games at all, let alone strategy-type ones, but I had a lot of fun. The variable degree to which cooperation was a helpful strategy between goalsets (only sometimes) was neat. Good work!
I read the "manual" page here, but I feel like it's primarily focused on the philosophy of the game and hasn't given a complete account of the rules. I also downloaded the print-and-play files but they seem to only contain cards/tiles and no rules document. Is there some other rules document that I've missed?
In case my response seems confusing, a few examples of why this doesn't seem like the full rules:
- It says you can move on your turn, but doesn't specify where you're allowed to move to (anywhere? adjacent spaces? in a straight line like a rook?)
- It says you can pick up and drop objects on your turn, but "objects" are not mentioned anywhere else on the page and I can't figure out what this refers to
- Rules for contracts don't specify when you can make them or what you can agree to (can you transfer points? can you nullify an earlier deal? can you make the same deal twice to double the penalty for breaking it?)
- There are no examples of play
- I looked at a few of the cards in the print-and-play files, and they use terms like "nearby" that appear to be intended as terms-of-art, but which aren't defined anywhere
I should probably rewrite it, but the reason the rules document is the way it is is that I was writing it for developers (are you one btw) and so there were a lot of things I didn't want to be prescriptive about, and I figured they could guess a lot of it as they approached their own understanding of how the game should be and how things fit together, and I want to encourage people to fully own their understanding of the reasons for the rules.
For that, writing in this way actually might be necessary to get people to ask "how should it be" instead of just taking my word as law and not really thinking about the underlying principles.
It says you can move on your turn, but doesn't specify where you're allowed to move to (anywhere? adjacent spaces? in a straight line like a rook?)
I'm surprised you wouldn't just assume I meant one space, given a lack of further details.
It says you can pick up and drop objects on your turn, but "objects" are not mentioned anywhere else on the page and I can't figure out what this refers to
In this case, the other rules are on the card backs. A lot of them are, which may be part of what's going on here.
When someone gets a terrible hunger desire, it's explained on the card that killing creates bodies and bodies can be carried. Object stuff isn't needed before then. Maybe I should move the mention of object pickup to the hunger card as well, but I'm not sure there'll always be room on that (I'm considering doing one with a micro deck to support placing cards in the world), and it's possible that more objects, other than bodies, will be added to the game later.
terms like "nearby"
This one gives me anguish. I don't think formally defining nearby somewhere would make a better experience for most people and I also don't want to say "on or adjacent to" 100 times.
there were a lot of things I didn't want to be prescriptive about, and I figured they could guess a lot of it as they approached their own understanding of how the game should be and how things fit together, and I want to encourage people to fully own their understanding of the reasons for the rules.
I think this is a bad idea. Games are complex machines with many interlocking parts and they trade off between many goals; even an experienced developer can't generally fill in gaps and expect things to work on the first try. This goes double for you because you are deliberately making an unusual game. Asking people to invent some of the rules is placing a pretty significant burden on them.
And if the designer fails to supply at least one example of a good rule, this makes me question whether they ever successfully found a good option themselves, and whether any possible rule could be filled in that would lead to a good result. (Imagine a blueprint for a perpetual motion machine with a box labeled "you can put whatever you want here.")
Additionally, an interoperable standard makes it much easier for people to play with strangers. If every friend-group invents their own version, then when they go to a meetup or a con, anyone they meet will have a different version. An official version makes it easier to join a new group.
That's without even getting into the psychological hangups people have about official rules, which are considerable. I think board games tap into human instincts about societal and ethical rules, and human instincts would like to pretend that there really is a correct rule somewhere in the Platonic realm, and maybe it's unclear but it can't just be missing and it's certainly not up for grabs. I've seen people get pretty upset at the suggestion that there is no "right" rule for something because the designer simply never considered it, or that the version 2 of the rules is in some sense "a different game" from version 1. My pet theory is that this is an evolved security measure to not let cheaters escape punishment merely by claiming that there's a problem with the formal legal code (regardless of whether that claim is correct).
I do not think you need to worry about blocking people from making up their own variations. My impression is that most hobbyist board gamers who would like to have house rules will go ahead use them no matter what you say on the matter. (This won't stop people from clamoring for you to canonize their preferred rule, but I don't think you can stop that by leaving rules unspecified, either.)
If you insist on doing this anyway, you should at least be clear about it in the document itself. You are bucking the cultural expectations of the board game hobbyist community, which expect games to be fully defined when we get them. People are not likely to infer that you intend them to make up their own details if you don't spell that out.
I'm surprised you wouldn't just assume I meant one space, given a lack of further details.
That was my highest-probability guess.
I do not like rulebooks that require me to guess what the rules are.
I also picked examples based on how glaring the absence of a rule seemed (and therefore how much evidence it gave that I was reading the wrong document), rather than based on how hard it was to guess the most likely answer. If I was more focused on omissions that are hard to guess, I might have asked "can 2 pawns occupy the same space at the same time?" instead.
Maybe I should move the mention of object pickup to the hunger card as well
If you intend to use this on more than one ability, I think it's probably good to have object pickup rules in the rulebook, but there should be enough context that readers can slot the rule into their mental model of the game while reading the rulebook instead of leaving a dangling pointer that will only be resolved when they see the right card.
"Some abilities add objects to the map. Objects in your space can be picked up or dropped for free during your turn..."
You also probably need several more rules about objects, e.g. "Objects are carried by a particular pawn, and cannot teleport between the two pawns controlled by the same player. Stack the objects beneath the pawn to show they are being carried. Dropped objects remain in their space until someone picks them up. You can carry an unlimited number of objects at once. You can't directly take an object that someone else is carrying."
Also, your print-and-play files do not appear to include any components to represent objects. If you are expecting people to supply their own components for this, that ought to be called out in the rules (and you should say something about how many you need, of how many different kinds, etc.) In fact, it is standard practice to include a component list for a game--people usually skim right past it until suddenly they need it because they suspect they're missing a piece or something.
(Though if this level of effort seems excessive for how often objects are actually used in the game, that might be a sign you should either use it more or get rid of it. Sometimes there's a really cool ability that's just not worth the complexity it introduces.)
This one gives me anguish. I don't think formally defining nearby somewhere would make a better experience for most people and I also don't want to say "on or adjacent to" 100 times.
Having a short description that will probably give people the right impression is great, but I think lots of players benefit from having some document they can check to resolve a confusion or disagreement if it comes up. I can't remember a time I've played a game that had a glossary or a "longer descriptions of the abilities" section where I didn't end up looking at least one thing up, and I can remember a lot of times when I wanted one and it wasn't present.
Also, maybe try "within 1". (Someone will still ask whether this means "on or adjacent" or "in the exact same space", but I'd expect fewer people will need to ask compared to "nearby".)
then when they go to a meetup or a con, anyone they meet will have a different version
No, that would actually be wonderful. We can learn from each other and compile our best findings.
It's more of a problem when trying to talk about the game through the internet when you can't see each other playing and notice the differences in others' interpretations.
I guess the synthesis would be for me to be fully specific in the manual, then insert lots and lots of "but also try it this other way" sections all over the place, like chekhovs pathways in a metroidvania.
Objects are carried by a particular pawn, and cannot teleport between the two pawns controlled by the same player.
Oof, that's a good thing to point out. Not all bodies can be stood on, so teleporting might actually be a better rule, especially given how interesting that is as a mechanic.
[failed line of thought, don't read] Maybe, instead, the rule should just be that a piece can move any object in the same cell along with it when it moves. It may even be a good idea to include other players' pieces in that. Hmm. No. This would incentivize the formation of large clumps of agents that could essentially move around the board unnaturally quickly, using similar principles to those caterpillar trails, and aside from that being too damned weird, it would overwhelm the capacity of the cells. I like the idea of pairs of allied agents being able to do this, though (analogizes one carrying the other while the other rests). And in the case of objects, it would still incentivize clumps.
"longer descriptions of the abilities"
I'd like that. That would be a good additional manual page, mostly generated.
then when they go to a meetup or a con, anyone they meet will have a different version
No, that would actually be wonderful. We can learn from each other and compile our best findings.
That's...not the strategy I would choose for playtesting multiple versions of a game. Consider:
- Testers aren't familiar with the mainline version and don't know how their version differs from it, so can't explain what their test condition is or how their results differ
- You don't know how their version differs either, or even whether it differs, except by getting them to teach you their full rules.
- There's a high risk they will accidentally leave out important details of the rules--even professional rulebooks often have issues, and that's not what you'll be getting. So interpreting whatever feedback you get will be a significant issue.
- You can't guarantee that any particular version gets tested
- You can't exclude variants that you believe are not worth testing
- You can't control how much testing is devoted to each version
- Many players may invent bad rules and then blame their bad experience on your game, or simply refuse to play at all if you're going to force them to invent rules, so you end up with a smaller and less-appreciative playerbase overall
The only real advantage I see to this strategy is that it may result in substantially more testers than asking for volunteers. But it accomplishes that by functionally deceiving your players about the fact that they're testing variants, which isn't a policy I endorse, either on moral or pragmatic grounds.
Most of the people that you've tricked into testing for you will never actually deliver any benefits to you. Even among volunteers, only a small percentage of playtesters actually deliver notable feedback (perhaps a tenth, depending on how you recruit). Among people who wouldn't have volunteered, I imagine the percentage will be much lower.
[failed line of thought, don't read]
Maybe limit it to bringing 1 thing with you? But notice this permits "stealing" items from other players, since "being carried" is not a persistent state.
"longer descriptions of the abilities"
I'd like that. That would be a good additional manual page, mostly generated.
If you're imagine having a computer program generate this, I'm not sure how that could work. The purpose is not merely to be verbose, but to act as a FAQ for each specific ability, hopefully providing a direct answer whatever question prompted them to look that ability up.
If you aren't familiar with this practice, maybe take a look at the Dominion rulebook as an example.
That's...not the strategy I would choose for playtesting multiple versions of a game. Consider
I think you misunderstood, I wouldn't write the manual this way after publishing for a broad audience. It's just fine for developers. But there are also some other reasons that stuff is less relevant:
- It's a game about choosing whatever rules make the most sense. Mainly setting laws, rather than game rules, but the mindset transfers.
- Everyone has complete information, and players are generally cooperatively striving towards mutual understanding (rather than away from it), so everyone's assumptions about the game rules are visible, if there's a difference in interpretation, you'll notice it in peoples' choices and you're usually going to want to bring it up.
Speaking as a developer, I would rather have a complete worked-out example as a baseline for my modifications than a box of loose parts.
I do not think that the designer mindset of unilaterally specifying neutral rules to provide a good experience for all players is especially similar to the negotiator mindset of trying to make the deal that will score you the most points.
I haven't played Optimal Weave yet, but my player model predicts that a nontrivial fraction of players are going to try to trick each other during their first game. Also I don't think any hidden info or trickery is required in order for rule disagreements to become an issue.
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.
FYI there are several OTS tools that will programmatically assemble card images based on spreadsheet data, so that you can change common elements (like layout, backgrounds, or icons) in one place and regenerate all cards automatically. Some are free. I think nandeck is the best-known one.
I'm not sure from your description if this is exactly what you're doing, but if you haven't looked into these, you may want to.
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
Yes. Most commercial board games use a manufacturing process called offset printing, which has high fixed costs that render it impractical if you want less than ~1k copies. The Game Crafter is the best-known of several services specializing in small volume. My impression is that they are noticeably lower-quality and have much higher marginal costs, but the low fixed costs make them great for prototyping and for people who just want to make their game available without making a business out of it.
People complain about printing alignment at these services, but from what I've heard, the big commercial printers don't actually give you any tighter guarantees regarding print alignment (IIRC 1/8" is the standard). I think there are a few reasons that people have divergent impressions:
- Professionals know more tricks to disguise alignment errors than amateurs do. For instance, in most commercial board games, you'll find a thick black (or white) border around the front of every card, which you've probably never noticed because it fades into the background; amateurs often fail to replicate this trick.
- It's a stochastic process, and the biggest complaints are from a self-selected group with bad luck. (Also, maybe offset printing is better on average, even if the worst case is similar?)
- I've been told that when it's really important, big publishers will examine the print output and throw away the worst examples at their own cost.
I lack the experience to tell you which card-making tools or small-run print services are best, but send me a message if you'd like a longer list of examples that you could investigate for yourself.
As a former aspiring card-game-designer who's worked at a printing place, something about reading this made smile and feel happy.
Ah, so that's how most people do it. Personally, I can't say that using a spreadsheet would appeal to me more than a programming language, but it might be more approachable for others than installing rust or nix, so I might consider porting in the future.
This looks really interesting, I'd be eager to try an online version if it's not too much trouble to make?
I ordered and also printed it. While doing the cutting and pasting of the cards I found myself wishing that the 'level 2' cards had been considered an 'expansion pack' and separated out so that you didn't need to prepare them all in order to try playing a level 1 game.
I look forward to trying it soon.
1Yeah, the reason they're mixed up us 1) I just didn't think to program it to sort by level 2) Because gamecrafter randomizes the order of the cards. But it would make sense to do that for print and play. I'll file an issue.
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.
However, I regret picking Rust as the programming language:
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:
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.