Making a mechanic database

I have been thinking and mechanics might indirectly be discussed while describing components but it might not be done as systematically than component description.

For example, if you talk about dice colors, I could say that one of the use, like in a dungeon quest variant, is to assign a die of each color for each character stats. So that when you roll the dice, you know which die must be compared with which stats.

This is indeed an expanple of mechanic that can be used with dice color. The subject of the "page" would be about dice properties which is color with an example of how it can be used. But it will not systematically list all the possible use of dice colors. But it will list all the properties of a die.

Maybe that could make more sense now.

I think the organisation would be to define components caterogies, then make a page for each property of that component. For example

Dice
- Nb Face
- Color
- Face content

No problem, like I explained above, it will indirectly talk about mechanics. We might talk for example that a kind of information that can be found on cards are connection paths like in Hacker and illuminati. IN that case, you are indirectly describing a mechaninc

I think in order to start we need to do an inventory of components. The best solution would be for me to take my closet (I have around 80 games), list everything I see. Do the same on your side, then we fusion the list and create groups of components. Once this is done we could start building the scheme and the website.

They are easy to setup. In an hour, I can install the wiki, do the basic configuration and write a bit of content structure. I'll need another hour or two to change the CSS to alter the look of the website (colors, layout, etc).

Then we should be ready to start. We might need to make some page formating guide lines to present the various components and their properties.

I personally use Pmwiki for all my websites with various skins. You can have some example on my websites, here is the hub:

http://lariennalibrary.com

I think the description should include what we can see.

For example, yes cards can be thin, thick, double sided, shape (square, rectangle).

But there are other things on cards that we can see which are in between mechanic and components. For example:

Edges: Some cards have information on the edge allowing you to only use the edge (ex: glory to rome)

Rotation: Some cards have information placed in various direction to rotate them.

Connections: Illumination and hacker connect cards with each other which offer different game play.

Colors and Suites: Use in regular card game and magic the gathering for various purposes.

Double Cards: Battlegroup and certain MTG cards has 2 distinct cards displayed on the same cards.

-----------------------------------

So as you can see all the example above are all placed on cards, and they do not change anything on the size of the cards, but they are things that we can actually see on the cards that offer various ways to use those cards by displaying the information differently.

So I think in the end we will end up in a Component + Mechanic hybrid description, but at least the components will be done more systematically, but not the mechanics.

Else let me start my collection, I'll see how it ends up and I could give you an example of what it could look like.

-----------------------------------

For more information about pmwiki, see:

http://www.pmwiki.org/

I don't mind using another wiki. I know I had some trouble with user account management last time, but since it's a semi open wiki, it could not be much a problem. Else we could make it open but make changes approvable by an admin before beign added to the website. If there is a low amount of contributors, it should not be much of a problem.

There are various layouts available for PMwiki, here is the list of skins available:

http://www.pmwiki.org/wiki/Skins/Skins

Things to check, are

- Number of columns: I prefer 2 columns than 3 columns
- Fixed vs variable width: Fixed website are easier to predict the output layout than variable because you don't know the screen resolution of the user.
- Content layout: See how headers and tables are displayed for example.
- Quality: Some are better looking, easier to work with, easier to modify. It's not that easy to see.

Colors can be easily changed by manually editing the CSS. Layout is a bit more complicated and can lead to a few bugs since I am not enough familiar with CSS. So far I have used the follwoing skins:

Sinorca
Green
Drop Shadow
BlueBerry

If you see anything else you like, let me know.

I'll try describing a few games as examples.

Hmm! interesting

For example, I thought that in Eclipse, you can have board and sheets where there is a place holder to have a component.

For example, a square space to place a tile, a cube, a disk, etc.

But those "placeholder" could also be found on other componnents like cards, tiles, etc.

So yes, we need to decompose, but not necessarily attach it to a specific type of components.

So now it does seem to expand the amount of things to classify other than having a few large class of 3d, 2d and electronic components.

-------------------------------------------

I think the basic rule for adding it or not to our description list is if it can be seen. So What-We-See-Is-What-You-Get.

I am going to try describing a few games, list what I see and not attach it to any physical components. See what I can end up with and start making groups.

It's true that we might end up with a class contating everything drawn on components like text, Lines, shapes, etc.

I have made 3 games so far, here is a quick idea of how the description could be made (I taken pictures too):

Board Game Deisgn Database
Preliminary Inventory of Board Game Components

Criterias
- Must be Visible
- Must have an Impact on Gameplay

__Typhoon over the Pacific__
- Map: Foldable on paper
- Geography: Geographical informaiton as a drawing
- Mount: Paper, Card board, wood, plastic,
- Grids: containing information
- Containers: drawn shape which space to place components
- Icons: Identifies concept in a specific location
- Arrows, connections: Allow to connect 2 areas together
- Writtings: Letters, name, number, information
- Track: Container used to move components to keep track of a value.
- Legend: Display the meaning of colors and icons
- Sections: Area split in various sub sections to subdivide space
- Token:
- Flag: Identifies a country, like an icon
- Code icon: ex: X for infantry, oval for panzer
- Code Letters: ex: BB= Battleship, CV= Carrier, etc.
- Pictures or drawing for thematic references
- Shapes: Use of circles, squares and other shapes around numbers to mark different information
- Color: Place number of various colors to have different meanings
- Rule booklet
- Double Sided tokens or other

__Labyrinthe__
- Container box: in card board or other materials
- Cards
- Pictures
- Tiles
- Connections with corridors
- Pawns
- Color: Identifies players in this case
- Board: Floadable on cardboard
- Attached components: Tiles are attached on the board.

__From Collar to crown__
- Cardboard box (container)
- Plastic Tray
- Dice with pips
- 3D miniature: A shield and 2 swords
- Cards
- Picture/Drawing/Painting
- Text: Name
- Values
- Sheet (Containing Refence Information)\
- Instruction Booklet
- Some double sided cards

I have to go

About the list, it's true that it will be important to avoid ambiguity. For example, what is the difference between a tile, a token and a small board, well the tilability of the component make a tile a tile.

So we could try making a standard glossary and try to remove ambiguity. It's just that I am not sure we have enough authority yet to make it widely accepted. I think we will have to make a glossary of commonly used terms, but for our classification scheme, use rigourous terms.

------------------------------

About database, I say we do it by steps: First we go strictly to component physical construction, second we could talk about things put or printed on components, and finally we could extend to mechanics. But at least, we would be able to put a basic structure to work on. I don't mind adding glossaries or accessory content related to board games.

PMwiki works with groups of pages or orphan pages. A group basically hold the "root" page and sub-pages. There are no limit to the amount of pages. It's also possible to treat a group as a thread of pages (jump from 1 page to another.

I suggest we make a "root" page for each component type (card, tile, pawn, etc). Then we can create an infinity of sub-pages regarding that component (color, layout, icons, etc)

-----------------------------------

So you want me to continue making an inventory of my game to pull out the most possible components list (step 1) and then try to create a classification scheme together?

Or do you want me to setup already a web site. I think it should be better when the basic component scheme would be defined since we will have some content to add.

-----------------------------------

Though of any names?

Board Game Design Database!?

It seems strictly dedicated to board games and not game design in general so the word "Board" seems essential. Else it could be an acronym, or a fiction name.

I am managing tons of projects right now, and I have just moved to a new appartment, so I have a lot of work to do all the time.

For the name, instead of "database", we could use a more "librarian" keyword like "Encyclopedia" for example.

I'll continue making inventories but stick to physical description only.