Start with the rulebook first. Change my mind.

I lack access to playtesters, so all my game designs reach "ready for blind playtest" stage with rules and a print-and-play and sometimes a Vassal module as their first stage in development. (Rules are often critiqued and modified along the way.)

I'm work the same way. Notes, rulebook, whatever you want to call it. Thinking through every aspect of the game helps me think of potential flaws before I even get it to the table, making the first playthrough with others a little more smooth.

Of course I don't bother with diagrams and gameplay examples, that will come much later when I'm working on the final rulebook.

Interesting approach!

Personally I’m more a notepad guy myself as no matter how hard I try my game idea goes through hundreds of options and revisions way before things start to become consistent additions. Although having rules in place early is a good idea as it means you can actively test quicker than concepts. Different approaches I suppose. :)

Nyt.

If you are good with excel, you could start writing rules in there.

Simply work from top to down as if this is your rule book. Only using 1 cell per specific rule. What you get is a column of cells that each contain a rule.

The very first cell above could be the version and date if you like.

If you want to change rules of your rulebook. You can insert an entire column. Give it a new date. Copy/paste those rules that you want to keep. And rewrite the rules that need a change. Maybe even colour the older rules the the previous column with green=ok, orange=changed, red=discarded.

Not only do you change your rules in a orderly fashion. You can keep track of how the rules have been changed in the past. Perhaps you want to go back to another rules that you first had. Or you can easily add columns with try outs. First adding the new or change a rule. And copy paste the rest later in if the few changes plus additional changes where good enough.

Because what if all your "rules" sound good... But when you playtest that game... it's "crap" (sorry for the term but you know what I mean).

I usually find that "Game IDEAS" sound REAL COOL. And you can get lost in the romance of a design UNLESS you "playtest it" FIRST. And that doesn't mean spending days in Illustrator (as I have done in the past), you can BUY blank Poker cards from "The Game Crafter" for $0.09 each ... you can get like 50. And then buy a pack of sleeves for $1.25 (the el-cheapo brand that is visible from both sides).

Next all you need is a Dry-Erase Marker and you're ready to create YOUR prototype... That may take 1 day to figure out all your cards (giving you an example that I would work on).

Lastly you PLAYTEST this "idea" ... because like I said, most Game Ideas seem to be pretty cool... But can be BORING when you make a prototype. Does the idea merit more time to WRITE "rules" or not?!

So I would say, that you need a PROTOTYPE "first" and then if it's moderately GOOD, then you can write down rules... But I would probably still wait, I would use Excel to copy the design from "prototype" to some kind of reference doc (in Excel) and then work on a prototype in Ilustrator...

I would do all of this BEFORE writing down rules. But that's my process, I understand everyone is different.

Cheers!

Note: I also write down notes for the game too... Like the components, and basic gameplay ideas, turns, etc... But that in my book is still not a "rulebook". Rulebooks have a specific FORMAT to follow (Victory Conditions, Turn Sequence, Combat, etc.) My notes are usually just paragraphs of text "resuming" the general idea of how the game is to be played.

And once I have my Excel, I have a referencing document too... That I can refer to giving the many iterations that my designs go through...

Note #2: I'm in the category of "Fail-Fast" prototyping until you have something which is sufficiently "fleshed-out" that it has enough depth to the game and it's something worthwhile to continue developing/designing.

Because EVENTUALLY you will NEED a "Rulebook" for "Blind Playtesting"... This is an important step in any design/product/game. Without it, you can't be certain that your rules are comprehensible by gamers who have never seen or played the game.

"Rule-book first" sounds like a great way to waste a lot of time.

Minimize the time between the idea and a first raw concept-proof prototype as much as possible.

I don't remember any of my games at all that would survive the first play-test without some major changes from the original idea.

Taking notes is a different thing though. I would normally use a google sheet to note down things like turn structure and what not. It's not a rule-book though.

At this stage I don't bother about proper wording, formatting, potential ambiguities etc. All that's required from the notes is that I myself understand them. This is the opposite of what a rule-book is.

Take a few lines of notes down, maybe a working title - and get to testing.

Obviously you shouldn't be doing formatting.

But you should be writing everything down.

And, after the very first proof-of-concept play, you should be thinking about the ordering of the rules to make sense to players (see my comments on that new Chesslike thing from a week or two ago). If playtesters aren't testing the same game you think you made, it's not going to do you any good. And having the rules written clearly makes it much easier for you to spot places where there are exceptions, holes, contradictions, etc.

Speaking of which, I just finished the full formatting on my 24-page campaign book, and I'm tackling the real rulebook (which has little icons and whatnot sprinkled around) next.

The difference between my process now (no local playtesters) and back in the 70s is one of playtesting.

------------
Back then, my old space wargame board was markers on a (3 inch hexes) vinyl sheet and chits were hand cutout blanks with felt tip pen markings and rules were a few handwritten sheets when it got playtested with people I saw every fri-sat at the local game store.

After that the rules were redone in an organized format and examples added.
------
Now, with no local playtesters, I run through it all myself multiple times from various angles and then organize the notes into what makes sense to me as a rulebook and put together a basic PnP version and sometimes a Vassal module.

Then the whole thing gets slapped around in several forums until the rules make sense to other people to get them into blind playtest ready state.
------------

There is a big difference between "ready to playtest" and "ready for blind playtest" rules.

But if you have the playtest capability, test the mechanics and fun as early in the process as possible once you think the rules are ready (provided you are there to explain them).

I completely agree with your post. Be assured I wasn't quibbling over anything you wrote. :)

Mine was a response to Questccg's. And I would add for clarity with regards to that, I didn't imply a rule must be good if it looks good on paper. Playtesting will alone will tell. But I certainly think a rule (or system of rules) might feel good in your head, where it has probably been incubating for months and where it seems perfectly logical, intuitive and consistent, only to become much less attractive when you actually bring it into the light of day - whether by explaining it to a playtesting relative or articulating it in a Microsoft document.

I can see writing the rule book first as a good way to catch mistakes over a long period of time, but mainly I'm mentally theorycrafting and explaining theorycrafted rules for play tests (internal not blind) for a very long time before putting anything on paper. That's partly because until the mechanics are frozen in place, it is just a ton of revisions that are not worth updating word files over and rule books for me are a chore, even with the games I purchase. Much easier to update brain files, but there is something to be said for having something early on that can evolve (hopefully for the better) over time.

Someone posted their "thoughts" on a "cool mechanic" which involved ROTATING cards by 90 degrees. Each side of the card would have a stat and one would be some kind of "special ability".

Reading this, I thought: "Hmm... that sounds super interesting. I can picture rotating the cards to the stats that I want, etc."

So I decided to TRY this mechanic just to see if it's as cool as I thought it might be...

Well ... it wasn't.

Firstly because you rotate ONE (1) card means you have to counter-balance with rotating a second (2nd) card. Because you could not have, for example, two cards with a "Strength" value. So if you had 4 cards, you would need to rotate 2 each time.

Well the dynamism of the mechanic (because you needed to rotate 2 cards) just fell flat because it wasn't all that it was supposed to be.

That's one example. And in my own designs there are a ton of games that I've shelved, re-worked, shelved again, etc. Each game has SOME merit... but as a "whole" it doesn't work. So when I get fresh ideas for one of the designs, it's back to playtesting to see if it's a good idea (is this next iteration of that design worthy of more attention)...

So for me to write out all those "temporary" ideas would just be a lot of time figuring out details that I'm not even sure that they make sense together. That's why I use Notepad++ to jot down some details... but I avoid writing "precise" rules until AFTER I have determined "how much I like or dislike the design in question"!

https://boardgamegeek.com/thread/1018707/brief-crash-course-game-design-...

With particular reference to point 2 C.

I also recall the blog of a successful game designer (sadly, I forget who now) which described the difficult decision to cut out a whole rule or set of rules because, although they DID make for a better game, it turned out that they weren't worth the extra load in the rule book.

In other words, they were good mechanically but proved too cumbersome in the execution as written rules to justify their existence.

Good to catch those problematic rules earlier rather than later if there's any doubt. And there's only one way to do that.

I'm not advocating writing the rulebook before any playtesting takes place. Not one bit. But I did see an interesting aspect of the OPs approach - which is that there ARE certain advantages to writing out particular rules to see how they look/ read on paper. There might be a compromise to be made, and it strikes me, as a person with no design experience to speak of, that it would be as well to realise early so that the rest of the game can accommodate it harmoniously.

In a word, "audience." Notes are for you or your fellow designers. A rulebook is for the public. As for my first game idea, I started with notes, and that's evolving into a rulebook with embedded notes.

I have highlighted regions which are brainstorming ideas, potential opportunities to balance and evolve the design, links to related documents like spreadsheets and pnp files, etc.

I find the layout and organization of a rulebook to be helpful to organize things. I have a separate document that's full of random thoughts and links relevant to the project, but it's harder to find anything in that jumbled mess. I put "the good stuff" in the prototype rulebook both so it gets more eyes on it and also so I don't forget it.

Speaking of audience, a prototype rulebook (or snippets of it) could be used as a sell sheet of sorts as you start to recruit playtesters. At the top of mine, I have a 2-short-paragraph summary that I refine and evolve over time. If anyone asks what my game is, I can paste that summary instead of having to come up with something on the fly. If they're interested, I send them this prototype rulebook so they can learn a bit about the game before they begin, or they can refer to it during gameplay.

I use a WORD document instead of a Google Docs, but that's just personal preference ;)

When I get a game idea, first it percolates for a bit but if I have pen and paper handy, I write "New Game Idea" at the top of the page and the date and then start writing about what I envision. There are rules in there, but also notes about what the board looks like and how the players will interact and what I want to be attractive about the game.

Nailing down the rules happens naturally as the game goes through the design process, and man it takes a long time to edit and make perfect.