Skip to Content

Making a mechanic database

83 replies [Last post]
Ekobor
Offline
Joined: 10/27/2008
Rereviving an old thread, but...

I too am a librarian and I too would love to work on a database of sorts of game mechanics. My stopping point has been classification schemes.

@Larienna: You said you'd had some ideas about a classification system? Care to share more in depth on that? If you still have the ideas, that is.

Where I've gotten for classification has been an attempt at a Dewey like system, with these as my hundred's level categories so far:

000- Randomizing
100- Movement
200- Trading
300- Information Sharing
400- Physical
500- Scoring
600- Combat

That leaves three places for others, and of course is open to change.
As far as components I was thinking of them as more tens level,
i.e: Ranomizing -> Dice -> Pool -> Entry
or
Combat -> Dice -> Pool -> Entry

I'm in the position where I have a fair amount of free time to devote to such a project, but it is a mammoth of a project and I'm not sure exactly how to start.

I'd love some thoughts about this. I'm trying to find something I can do that helps the general community.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Sorry for my late reply, I

Sorry for my late reply, I think for starting it would be too overwhelming to make a mechanic database since there is so many possibilities and it's so much abstract.

Just for rolling dice, you have mechanics regarding how you roll the die, how you manipulate the dice, how you interprete the value of the dice, etc. There might also be ambiguity on what a mechanic is actually is, since people could describe an infinity of sub mechanics.

My suggestion would be to have a component database since we are describing something that exists physically.

So if we take dice, we can talks about variation in number of faces, colors, colors on faces, content of face (icons, pips, numbers) etc. We could post pictures as examples.

Even with that information, designer could get new mechanic idea by seeing what kind of components could be used in a game.

Then afterward we could link those components with mechanics once we get something more solid. I think this would be much more realistic than doing a mechanic database.

Tell me what you think. I can build the web site and help for the classification scheme. I won't have much time to add description except for a few examples. I am more the kind of guy to start and control a machine, than adding content. I would still try to do my whole game collection as an example.

I have the webspace to build the website, so that should not be a problem for me. I would use a wiki, probably semi open, for the job.

larienna
larienna's picture
Offline
Joined: 07/28/2008
I have been thinking and

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

Ekobor
Offline
Joined: 10/27/2008
Not a problem. It is probably

Not a problem.
It is probably too large a scope, I agree.
But then again, a near infinitely expanding classification system already exists in Dewey, so the extreme numbers aren't the issue, it is (as you say) the abstractness.
Perhaps it would be a better project to develop a standardized jargon for mechanics, then/than a database of mechanics.

I like the components database idea too, I just don't feel it would be as helpful. But I'd be willing to help with one.
But brings us round back to needing a classification scheme to categorize the components.
Which, (again, as you say) would be a lot easier as the pieces are at least physical.

I think it would be hard to make a component's database without at least some reference to mechanics, as examples of usage would be needed for less common elements. I'm thinking of "Kerplunk" now, and it's use of skewers and marbles. The skewers aren't exactly a common element in games, but they are certainly a component in a game.

If you have a good idea where to start I'm willing to do a fair amount of legwork in filling out entries. And I'm sure many others would have things to say about it. I agree about a semi-open wiki, I just don't have a lot of experience setting them up, only maintaining them.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Quote:I think it would be

Quote:
I think it would be hard to make a component's database without at least some reference to mechanics, as examples of usage would be needed for less common elements.

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

Quote:
If you have a good idea where to start I'm willing to do a fair amount of legwork in filling out entries. And I'm sure many others would have things to say about it.

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.

Quote:

I agree about a semi-open wiki, I just don't have a lot of experience setting them up, only maintaining them.

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

Ekobor
Offline
Joined: 10/27/2008
This sounds reasonable. I

This sounds reasonable.
I have very few games, and they are almost all card games. But as a stand-in for my library, I can certainly take an extended trip to my FLGS and inventory some components used there.
I just wonder if it would be good practice to design a checklist of sorts for acquiring data.

Because I can look at Robinson Crusoe and Love Letter and and a myriad of other games and say "They use bricks", but maybe I should be looking for more detailed information?
I realise a good deal of this would come after in the detailing phase, but it might be good practice to take the information down anyway?

Because I'm thinking knowing that there are cards in a game isn't as useful as knowing that there are 2.5" x 3.5" (poker)cards, and 1.5" x 2.5"(Euro) cards- both need to be listed in some fashion.
But knowing that some are red, blue, green, double sided or not, that seems less important.

So I guess I am asking what is our level of import? What kind of standardization should be used in collecting data?

--

Those are quite the variation of sites! Good work, I must say. I only have passing knowledge of CSS, and I've never heard of PmWiki, so I feel a bit out of my depth in this area.

larienna
larienna's picture
Offline
Joined: 07/28/2008
I think the description

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.

Ekobor
Offline
Joined: 10/27/2008
It seems to me that it

It seems to me that it becomes a roundabout way of classing mechanics in a sub-optimal fashion, however.
If it were truly about components, would it not be of more use to describe as:
Card
- shape
- colour
- size
- etc

as these are physical and not mechanical properties?

Numbers/writing on the card would then be considered their own component in how I am envisioning, because is it easier to class:
Writing
- on card
- in book
- etc

as a component?

Because it seems like we would end up with far too much clashing information, and end up defining components by game, rather than games by components.

-----------------------------------
I'm quite happy using any site maintenance you are comfortable with, as I do not have enough knowledge to make a useful objection.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Hmm! interesting For example,

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.

Ekobor
Offline
Joined: 10/27/2008
So, as an example this card

So, as an example this card from Ascension: The Cultist

I see:
1 - single sided 2.5"x3.5" card (The rear is just art)
1 - Title box
1 - Title (Cultist)
1 - Number (2)
1 - Symbol (behind the 2)
1 - Art box w/art
1 - Class Title (monster)
1 - effect box
1 - Effect Text (reward: 1)
1 - symbol (behind the 1)
1 - Flavour Text

Is this the type of thing you're thinking of?

larienna
larienna's picture
Offline
Joined: 07/28/2008
I have made 3 games so far,

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

larienna
larienna's picture
Offline
Joined: 07/28/2008
Here is one thing that has

Here is one thing that has been botherinrg me, net sey we avoid redundance between components (make sure there is not a text about let say "color" for each component that can have icons) we would end up with the following structure

1 Page for Dice
- link to color page

1 Page for Cards
- link to color page

1 Page for Tokens
- link to color page

1 Page about Color

But the page about color will have to list all the possible use of color forcing to display color for dice, color for cards, and color for tokens on the same page. Which can get pretty long

That could make the navigation pretty annoying. Most people would be look for a component and they want to know everything about that component. So I think it should be better to split the color page for each component and add "See also" links between color pages. For example

Page about Dice
- link to Page with color used on dice

Page about Cards
- Link to page with color used on cards

Page about tokens
- Link to page with color used on tokens

And on each page you'll get "see also" links. As for example

Color used on dice
- See also color used on cards
- See also color used on tokens

With that approach, we could start to list only components and their physical properties, then we could elaborate more about the content put on those components. It would make a 2 step description where the 3rd step would be describing mechanics.

Quote:

So, as an example this card from Ascension: The Cultist

I see:
1 - single sided 2.5"x3.5" card (The rear is just art)
1 - Title box
1 - Title (Cultist)
1 - Number (2)
1 - Symbol (behind the 2)
1 - Art box w/art
1 - Class Title (monster)
1 - effect box
1 - Effect Text (reward: 1)
1 - symbol (behind the 1)
1 - Flavour Text

Is this the type of thing you're thinking of?

Similar, only list the same type once. If you have symbols, just say there are icons and symbols, I don't need to know how many symbols there are in the game. I just need to know that symbol exist so that we can describe where they can be used in games.

Ekobor
Offline
Joined: 10/27/2008
That sounds effective. It

That sounds effective.
It also makes it sound like a much smaller task, as while there are many colours and different symbols, there is no need to list them all.

I guess now it comes to how wide a net we throw. Obviously we include standard playing cards, but do we include mechanical things like the Hungry Hippos game?

Ekobor
Offline
Joined: 10/27/2008
Something else I'm working on

Something else I'm working on is here.

It's basically an attempt to standardize the language used to describe games, thus allowing us to talk about mechanics in a more structured way.
I feel like this makes the task more bite sized, but perhaps it is folly.
I'm using a spreadsheet, as I find that easy right now. I'll probably end up porting the data over to Lexique Pro.

Thoughts? Am I making any obvious mistakes?

X3M
X3M's picture
Offline
Joined: 10/28/2013
@Ekobor

I don't know if you are making mistakes. But that list actually looks promising.

It could contain much more. And then base the library of mechanics on this list. It should become some sort of board/card game wiki. With cross references.

ps. I am missing the word "Round"

Some words might hold several meanings for several people. Or a certain mechanic/meaning has different words.

You need to take into consideration that confusion might appear due to this difference. (I can know, had one about Rate of Fire and Cool Down on another forum)

So, perhaps allowing people to send you their view on words. And new words. And add that to the list? Once you see obvious differences that show similarities with other words. (round = turn = action) You could add a, "what if" round means this... Then turn means that.

...I hope that was understandable... I know how confusing I sometimes am with words.

Ekobor
Offline
Joined: 10/27/2008
Thank you for taking a

Thank you for taking a look!
I have been adding to it for about two or three hours, and expect it is missing many things. I added round, thank you for mentioning it!

My hope is that if someone with more knowledge than I in terms of wikis and such worked with me, the cross referencing would be there. (Thus the desire to work with larienna)
As it is the "See Also" Section (which I've yet to fill out ^^;;) is supposed to contain the keywords you might want to look up. Like an old card catalogue.

---

This is my way of trying to stop certain things from having multiple meanings. Or, more clearly, a way to standardize the language/jargon used when talking about games.

In many fields the jargon is standardized by a governing body of some form (I'm thinking of the DSM when it comes to mental health as a good example). Of course, board games don't have that (and I don't claim to be that) I think mainly because people think they are 'just games'. But if we as designers want to be recognized as a realistic field, I think we need to tidy up our act, and make our jargon a bit more uniform. Is this the only way? No. It's just the best I can come up with.

So, I know there are many meanings to each word (Turn, as a great example) and many possible ways to define. But I am hoping there can be a general consensus between designers that "this set" or "that set" of jargon is what we're going to use to define words in our current discussion. Just like how it is meaningless to discuss symptoms of bipolar if one psych is using the DSM and the other the ICD.
This is just an attempt to make one of those references.

I have opened this up for discussion over on the 'Geek (here), and will make a similar thread here tomorrow

...This turned out very long, my apologies. I just really like this idea.

---

As an after thought, I have used this system to describe the game Ascension (as I am familiar with it) and found this list serviceable. I was able to describe game play in a basic way in a about two paragraphs.

larienna
larienna's picture
Offline
Joined: 07/28/2008
About the list, it's true

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.

Ekobor
Offline
Joined: 10/27/2008
I think we have as much

I think we have as much authority as anyone else, perhaps a tiny bit more after such a resource is made- people default to already made paradigms.
A glossary is certainly needed for our project, to keep people on the same page about what we are talking about.

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

I like the stepped idea. It makes it a manageable project.

As for how to set up the wiki, that sounds appropriate. That way each category(root) has easy access to its sup pages.

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

Oh, certainly keep building the inventory! As you say, it is step one.
This list is merely a side-project for me, not an attempt to replace the work necessary.
I'm heading to my FLGS today to inventory a few games, now that I know what I'm looking for.

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

I hadn't thought of name ideas, but Board Game Design Database seems functional at this point.
I agree that it seems necessary to include the 'board' part.

larienna
larienna's picture
Offline
Joined: 07/28/2008
I am managing tons of

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.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Here is another inventory

Here is another inventory example I did this morning.

Hacker
- Cards: Text ability, Name, Flavor Text
- System cards: Attribute name and values, Name, Special ability, Connection icons on the edge, hub icon on the center
- Player Tokens: Square and Hexagonal shape, Full and hollow icon shape inside, Thin Tokens, some have text. Various colors for each player.
- Game Token: Hex, square and rectangle shape, Contains Text, icons, numbers and drawings. Thin.
- Console Unit Sheet: Thin sheet with incisions to slide in upgrades. A color for each player. High Voltage add on. Contains color coded area and text.
- Concole upgrade: Thin slide in upgrade for the console. Contains text and values
- Virus: Thin slide in for the console containing names and pictures.
- Net Ninja Token: Large thin token with text and picture
- Dice: White and numbers (not included with the game)
- Rule booklet: Paper, Folded, Staples in the middle.

The idea is to list components with the properties of that components. So that we can first groups same compoents together (All cards, token, etc). Then when we will have them grouped, we could now at the 2nd step group properties of these components to make the sub pages. It will avoid making the inventory twice. And we will have enough content to describe for a long time.

Ekobor
Offline
Joined: 10/27/2008
Okay, so: Mancala - Stones:

Okay, so:

Mancala
- Stones: Of various colours without meaning
- Hinged Board: Wooden, with divots in two sizes small- movement, large- scoring
- Rule Sheet- Paper, folded

Gargon, Amulet of Power:
- Cards: single sided number, symbol, art
- score cards: double sided, +number
- Rules sheet: paper, folded
- Box: Cardboard

?

larienna
larienna's picture
Offline
Joined: 07/28/2008
Yeah, Somehthing like that. I

Yeah, Somehthing like that. I finished the top shelf of my closet. It includes small and large game. So the selection could be nice.

Send me your e-mail address by PM or at ericp@lariennalibrary.com, and I'll send my list of components so far, plus the pictures of the components of the game so that you know what I am taking about.

I did not redo the first 3 games according to the new format, but it should not matter much.

I listed rulebooks, and sometime the tray if it was useful in the game. I was not sure but I think it will be interesting to have a few pages on that because some of them could be very creative. The game box itself could also worth mentionning is special cases. For example, there was some games distributed in VHS tape box.

This is it for now. I'll start shopping my wiki skins.

Ekobor
Offline
Joined: 10/27/2008
I got your email. It is very

I got your email. It is very comprehensive list!

I went to my FLGS for game night and took note of a couple game's components:

Fluxx: The Board Game
- Start Tile
- Tiles: bearing images as spaces to land
- pegboards: bearing text and images and a space for cards
- pegs
- cards: bearing images and text
- colour cards: bearing an image and text as well as a colour
- tokens- in various colours and shapes

Ticket to Ride:
- Train Car Cards:Bearing a colour
- Destination cards bearing text and an image
- Score card: showing images and text
- Longest road card: showing an image and a value
- Board: displaying a score track, and claimable spaces
- train tokens: in several colours relating to player
- player tokens: for the score track, in several colours relating to player
- Box with tray: organizes trains
- rules: glossy folded paper

Coup
- coin chits: one denomination
- cards: showing an image and text
- Player reference cards: showing all possible moves
- rules: booklet

I agree that the boxes and trays can be important (wasn't there a game where the tray became the terrain for a wargame? Or am I imagining that?)

Syndicate content


forum | by Dr. Radut