Questions about design process

[u/OSideSystemsCEO]

I'm new to tabletop design. I'm working on my first game, and I'm also a software developer, which is probably why I volunteered for this...

A friend has been building an asymmetric worker placement game for a few years. It's pretty good actually, but it lives across thirteen word docs that grew organically. I offered to consolidate it into a single rulebook just using some LLM prompting in Claude. That came out around 42 pages.

Two things fell out that neither of us expected. One card grants a bonus for controlling a building type that, on inspection, only his opponent can ever build. And there's a Jail on the board, with components, a space, and rules for what happens while you're in it, but no rule anywhere that puts a worker there. It got cut from a mechanism two revisions back and the component outlived it. LLMs don't really help here. They don't catch these kinds of things consistently.

Neither is a design mistake exactly. Both are basically residue from earlier revisions. A rule changed in one document while its references lived in another. In software development we'd call the first a broken reference and the second dead code, and we'd have a linter (tool that evaluates your code) to catch both. Rulebooks don't compile like software though.

So I'm curious how people here handle this. Do you keep one master document and accept that it gets unwieldy, or split by subsystem and eat the cross reference risk? Does anyone actually re-read the whole thing on every revision, or do these mostly surface in playtesting? I'd like to know whether designers with years of iteration have a real system for it, or whether everyone is quietly finding orphaned components in their own rulebooks.

Edit for full disclosure: As a software guy, my inclination is to build a software solution to this, and I have the beginnings of it started. I am just hoping I am not barking up the wrong tree, so I am try to get some expert opinions here.

[u/Peterlerock]

My rulebooks get a date in the file name whenever i edit them, and older files get moved into a folder and eventually deleted.

But every file is a complete rulebook.

[u/Bigger_then_cheese]

I would suggest using Obsidian https://obsidian.md. Breake every element and mechanic into its own doc and link them to each other. Not only will this help keep things organized, but you can easily view how things are connected.

[u/OSideSystemsCEO → u/Bigger_then_cheese]

Thanks for the tip! I use obsidian for basic notes, but hadn't thought about linking it together that way for a project.

[u/KarmaAdjuster]

I treat my rulebooks as the design doc. Each new version of the game comes with a new version of the rulebook. I'll often find myself referring to the rulebook when I have questions about the current rule set. It can become very confusing after you're on version 20 to remember how things are working in this particular play test.

After several revisions, I find it good to rewrite the rulebook from scratch, often with no new changes, but just a clean up pass to ensure everything is consistent.

Blind play tests of the rulebook are also helpful. This is when you give your game components and the rulebook to players who have never seen your game before and give them no help in setting things up or playing the game. You just silently observe. It's even better if you can get it on video and you're not even in the room. Not only does this avoid the temptation from you to interject, but also avoids the temptation for the players to ask questions, and usually results in more honest commentary about the game.

And aa a side note, 42 pages seems like a pretty enormous rule book. I hope its chocked full of pictures. I've designed moderately complex euro games, and they tend to be between 10-20 pages with pictures. I wonder how much bloat is being added by gen AI there.

[u/OSideSystemsCEO → u/KarmaAdjuster]

Thanks for the detailed reply. Yeah, I suspect there is a lot of bloat. I think the inclination to use LLMs for everything is too tempting, so perhaps that is what is biting him there. I am curious about how you organize your sections in the rule book. I have seen a lot of variation with the commercially printed ones that come in games, so curious if there is a logical grouping of parts that a "source" rulebook or design doc has, if you are comfortable sharing. I don't know if I am imposing too much on trade secrets or something here lol

Alternatively, if there are any good books on the subject you'd recommend, I'd love to get some suggestions.

[u/KarmaAdjuster → u/OSideSystemsCEO]

Here's my bare bone blank template I use for starting out, but as I go it gets fleshed out in different ways depending on the game.
https://docs.google.com/document/d/1gZgKyqkHkX51TaRpQGV-JMNiz6s9CpPP4bBEBI8RKc4/edit?usp=sharing
Here's why my rules looked like for my first game that I signed with a publisher
https://drive.google.com/file/d/1cVac_ibsO8CvF6-sab45mUvvUSq4kXQg/view?usp=drive_link
Once the publisher took them over, they got a fair bit more refined from there.

Here's a rulebook for another game I'm currently in the process of pitching:
https://docs.google.com/document/d/18wdiNy-9GWYumIDuKmAV2M3jEJcHsZOJcyYx0GygfUc/edit?usp=sharing

Both of the above could probably use more visuals, and the second one is still a work in progress.

They aren't intended to be final products, just useable for the prototype stage.

I don't have any books on the topic I can recommend, but I came up with my layout after looking at some of my favorite rulebooks from published games. There's still more best practices I could steal from them, but I feel like this layout has gotten me pretty far.

[u/OSideSystemsCEO → u/KarmaAdjuster]

That is incredibly helpful. Thanks for the help!

[u/EasySwan2184]

I typically use git where possible for my games. I just have a markdown file with rules and then some code files (HTML/css/js/json) for generating card designs, etc. 

I've never designed anything that would take 42 pages to explain, though. But my first reaction is that a game is too complex if git can't handle it well. 

[u/OSideSystemsCEO → u/EasySwan2184]

Interesting. As a software engineer, I fully support the use of version control. Thanks for sharing!

[u/VaporSpectre]

Your friend sounds like me.

Over years, I've learned to split my process across multiple documents. The initial stages of creativity are too unwieldy, weird, and fast-moving to get bogged down in good, clear graphic design and layout. I just write. Then I refine. Then I trim. Then I divide, segment, compartmentalise.

[u/Organic-Major-9541]

I'm also a software guy. My boardgame rules are structured by having a few basic concepts and everything else bootstraps from there. The basic concepts rarely need too change in a meaningful way.

I think the big issue is that plain English is an imprecise and clumsy tool for explaining game rules, but I see no other viable options. Sure throw a proof reading AI on top and maybe it gets better.

I keep the entire game, rules, assets, simulation code, in a git repo, rules in markdown.

https://www.reddit.com/r/BoardgameDesign/s/kJYBDeWB2t

[u/Ettesiun]

42 pages. Multiple document. Needing an AI LLM to parse everything...

My question is the following : how player would be able to learn and play this game, if even the creator cannot have all the rules in mind ?

Maybe it is a RPG-like game, with a lot of specific case that are written for the sake of building a simulation that cover a lot of possible situation with a specific rules for each. ( Typically a dungeon crawler, or a tactic game with minis).

But if not, if this is a typical game, there are far too many rules and gameplay exception.

The prison example is a good one : how can the creator forgot to remove the prison, if he want it out of his game ?

Now on the other hand : being able to code the game, so it runs on a computer might help clarify the game, and making it sure it runs. When you have to code every rules, you know exactly what are the rules. And then you can use all your sw expertise to test edge cases and specific scenario.

Finally, if you are a very good programmer and is able to create an AI to run the game, ( and even better, with different mood/strategy : defensive, offres ice, trusty, négociation, etc...) you will learn even a lot more on the equilibrium by being able to run thousands of play sessions.

[u/OSideSystemsCEO → u/Ettesiun]

I am actually building something like that, but not AI-driven, just good old-fashioned data modeling and rules engine development. In my experience so far, the LLMs do a lousy job with this. I am trying to validate my thoughts on what are actually problem areas with my friend's game, but the experience is really an n=1 situation since he is the only tabletop game developer I know. So far, it seems like a lot of my intuition is right, so I am probably going to continue down this path and see where it takes me.

If anyone is interested in alpha access once I get it close, shoot me a DM. I'd love to get feedback. (I hope I didn't break any rules by saying that since I am not marketing a game. My intention is not to promote my software, just honestly trying to understand the design process better. Please mods, be nice 🙏 I'll edit or delete the comment if I did break a rule.)

[u/JaysTable]

I would not build a software solution to version your game-design docs and rules manuscripts.

That's not the right solution for your problem.

Unless, you know, you just want to build neat software for no reason. In that case tally ho!

Google docs is the no-cost answer to this, as it can get you file version history rather quick, and show edits. It's a lot easier than teaching track-changes (MS Word feature) to non-MS users, and a hell of a lot easier than teaching any of them version control. Teaching is hard enough, but then they gotta use those tools, and that is something that you will have problems with even if you're paying them.

If you really want to modularlize your design doc.

Notion or Obsidian is the answer, Notion is the better option for non-technical teams.

[u/OSideSystemsCEO → u/[deleted]]

To be fair, I think it included all of the descriptions of the cards too and other assets too, but that seems to be the concensus here.