Making a mechanic database

I just made a quick look at access. It seems that I could export data to XML and then make my wiki read XML. It's still not changeable from the web. So either I need something which could add data to an XML file or constantly export my database on the web (but be the only one to be able to edit).

Installing mysql is out of the way since it's too big. unless there is a small limited mysql compatible database which I could install. Still the XML solution above might not be too bad since maybe I could allow users to be able to add comments to pages without giving access to anything else.

Like one of my friend said, this database would have a very limited audience. So making money out of it would be really hard.

Of course if I do everything, it will be very time consuming (which I don't have much). As a community project it would be better but I must make sure that the structure of the database will always make sure that the data stay sorted correctly. I thought for example that people could submit new keyword index, but I would need to pass behind to normalize the keywords and create proper redirections.

On the other hand, I could just make a basic classification scheme layout and make people submit their mechanics or variant as they want. It could get a bit chaotic and maybe the information will be harder to find but at least there will be a lot of content. People would index their mechanics by themselves to it could lead to duplication. But if there is hyper text searching on the whole website, like in a wiki, it might not be too complicated to find the information.

Still, do you think it is worth the effort? Will people really benefit from it during their game design?

It also seems I'll have to check what BGG has to offer on their website.

For the first link, it seems to be a wiki page own by the website itself? Can I create wiki pages on BGG.

For the 2nd link, yes there seems to be a good bunch of mechanics categories. But what If I want to make my own category scheme. Of course, I could get inspiration from these categories to build the initial classification scheme.

By the way, I know it's possible to access BGG data directly by an external application or web site. For example: NAND to BGG software download your game list and makes cards with it. So is there an open interface on BGG to easily transfer data between applications or web site in order to increase the connectivity.

I don't mind doing the classification of the mechanics because I really don't like those on BGG. Some of the listed mechanics are either to narrow or too wide or they are simply not mechanics. For example:

Hex-and-Counter & Modular Board : I don't consider these to be mechanics, but rather board design. Because there is no rules attached to it. Using an hex map in your games does not tell you anything on how it works. I don't mind having a separate section about all kind of board design that exist.

Simulation: This is not a mechanic, it's a type of game.

Paper-and-Penci: This is a component used in the game, almost any mechanic can use pen and paper.

Roll and Move: This is an application of mechanic called "Randomness". It use a component called dice and use it for movement.

So this is why I wanted to create a better structure for the mechanics. The easiest way to do it is with an tree of categories which could be maybe 2 or 3 levels deep.

OR

I could also make a facet classification system which consist in combining different categories. For example, to classify clothes, you could do it by 3 attributes: the shape, the color and the fabric. So you could end up with a

"robe, red, cotton"
"skirt, green, silk".

But if I consider that I want to group by clothes by color first, I'll place the color facet in priority to the others which gives:

"red, robe, cotton"
"green, skirt, silk"

So if we could determine different aspect in a mechanic, we could create a faceted classification system. Still, I though I could use the components in the classification system to realize that the components has almost nothing to do with the mechanics. For example, you can do an auction with cards, money, tokens, etc. Even the "randomness" mechanics can be done with dice, cards, cube tower, etc. So the components might not be a good facet. Here are some raw ideas, it's not the best thing I've done:

Objective/application: Conflict resolution, price/value, movement,
Method: Random, strategic, determinist (cannot change result), esthetic (ex: acting, modeling)

Now, according to how the classification system works, there might be a need or not to do some indexing. If you can do a search in the content text of the mechanic, it might not be interesting to create an index even if it use free vocabulary. So for example, you could have fields with pro and cons, effect, most common components used, etc. Then if you search for one of these words, you might find the entry. Still, 2 different person could "index" the same concept with a different word. But when we will start using it, we will see if there is a lot of noise or silence that comes out of the search.

As for a way of using it, I think that if everybody which has an account can add consistent stuff to the database, then it will share the work among the users. There must not be some comments/discussion in the database to keep the value of the information high.

We will have to make sure that there is no duplications of mechanics in the database. So either submitting a new mechanic needs to be approved by some admin and maybe get classified at the right place. And use can post additional variants, pros and cons, etc. It depends what is the ration of mechanics VS mechanic variants and it depends how do you cross the line between both of these concept.

If we end up with few mechanics but lot of variants, I would not mind classify them myself to keep the data structure. If it's the opposite, I might not be able to. If there is fewer mechanics, it will be easier to move them around if there is a change in the class

When creating a classification scheme, you generally need basic data to work with. Right now, according to BGG, I rated/played 171 games. So I could take each of these games, strip down the mechanics. If will give be a base of information I could build my classification scheme. Then it will be open to add variant and mechanics. But I can't make a classification scheme if I have no sample data.

Maybe it's just the way I named it which is wrong. For example, rolling 1D6 or playing cards with a value range from 1 to 6 is actually the same mechanics: you pull out a random value between 1 and 6. It just use different components, so they are both variants of the same mechanics. So that's why I said "randomness".

Still that might be a bad point of view and both mechanics above could be seen as 2 different mechanics rather than 2 variants of the same mechanics. So maybe the components could have more weight in the classification scheme. It's also an example that shows why you need to set a line between a variant or a mechanic.

Anyways, like I said, I really need to work with real data so that I can make some regrouping of mechanics that looks alike.

This is why I thought it could be easier to start with a component database. It's much more clearer than a mechanic because a mechanic is just a different point of view at using things. Components are physical elements so they are easier to define.

For example: a card is a card: it has a size, a certain amount of information by text icon and color. But the number of way it can be used is really large because you can even use it in a dexterity game.

From what I know, there are not any. The problem is that organizing all the information seems very complication because there could be millions of variations to the same mechanic. If the information is not organized then finding the information you need would be too hard to find. This is why I am not sure if it's really a good idea to build one.