$18.00
GeekGold Bonus for All Supporters: 133.91

7,823 Supporters

$15 min for supporter badge & GeekGold bonus
49.3% of Goal | left

Support:

Recommend
9 
 Thumb up
 Hide
8 Posts

BoardGameGeek» Forums » Board Game Design » Board Game Design

Subject: Organizing Your Game Development rss

Your Tags: Add tags
Popular Tags: [View All]
Channing Jones
Germany
Kleve
flag msg tools
mbmbmbmbmb
Designing a board game is an very iterative process, meaning you will likely be revising your game many, many times. Here are some techniques I found useful to stay organized.


Versioning:
Keep a version number for your rules. I use a system similar to software development:

major.minor[.editing]

with

major: being the major version starting with 1. I go up one number if I make major changes to the game (i.e. almost a completely different game)

minor: starting at 0, whenever a rule changes this number goes up by 1 (numbers above 9 are ok). The first version of my game will be 1.0. It is important that this number changes whenever you change a rule, so that you know playtests with game differing in this number are not necessarily comparable anymore

editing: I initially leave away this third number; whenever I just change the text of the rulebook without changing any rules (or just very minor rule changes, e.g. for extreme edge cases) this number goes up by 1. This means playtests where only this number differs are comparable.

Example: 1.13.2 (still on the first major version of the game, now with the 13th set of rule changes, second time editing latest version on that).


Recording playtests:
I have found it very useful to record some data on every playtest made, at least past the rough prototype stage.
Things I records include:
* Duration of explaining the rules
* Duration of the game
* Rules version
* Number of players
* Who won (which faction, group, side, color)
* Scores
* Remarks (how victory was achieved, anything special that happened)

I usually design a specific form and print it out on paper and put several pages into the prototype box. For every game I play I can then immediately fill out the paper at the end of the game. The specific format is useful because I can quickly record the data that I specifically need right then and there.

I can also use this paper to record any comments and suggestions playtesters make after the game.

This data useful for balancing various components of the game (especially good for asymmetrical games). Also very useful is to know how long the game will last.

Later on I put all this data into a spreadsheet which lets me easily make calculations on the data such as averages.


Changelog:
I also keep a changelog for every set of changes I make to the rules (i.e. when the version number changes). I print out the latest page and put that into the box of my prototype. The useful thing about this is that when I playtest the game later I can just look at that sheet and am reminded about what the latest changes have been to the rules. I can thus be more aware of that during the playtest.

Before I started doing this I sometimes had trouble remembering what I version of the rules I was currently at (because sometimes there were many).

The changes are recorded in reverse version number order (i.e. starting with the highest number and going down).

Here is an example:

------------
Changelog
Puppetmaster Endgame

v3.11
Remove 2 CP from pool if inspected card not revealed when upgrading to Information level.
Adjustment of CP levels needed for FP win.
Pyramids limited to number of players +1.

v3.10
Cost of upgrading to Information level decreased by 1 to 2 AC.

v3.9
“Conqueror” specialization lowers the cost for conquering by 2 AC now.
Finger counting hint.
Starting player power only works starting with the 2nd round.

v3.8
Starting player may stay starting player if he pays 1 AC.
First round: +1 AC if starting in Argentina, Eastern Australia or South Africa, -1 AC if starting in Middle East (replaces rule for these provinces below)

v3.7
Starting player gives starting player marker to other player.
Starting player may look at top card of calamity card deck.
Building pyramid costs 2 AC.
Trade action (get +1/+2 (if lower civ. lvl.) income marker, only 1x per round).
Players who have Argentina, South Africa or Eastern Australia as their only province giving income pay only 1 action counter for the upgrade to the Medieval level.
------------

File organization:
On my computer, I keep a separate directory for each prototype and use the same directory structure below that for every prototype (images, photos, old versions, backup, PDFs, correspondence, etc.). I make a separate backup at the end of the day or for every significant change and store it in zip file with the current date and archive (on another drive and in the cloud). I keep every backup version so I have the possibility to easily go back to an old version if I need to.


Notes files:
For every prototype I keep two text files. One called "IDEAS.txt" where I just collect any and all ideas I might have on the game. Another text file called "TO DO NEXT VERSION.txt" is a reminder (to do list) what I need to do to make the next prototype version (e.g. changing graphics, new printout, changing rules, etc.). I keep it in text file format because it is very easy and quick to edit.
11 
 Thumb up
0.01
 tip
 Hide
  • [+] Dice rolls
Derek H
South Africa
Pretoria
Gauteng
flag msg tools
mbmbmbmbmb
I use the 0.x numbering series to refer to a game that has not been playtested by anyone except me ...
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Carl Qwerty
Canada
flag msg tools
mbmbmbmbmb
That's very thorough. I usually just make quick notes in a notebook, but I can see that being more detailed would be beneficial.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Tim Murray
Canada
flag msg tools
On a related note, do you have a solution to the problem of physical component versions?

I often run into a problem where my new version will require making new components to replace outdated ones. There is, however, always a possibility of the latest iteration being worse / the change I made didn't work / etc. In this case, sometimes it's better to revert back to the last iteration rather than working from the current one.

Problem: I either end up with a CRAPLOAD of old components laying around my house from old versions or I throw them out after doing a new version and I can't revert.

The best solution I've come up with is to only keep the components for the most recent previous version, but that still presents a problem of how to store that old set of components.

I currently have an old version just sitting out on a table making a mess because I have no idea what to do with it!
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Channing Jones
Germany
Kleve
flag msg tools
mbmbmbmbmb
action9000 wrote:
On a related note, do you have a solution to the problem of physical component versions?

I often run into a problem where my new version will require making new components to replace outdated ones. There is, however, always a possibility of the latest iteration being worse / the change I made didn't work / etc. In this case, sometimes it's better to revert back to the last iteration rather than working from the current one.

Problem: I either end up with a CRAPLOAD of old components laying around my house from old versions or I throw them out after doing a new version and I can't revert.

The best solution I've come up with is to only keep the components for the most recent previous version, but that still presents a problem of how to store that old set of components.

I currently have an old version just sitting out on a table making a mess because I have no idea what to do with it!


No, I don't have a good solution for that.

I also often have a lot of old version components. Eventually, when the version becomes really old, I can throw it out. Luckily, it only rarely happens to me that I need to revert to an older version.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Warren Fitzpatrick
United States
Ohio
flag msg tools
mbmbmbmbmb
I'm not sure I understand the problem w/ components. Normally, I don't create the physical assets until well into the game's development. I used popsicle sticks for cards for one project (true story). It didn't have a good look, but it gave the information that I could reference w/ a spreadsheet. This allowed me to change things quickly w/o continuously reinventing the wheel. Slowed things down in terms of playtime but worked until I could upgrade to printed paper with actual ink on it .

Am I misunderstanding the kinds of components being referred to here?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Tim Murray
Canada
flag msg tools
warrenfitz45 wrote:
I'm not sure I understand the problem w/ components. Normally, I don't create the physical assets until well into the game's development. I used popsicle sticks for cards for one project (true story). It didn't have a good look, but it gave the information that I could reference w/ a spreadsheet. This allowed me to change things quickly w/o continuously reinventing the wheel. Slowed things down in terms of playtime but worked until I could upgrade to printed paper with actual ink on it .

Am I misunderstanding the kinds of components being referred to here?



The big one for me is playtesting with friends. I get considerably better results from playtesting early in development if my assets are of somewhat higher quality than scribbled up index cards. I don't go crazy but I do use a printer + ink. I'm still able to white-out things and write on them but the end result is that the majority of my components at least look semi-presentable.

At first this did indeed seem like a waste of time until I got results back from the first playtest where I did this. People tended to give the project more respect and I got considerably better data.

Bottom line, I don't have ideal playtesters to work with in my social group and creating better components lets me overcome that to an extent until I get a game to the point where I can take it to strangers and blind-test it.

I can solo-playtest with index cards and whatnot just fine, but it seems to be in my best interest to step things up a notch when asking others to donate their valuable time to my cause.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Craig M
msg tools
mbmb
You are all more organised than me... I must remember to start a proper versioning system when I move to more widespread playtesting. Currently it is an organic process, where I make changes to the rules document often, but don't distinguish between edits and major mechanic revisions.

Interesting observation about the need for semi-decent components. It makes intuitive sense. I have self playtested with crappy cards etc, but lifted it a notch when getting other people to try it out. It's important not to go too far down the road to nice components, though. No point getting distracted with perfect layout and artwork when things are very likely to change. I have spent far too long designing mats and cards that I ditched completely.

2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Front Page | Welcome | Contact | Privacy Policy | Terms of Service | Advertise | Support BGG | Feeds RSS
Geekdo, BoardGameGeek, the Geekdo logo, and the BoardGameGeek logo are trademarks of BoardGameGeek, LLC.