Skip to Content

Making a mechanic database

83 replies [Last post]
larienna
larienna's picture
Offline
Joined: 07/28/2008

It's just an idea I got like that. I am not sure it could be very useful. It seems that most of the time, when I design a game, I am always shopping for a mechanic to add to a game. Since I have a limited memory I sometimes forget mechanics I already have seen in games I played.

So I thought that I could create a database containing all the game mechanics I have seen so far in order to make mechanic shopping easier or to create new mechanics by combining ideas.

Of course, the information would have to be classified in certain way to make it easier to find. There will probably be sometimes a base mechanic with some variants (ex: auction: Blind, one bid, open, etc).

I am not sure if by doing something like this it would really pay off in the end. Don't want to place time of something which would not help me. Of course, if I do it, I would probably put it on the internet to make sure other people could benefit from it or maybe add to it (as long as the content stays classified).

So what do you think?

Addiso
Addiso's picture
Offline
Joined: 07/27/2008
Should be a community project!

I really think it would be a really usefull resource. It could be a community project with you or someone else here coordinating the effort. You should have a chat with KrinkleChip who's doing his Mechanics of the Day blog entries.

the database entries should contain something like this:

- mechanics name
- short description of the mechanics
- examples of usage in games / themes usually associated with it
- link to related mechanics or variations
....

Gogolski
Gogolski's picture
Offline
Joined: 07/28/2008
A good structured database

A good structured database could be a wonderfull resource. Most mechanics have submechanics, and forgetting some of those is where someone can get blocked in tweaking his design...

Example from games I own:

Bidding.

* blind/open
* one round/continue till everybody passed
* fixed amount to raise the bid/raise the bid however much you like
* recuperate your bid if you pass/recuperate your last raise of the bid (and loose the previous bids)
* waited bidding (players bid something, but their bid is multiplied by another game-stat)
* ... (sure there's a bunch of others)

Each of these submechanics of bidding has it's own consequences and dictates a style of play (more or less), but switching to another submechanic, can make for a very different game, while it is all still bidding...

A very good idea. It will certainly make for very nice and interesting content for the BGDF-article pages/wike/whatever-these-pages-are-called-now. If they link to example games on BGG, it wont probably very hard to find the actual rules and see how the mechanic is implemented in certain games.

I've seen the "mechanic a day" posts, but I think a day is a bit short to sort out most of the subs of some mechanics...

Cheese!

larienna
larienna's picture
Offline
Joined: 07/28/2008
trust me ... I am a librarian (^_^)

Since I am a librarian, creating a classification scheme and an indexing system is not a problem.

First I thought of classifying by objective of the mechanic to finally realize that the same mechanic can have multiple objectives.

Ex: auction can be used to resolve a conflict or determine the value of something. Dice can be used to resolve a conflict and maybe determine movement range.

So there will be the classification scheme, which I am not sure yet on what it will base it self. Once thing for sure, each mechanic must have only 1 possible spot in the scheme.

Then I though of adding index keywords according to different point of view:

Objective: Conflict resolution, time limit, movement, etc.
Components: Cards, dice, token, pawn, etc.

So if for example, you want cards in your game, you can search for the keyword "card" in the component index and you'll find all mechanics which can use cards.

Each mechanic and variant would have information related to it. Like how many players does it affect, what kind of effect it will have on the game, etc.

For the technical point of view, I like Access a lot when it consist of database. I know that access can make web pages but I have not explored the software yet. I am not sure what kind of product I could do with it. There might be a CMS that could do a better job, if any of you know any, just tell me. Recently I have learned how to use PMwiki, since it's in PHP, maybe I could easily make a plug in to manage data OR maybe there is already one I would need to check.

I am also not sure if the database should be completely open to everybody for adding new entries considering that it needs to be classified. So there need to be some order to be kept. Maybe I could leave some elements which could be modified or commented by the user. Ex: a user comment a mechanic he likes or he had used in his game.

larienna
larienna's picture
Offline
Joined: 07/28/2008
About database software

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.

bluesea
bluesea's picture
Offline
Joined: 07/28/2008
Allow for open discussion

This is a great idea. My suggestion for it is to vet each mechanic one at a time, such as KrinkleChip has been posting as a Mechanic of the day. Actually per day is too frequent, per week would work a bit better I think. This will allow for some nice open discussion and debate, and then I'm sure these posts could have some good *meat* in them that could get edited and included in the Mechanic description.

(don't forget the content over at the geek.)

If this was done well, make it into a pdf book for sale. I'll buy one to have as a good, solid game mechanic reference.

mistre
mistre's picture
Offline
Joined: 07/28/2008
Great resource

Shannon Appelcline has written a lot about game design that would be an invaluable resource for a mechanics database.

See the following link (specifically the articles from Season 5:Designing Strategy and on).
http://www.skotos.net/articles/Thinking.shtml#s5

larienna
larienna's picture
Offline
Joined: 07/28/2008
Need to classify

I would probably need to do an average bunch of mechanics first in order to create a classification scheme. When it's done, then I could add on.

Maybe the basic mechanic would be inserted in the database only by the admin but any variants could be added by people on the internet. This way, you sill have a lot of content in the database while still being organized.

Apparently, BGG can do some web hosting? That's what one of my friend said.

tinymachine
Offline
Joined: 08/21/2008
interesting idea

sounds like a mammoth task - i'd guess there must be many 1000s of different mechanics and sub-mechanics used in games. BGG lists something like 50, but these are very broad. taking bidding there must be over 100 bidding variants in games on its own. i'd suggest you use some sort of hand written software to trawl through BGG via google and pull out descriptions of different mechanics in the thousands of reviews to create an initial database - it would need to be able to differentiate different ones - a real hard task. doing it by hand would be too daunting - getting all the BGG users to create a much more specific list of mechanics used in their listed games might be possible - perhaps with some geek gold incentive - the lack of proper mechanic detailing is often moaned about on BGG.

good luck.

Katherine
Offline
Joined: 07/24/2008
isn't it interesting that two

isn't it interesting that two data bases are being discussed on the one forum. One is for clip art and users pay a weekly fee, this site does not appear to offer anything else and I bet the administrators get paid for their time.

the other is discussed in the above thread, I think it is a great idea and agree that it would be labour intensive to establish. I see the unreasonable part of this idea being that the actual work will fall to those who have administrator access, in their own time and free of charge. The other thing to consider would be weather the site would support a data base or will there be extra costs involved

Perhaps the people who made this site could create a commercial "sister" site with a mechanics data base and a clip art data base and charge an access fee.

larienna
larienna's picture
Offline
Joined: 07/28/2008
limited audience

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.

mistre
mistre's picture
Offline
Joined: 07/28/2008
BGG Wiki

It would make sense to have your information posted here:

http://www.boardgamegeek.com/wiki/page/Games_by_mechanic#

Right now there are only 2 entries and they are sparse. If I was doing this, I would start with the mechanics listed here: http://www.boardgamegeek.com/browser.php?itemtype=game&sortby=mechanic, provide a description of what the mechanic is, define sub-mechanics, and provide examples from well-known games. When done with the main categories already defined in BGG, I would go back and fill in the blanks for what is missing and see if it makes sense for existing mechanics to be combined or deleted.

Two mechanics off the top of my head that are not listed on BGG are "press your luck" - Incan Gold, Can't Stop, etc. and "worker placement" - Agricola, Caylus, Pillars, AOEIII, Stone Age, etc.

larienna
larienna's picture
Offline
Joined: 07/28/2008
BGG data

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.

mistre
mistre's picture
Offline
Joined: 07/28/2008
larienna wrote:For the first

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

Yes, you can edit the page (or any of us could for that matter) - that is what a wiki is for. You could create your own page, but since the page I referenced is called "games by mechanic" and has very little on it, I would recommend just posting content there.

KrinkleChip
KrinkleChip's picture
Offline
Joined: 07/30/2008
This is my goal, actually...

Io. This is one of my goals with my Mechanic of the Day, actually. From the feedback I've been receiving, this is wanted by your fellow designers... badly. And as for whether it would help your game design, it will; along with everyone else's. A nexus of creativity such as this would be a source of inspiration for game designers abroad... and we all want more awesome games to play.

Regards,
Phil

*Brief side note rant* I've already done about 30 Mechanics for my game design group, and I figured once there were enough, I'd gather them together (among other things) and do a Lulu-style print on demand book. *rant end*

Zzzzz
Zzzzz's picture
Offline
Joined: 06/20/2008
Sorry for the lack of

Sorry for the lack of response, I have been pretty busy lately so my time is not being directed toward BGDF and the useful ideas listed here.

The previous site did offer more content on the specific topics being discussed here. Such as a breakdown of mechanics, pro/cons, and was suppose to grow with time.

You can see the older information at http://archive.bgdf.com/tiki-index.php?page=Game+Mechanics

This content has not yet made its way over to the new site, directly as a result of my lack of time. And since $$ talks, I have to make choices that sometimes yield a negative on BGDF, since I do everything I can for BGDf, free of charge (as is every admin/editor/moderator at BGDF.com).

With that said, there are something swe can do to promote this mechanic *db* idea here at BGDF, but there needs to be a structured goal in mind. This old version was initially thrown together by some members, but it never was completed nor was it every used by members. Either for commenting or expanding. The downfall might have been directly tied to the restriction of whom could alter the content, but to avoid the normal wiki issues of spam postings, BGDF admin decide to restrict who could alter. But attempted to encourage members to post updates, tweak or suggestions by commenting on the wiki page. This was fine, but slowly no one seemed to use it.

With all of this said, my goal was to actually write up some very useful content and only post materials/articles once they are *complete* ideas. Doing so would help avoid partial content areas, bad content, and hopefully improve user experience.

SO, if you are an interested member that wishes to produce content for the site, please PM me. Maybe we can work on a method that will allow you the members of BGDF to create content that can be added to the site, such as this mechanic DB. But please understand we need to keep the content and process structured to help improve the user experience here at BGDF (and avoid some of the old pitfalls of horrible and stale data)

larienna
larienna's picture
Offline
Joined: 07/28/2008
I don't mind doing the classification

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.

mistre
mistre's picture
Offline
Joined: 07/28/2008
Randomness a mechanic?

Is randomness really considered a mechanic? I see mechanics more as player driven actions such as worker placement, card drafting, auctions, tile placement, etc.. Randomness can be ACHIEVED through various mechanics - dice rolling, drawing cards, pulling tokens or items out of a bag, etc., but I don't think randomness in and of itself is a mechanic. I do agree with your other assertions.

larienna
larienna's picture
Offline
Joined: 07/28/2008
about randomness

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.

hansth
Offline
Joined: 10/03/2008
defining what a mechanic is ?

Anyone given this some more thought ?

I agree with the thoughts on current mechanics listed at BGG (and other sites).
(They are all crappy (in various degrees)) :-P

The mechanics listed at BGG:
(I put a minus ahead of those I think are not mechanics for various reasons)

- Acting
Action Point Allowance System
Area Control
Area Enclosure
Area Movement
Area-Impulse
Auction/Bidding
Betting/Wagering
Campaign/Battle Card Driven
Card Drafting
Chit-Pull System
Co-operative Play
-Commodity Speculation
-Crayon Rail System
-Dice Rolling
-Hand Management
-Hex-and-Counter
-Line Drawing
-Memory
-Modular Board
-Paper-and-Pencil
Partnerships
Pattern Building
-Pattern Recognition
Pick-up and Deliver
Point to Point Movement
Rock-Paper-Scissors
-Role Playing
Roll and Move
Route/Network Building
Secret Unit Deployment
-Set Collection
-Simulation
Simultaneous Action Selection
-Singing
-Stock Holding
-Storytelling
Tile Placement
Trading
-Trick-taking
Variable Phase Order
-Variable Player Powers
Voting

I guess the first step towards making a good mechanic database, is to define what a mechanic really is. (what defines a mechanic?)

larienna
larienna's picture
Offline
Joined: 07/28/2008
This is why I thought it

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.

The Magician
Offline
Joined: 12/23/2008
larienna wrote:It's just an

larienna wrote:
It's just an idea I got like that. I am not sure it could be very useful. It seems that most of the time, when I design a game, I am always shopping for a mechanic to add to a game. Since I have a limited memory I sometimes forget mechanics I already have seen in games I played.

So I thought that I could create a database containing all the game mechanics I have seen so far in order to make mechanic shopping easier or to create new mechanics by combining ideas.

Of course, the information would have to be classified in certain way to make it easier to find. There will probably be sometimes a base mechanic with some variants (ex: auction: Blind, one bid, open, etc).

I am not sure if by doing something like this it would really pay off in the end. Don't want to place time of something which would not help me. Of course, if I do it, I would probably put it on the internet to make sure other people could benefit from it or maybe add to it (as long as the content stays classified).

So what do you think?


I love your idea of a mechanic database! Just before I found your post, I was interested in finding just that. I wanted to know if there was a database that I could brows to get ideas from.

larienna
larienna's picture
Offline
Joined: 07/28/2008
From what I know, there are

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.

The Magician
Offline
Joined: 12/23/2008
Ahhhnghhhh!: http://mike-comp
Katherine
Offline
Joined: 07/24/2008
I think a component data base

I think a component data base is a good option - known mechanics for each component could be listed as a sub category. It is still a lot of work for some one to do though.

skeye
skeye's picture
Offline
Joined: 02/06/2009
About Shannon Appelcline

Really interesting !

Mitchell Allen
Mitchell Allen's picture
Offline
Joined: 08/09/2008
Mechanically Basing Data in a Mechanics Database

larienna wrote:
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.

I've developed databases for a living. and I have always felt the need to approach the designs from both ends - bottom-up and top-down.

One approach I never had the luxury of trying was a genetic approach.
What if we had a generic method for creating retrievable information?
Further, what if each interested person began building his or her own set of generically produced snippets of information?
Finally, what if all of this were transparent?

What I think would emerge is that oft-overhyped phenomenon known as the wisdom of the crowd. At some point, contributors will notice a method that complements their own - or maybe improves on it. If the method is simple to imitate, it will supercede the prior methods.

Imagine that, over time, a superior methodology evolves - genetics, get it? :)

As that methodology dominates its lesser siblings, the data will coalesce into a usable compendium of information.

I have no real idea how this could work, except within the constraints of a well-defined authoring system, like a wiki. The only thing I would do to control existing data is to make it read-only for all but the original author. I also think that hyper-linked information may be more useful than hierarchical, although that remains to be proven.

My reason for down-playing categories and rigid definitions is not because the database wouldn't benefit from them, but because (as larienna continually points out) the lack of a clearly defined structure seems to be an inhibiting factor. I personally always liked the BGG list of mechanics, because it is a springboard for inspiration.
Its inconsistencies and overlapping elements don't detract from that.
However, if you're mainly interested in a canonical database of mechanics, then categories and rigid definitions are of paramount importance.

Cheers,

Mitch

The Magician
Offline
Joined: 12/23/2008
I love it! We would need a

I love it! We would need a basic structure to start with.

Katherine
Offline
Joined: 07/24/2008
Mitchell, I may have

Mitchell,

I may have misunderstood your post because I am not very IT savvy, so correct me if I am wrong.

I think that a game design data base would need categories and the primary category should be components. In my opinion components are physical, they exist and people can buy them.

Mechanics are but a figment of someones imagination, they are not physical outside the game, they cannot be purchased outside the rule book and they change with designer imagination.

If I was puchasing a data base of mechanics I would like the process of selection simplified. I would like to be able to search by primary component, then varient and then run a report for all known mechanics used with the nominated component.

This is probably not possible for a public data base with multiple contributors but as a newbie something along these lines would be most useful. I say this from personal experience.

When I first started viewing this site I did not know much about game design. for example I did not know that dice could have more than six sides. To get around this I used copy (unkown terms in blogs) and paste (into the archives search), to learn more about this design stuff. This is a very painful way of finding information and 90% of my searches have turned out to be mechanics, not components. This indicates that I would not know something was a mechanic to search it by that term anyway.

Someone may suggest I just ask, but the "dumb" questions never get answered on this forum.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Quote:I think that a game

Quote:
I think that a game design data base would need categories and the primary category should be components

I agree with your idea, many times you know what components you want you just don't know how to implement it. The problem is that the components does not restrict any how the mechanics that can be attatched to it.

For example, you can do an auction with :

Cubes, cards, tiles, paper money, dice, etc.

You can draft with

Cubes, cards, tiles, paper money, dice, etc.

So almost all components can use almost all mechanics.

So if I was to make a classification scheme, the components could be a facet of the component-mechanic database. But the components never restrict the mechanics that can be used. Vice versa is also true, a mechanic can never restrict the components you can use.

This this is why I thought it should be easier to make first a component database and then maybe link mechanics to each component. Still considering that N components can have N mechanics.

Taavet
Taavet's picture
Offline
Joined: 08/15/2008
Knowledge is Power!

Plain and simple, why reinvent the wheel instead of improving on it?

It's not that we just want to butcher and steal elements from old games to set ourselves up as competent designers. We want to CREATE and IMPROVE on existing systems/designs. Having access to a resource where these can be researched and analyzed would greatly benefit everyone.

That is one of the reasons most of us frequent the forums. If we aren't here we miss bits and pieces of information and ideas which help to inspire and drive us foward.

As far as the old site and old database getting stale and not used I think that is largely because no one has enough time to properly use it. If I am making a game only a very small part of that time is spent looking/thinking about mechanics. So I would only access the database once in a while. Otherwise, as I know we all have, you get overloaded with ideas on how to do this and which way this would work and maybe this way ect, ending up with several designs that never get done or just get archived and sit in our personal databases.

Good idea. Good luck! I would use it every so often and it would help save time and energy. It would probably also help avoid those *dumb* questions which get posted in the forums and not answered!

I did know dice could be had with varying amounts of sides, but on the dice subject I did just read up and learned about the non-transitive dice (rock, paper, scissors): http://www.bgdf.com/node/944 Pretty cool concept!

Syndicate content


forum | by Dr. Radut