Great thing about org-mode is that comments and different conflicting ideas can co-exist with rules and playtest data and everything else, all in one plain-text file that is also very easy to navigate and find things in. Using it to organize everything in work/life and particularly game design. But it really blurs the line between what parts of the document are rules (exported to PDF to send others) and what parts are just my private notes.
Start with the rulebook first. Change my mind.
Fri, 08/03/2018 - 09:08
#31
Great thing about org-mode is
Sat, 08/11/2018 - 05:33
#32
Bruno Faidutti just posted
Bruno Faidutti just posted this link to his blog on bgg, and the very first section is about when to write rules. Some good arguments and I think the process he describes is ideal and very similar to what I strive for.
"One of the first things I do when starting to think of a game, sometimes even before making a first prototype, is to write complete rules. These rules are then updated after every playtest session, and numbered like softwares."
Click the link and read the rest of it as well. Well worth reading.
Mon, 08/13/2018 - 09:33
#33
If you don't have the rules,
If you don't have the rules, how can you possibly make a prototype? :)
I'm working up a card game and I'm certainly not making any cards before I know how the gameplay works, in detail. Of course, as I make the cards, I'll come up with rule clarifications, changes, etc.
Wed, 08/15/2018 - 09:56
#34
Personnaly, I think the
Personnaly, I think the rulebook is the key document to game design. It fixes how the game was previously played.
Yes it will be updated many time trought the process and yes you'll take notes on printed rules or digital rules but that is normal.
Updating rules does not take a lot of time compared to building a prototype. Of course, I am talking a very simple text file or word document, not an Adobe illustrator rulebook. That is done at the end.
Else you will just get stuck with a bunch of notes. And trust me if you take a break and come back 3 months later, you'll have no clue how your game worked even with those notes.
Or you'll have worked on so many version of your game, that you will not remember what was the last accepted version of your rules.
Also by fixing your rules, you fix them in time a bit like commits in a Git repository allowing you to trace back changes and the evolution of your game.
You can take for example my first game Fallen Kingdoms, the archives and paper scan are available on in my archives:
http://ha.lariennalibrary.com/index.php?n=BoardGame.BoardGame-FallenKing...
I have 75 megs of annotated rules scan.
Wed, 08/15/2018 - 10:36
#35
larienna wrote:Also by fixing
Also by fixing your rules, you fix them in time a bit like commits in a Git repository allowing you to trace back changes and the evolution of your game.
I get enough Git at work, thank you very much :)
Although, yeah, that would actually be a good idea.
Thu, 08/16/2018 - 00:37
#36
Jay103 wrote:larienna
Also by fixing your rules, you fix them in time a bit like commits in a Git repository allowing you to trace back changes and the evolution of your game.
I get enough Git at work, thank you very much :)
Although, yeah, that would actually be a good idea.
I started out with git to manage early development versions of Trenches of Valor rules (and graphics and historical notes etc) couple of years before first using it at work. Have used it on every boardgame project since (10+ years). Also use it on my big org-mode file where I keep early designs until they are ready to get their own project. Not using branches makes it pretty simple and easy to use git actually. Worst thing is when I have accidentally edited the same file on two computers (more often than I would expect...) and have to resolve the conflicts.
Thu, 08/16/2018 - 11:22
#37
For multi computer syncing,
For multi computer syncing, Unison works well. But I don't think it combines well with git.
