Documenting a game

[Peyrol]

I am considering developing for BGA an abstract two player game called Lazo. In my opinion as the inventor, the rules seem fairly straightforward, but there is an underlying concept which players must understand in order to play and enjoy the game. This concept, the object of the game, can be difficult to convey well to a new player. A plain text file would be insufficient to effectively get my message across. At the very least, I need to make a document which is richly illustrated and formatted. I should provide both a pdf file and an html document, probably with style sheets. Even better than that would be a video that explains the rules, and perhaps other videos which explain basic tactical ideas. Maybe I could even make an interactive Javascript page which shows some positions and asks the user to determine whether the player to move has an immediate win, and if so, where is the winning move. When they click on an answer, they would be told if they are right or wrong.

For those who are geometrically inclined, here is a brief sketch of Lazo. The game is played with specially shaped dark versus light tiles which have pegs on their undersides that fit into holes on the board surface. The grid of holes is hexagonal; interior holes on the board are adjacent to six neighbors. When the tiles are placed on the board, they fit together like hexagons, although their shape is more complicated than that. Three mutually adjacent tiles on the board either share a mutual vertex, or they form a hole between them which is the same as the holes on the board. Tiles can stack like cannonballs in a 3-dimensional lattice. The object seems simple, form a loop made of your color tiles and possibly the board surface. (Lazo is Spanish for loop.) But here's the catch: This loop must have a hole in it which a lattice path must pass completely through. This "hole path" must consist of tiles or lattice spaces, each adjacent to the next, which does not contain any of your color tiles, and is distinct and separate from your loop path.

The problem is, many positions may look like winning loops, but are not, and many winning loops may not be easy to recognize. So I need to explain my terms clearly and provide plenty of examples. My question is, what sort of standards should my help file conform to? What size should the diagrams be, how long should each page be, how many pages long should the entire document be, what other restrictions should I observe?

Thanks for your time.

how the tiles stack, upside down tile placed off the board

Cameron3LowRes_gimped.png (128.84 KiB) Viewed 2346 times

[Jest Phulin]

The majority of gaming still takes place in the physical world. Your game instructions will need to conform to that standard -- IE, you will need an instruction book. If someone opens a box with a board and one type of piece (of of two colors), and a 50 page instruction booklet, they will probably think something is amiss. You might want to figure out how to explain it first, and worry about help files later.

[Peyrol]

Of course, a published game set would need an instruction booklet. Are you saying I would need to get my game published before it would be accepted here on BGA?

"If someone opens a box with a board and one type of piece (of of two colors), and a 50 page instruction booklet, they will probably think something is amiss." Could you please spell out for me what point you are making? 50 pages is too long, perhaps? I completely agree.

I see a sort of slide show format is used for much of the documentation here. Perhaps I could use that format? I will try to use less than 50 slides.

[Jest Phulin]

No, I'm definitely not saying that it must be published before BGA will accept it. At least, I don't think so -- I'm not BGA staff, so my word isn't final.

What I am saying, though, is that printed instructions will most likely be an eventual goal. Rather than trying to format the instructions and concept of the game you have now into an electronic form and then later making them into a concise print form, you might consider making the concise print form first, and then take that set of instructions and making them electronic. You will most likely then end up with a concise electronic form.

[Peyrol]

So, if my first version of the rules is a help file for BGA, I might blather unnecessarily, whereas if my first version is a pdf file for a printable booklet, I would more likely be concise? I appreciate your concern, but I don't see why that would be the case, especially if I use the slide show format. There's not a whole lot of room on each slide for me to communicate. It's a lot less room than I would have on a 1200 dot per inch page of a booklet. I can't fill up a slide with clutter; each slide must clearly present one concept, or at most two. And I probably would have to keep the slide show to 32 slides or less. That's pretty restrictive as far as I can tell. Not much blather space available. Anyway, I do already have a printable version of the rules. It's not the final version, but I worked out how to keep it all within about 12 pages, each 7"x8.5".

My original question was not how should I create my rules. My question was, what format should I use, what guidelines should I follow for my documentation? There are guidelines for writing the code. How about guidelines for documentation? Is the slide show format acceptable? What are the restrictions on that format? This is not just for the public. A slide show presentation might be the best way for me to pitch my game to the BGA admins. I appreciate any clue.