larienna,
My spreadsheet columns are:
primary / secondary / funcion / dependancy / rule / game.
eg: blocks / elongated / stack and crash / nil / cannot take from top of tower / jenga
I try to use the name given by the designer for the secondary. With the dread pirates dice, I would use dice / wind.
This may be over the top with 30+ different cards (so far) but it works for me and beats the copy and paste!
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.
I'm not very IT savvy, either, which is why I love to solve problems in ways that are not necessarily in line with conventional thought processes.
First, let me repeat that categories and structure are indeed important, if you're looking for a definitive guide to a particular subject.
In the context of this thread, it appears that the canonical approach is not working out. Either there's not enough manpower to support such a rigid database (EDITORS) or there's not enough agreement as to what should go in it (CONTRIBUTORS).
I have suggested that we combine the two roles and allow any interested person to be a CONTRIBUTING EDITOR.
I like this observation! It actually supports my line of thinking, too. Since mechanics can seem to be so ephemeral, how much more difficult must it be to impose structure on it?
To be prosaically silly for a second, consider how useless air would be to us mammals - if it were permanently frozen solid!
Just as air is all around us, supporting life while being unconstrained, the wisdom of crowds can support the growth of a knowledge base, while being unconstrained by "categories" and "structures".
To be sure, some structure is necessary. Returning to our friend, air, structure is not imposed by the actions of those who use it, but by a disinterested third party: gravity.
In our scenario, the Wiki software would be that which imposed structure on the knowledge base.
So, within that context, your own CONTRIBUTING EDITOR method is valid:
However:
If enough people agree with your assessment of this method, it would fall into disuse, in favor of a more efficient method.
Thus the wisdom of crowds is conducive to an evolutionary style of storing and retrieving information.
Finally:
You have pointed out the major flaw in rigid database design implementations. It is nearly impossible to know beforehand how best to "tag", "classify" and "file" every bit information within a confined system. Retrieval, in such systems, becomes an unnatural dance between the expert classifier and the novice seeker.
I used to classify fingerprints for law enforcement and that rigid system - thankfully - gave way to the AFIS: Automated Fingerprint Identification System. (I shan't bore you, but the key difference between the old "Henry System" and the new AFIS is sort of like the difference between driving cross-country with an old map and using GPS: the older systems rely on absolutes; the newer systems rely on relative positioning.)
Anyway, thanks for asking me about this.
Cheers,
Mitch
Hey, Magician!
I've been using TiddlyWiki exclusively. It's self-contained.
What if everyone who wanted to contribute snagged a copy of TiddlyWiki and just started typing away?
I bet we could get some ideas for building. As we saw other works in progress, we could adapt our version by using the bits we like best from the other TiddlyWikis.
Will the blog feature on BGDF support javascript?
if not, we can host our own wikis. :)
Cheers,
Mitch
Dumb question Mitchell.
Where is the tiddly wiki tutorial? I know the download button and nothing else!
Hi shazzaz,
Here ya go:
http://www.blogjones.com/TiddlyWikiTutorial.html
http://www.giffmex.org/twfortherestofus.html
Cheers,
Mitch
Excuse my lack of knowledge about this thread (since I have been vary busy with personal matters), but what is the goal of this mechanic database?
I ask since I am willing to consider addition of functionality to BGDF.com to help support whatever ppl feel the goal of this thread is meaning to accomplish. So if someone could summarize what the goal/ideas are in a nice outline formed post. I will see what I can do to help facilitate some new functionality on BGDF.com to help support it.
OK, here is an example of what optimally the user should be able to see or do in a mechanic database.
Let say, I am looking for a combat resolution mechanic. I strictly want to use cards in the resolution but I don't want any auctions. So I could type in something like this:
(index are ME: mechanic, CO: component
ME:combat AND CO:Card NOT ME:auction
and it should give a a result like
Combat cards with values specific to units.
Short summary description here.
Source: Starcraft.- Fantasy flight game, 2008
Combat by matching set of cards
Short summary description here
Source: Supernova.- Valley Games inc., 2008
Now what I realized is that for example, I my library catalog, if I am looking for "hamlet" I am going to find something like 12 results. Some comes with integral text, some books are a group of pieces contaiing hamlet, some have notes. So for the mechanic database, if I tyme "Me:Roll and move" and get 150 results, it should be normal.
So this is why I think that we should not check if the mechanic already exist in the database when entering a new one. Double entries will exist because each can have a flavor of it's own that would make the mechanic unique.
It could also be interesting that all the game information "Supernova.- Valley Games inc., 2008" comes from board game geek. So that we don't get double entries on the same game.
Here is how I could see it could work. A user which has the game (maybe selected user) can decide to index a game. If he wants to do so, he locks the game in the database to make sure no other player index it.
Then he finds all the mechanics in the game possible. Some indexer would be more exhaustive than other. He give its a name, short description and long text explanation. Then he add some keyword. I suggest for now
Free vocabulary keyword for mechanics: So a user could write : Combat, auction, etc. all singular noun. There could be a dictionnary to match synomyms : Combat = battle. Auction = bidding.
And controlled vocabulary keyword for component: Example
Pawn - Odd Shape - Meeple
Pawn - Polyhedre - Cube
Dice - 6 Sided
etc.
I could always make that thesorus
Anyways, got to leave, if need more info idea just ask.
While I was in the metro, I was thinking about other indexes that could be used. So far I have:
Component: Most of the time there is only 1 component per mechanic, but it could happen that you can use multiple componets in a mechanic.
Mechanic: Free vocabulary Keywords that described best the mechanic.
Objective: Goal of this mechanic ( ex: combat, price calculation, etc)
Nb of players: The amount of players the mechanic affect, 2, 3 , 4 players or all players,or a specific group of players.
Time: Amount of time it takes to use
A: Instant
B: Requires some manibulation
C: Requires some calculations
Thinking: Level of thinking to do in the mechanic
A: Intuitive, almost no thinking
B: You must give some thought about it.
C: There is downtime and analysis paralysis.
for example, the cash and guns's gun pointing mechanic would be instant and intuitive.
that all for now
Reading this topic reminds me of a book that I often use as a reference in designing my games: Patterns in Game Design. In stead of talking about 'mechanics', the authors talk about 'patterns' ("practical design choices") that are possibles in games.
I actually use the book for the same reason larienna already stated in the reasoning for starting the database: "in order to make mechanic shopping easier or to create new mechanics by combining ideas". Even though I mainly use it when designing digital games, in my opinion it can be used without trouble for board game design as well.
So before starting to make the database, I would definitely suggest taking some time to look at this book (it has the "Click to look Inside" option on Amazon - might want to do that first).
I have another book from the same collection called "21st century agme design" which focus more on video game groups of players. So my question is: Is this book focused on video game design, or are the concepts generic enough to be transposed to board game design?
This is really few board game design books out there. I want to eventually build up a small collection but right now, I don't have much time to read.
In essence "game design" is "game design". Whether you're designing for digital games, board games, live action role-playing games or alternate-reality games does not matter. Because of the abstraction level chosen in the book, the patterns described can be applied to "game design".
So as to answer your question:
There is no need to transpose, the way the patterns are described,they can be used for game design regardless of the game's medium.
I checked the table of contents and it makes a lot of reference to video game design but still it's not as much as the other books of the same collection which all talk about VG.
That might have to do with the naming choices for the different patterns. Some are easily connected to video games and harder to see in a board game perspective.
Could you give me an example of what you believe to be a typical 'video game reference', so I can try and find the description of the pattern connected to it?
here a few quick examples:
chapter 5 -- object -- controler
chapter8 -- action -- aim and shoot
chapter8 -- action control -- save-load cycles
chapter 9 -- narative structure -- cut scene
chapter 13 -- game and play sessions -- real-time games
Still, in general the book seem OK and the knowledge seems transposable to board game. I contacted the publisher and ask if they could tell me which of their books is actually realted to game design in general so that it could be transposed to board game design.
What frustrate me about their books is that they use the expression "Game design" when they wan to say "video game design" like if board games and other media were actually non existant. I also try to find it in libraries and according to amicus, there is only 2 libraries in canada that has it. So I think I would have to buy it.
By the way, the content of the CD-rom seems interesting, could you tell me more of it's content? (is it useful to you?)
Thank you
chapter 5 -- object -- controler
chapter8 -- action -- aim and shoot
chapter8 -- action control -- save-load cycles
chapter 9 -- narative structure -- cut scene
chapter 13 -- game and play sessions -- real-time games
I can see where you're going, but remember we're talking about "game" design here, not by definition "video game" design, but also not by definition "boardgame" design!
> Controllers: when the player is represented by and avatar in the game, this concept van still be used in a board game. Also one could imagine that such game element is part of a physical game (such as tag).
> Aim and shoot: paintball? laser tag?
> Save-Load cycles: this is a tricky one and I will have to agree on you that although possible, it is unlikely that you will be using this in another kind of game except for a video game.
> Cut scene: there are actually a couple of 'dvd boardgames' around. One can play the game and at certain points in the game you watch certain scenes of the dvd.
> Real-time games: tag (again)? hide-and-seek?
What frustrate me about their books is that they use the expression "Game design" when they wan to say "video game design" like if board games and other media were actually non existant. I also try to find it in libraries and according to amicus, there is only 2 libraries in canada that has it. So I think I would have to buy it.
I did not read every post here but I have a question.
has this been made/finished?
If it has not, I would be happy to make it.
Very old thread revival!
I do not think anybody has done such things. The main problem is that it's hard to make a finite list of mechanics or find an appropriate way to class them. It could be easier to make a list of components instead and define mechanics that could be used with it.
I currently do not have the time to work on this. I think I still have some paper notes about it, else I will have to check them and reread this thread.
If you are interested, first read this thread, it will give you an idea of the problems encountered in the discussion. Then I can always host the project on my website if you need web hosting. I generally use a Pmwiki to design web site, I could set you up a site and give you the web access. I am open to use other systems.
If you need a classification scheme, I could always design one (since I do that in real life). But I wont have time to fill up the content of the DB.
Tell me what you think.
Additional note, Currently I was more looking to make a thematic index database to stimulate creativity.
Considering I lacked of time, I tough I could only dump the results of my own research for some of my games, so that the content could be reused. Rather than extracting data from all the games I have.
Do you think that some system to comment on, and rate mechanics would work?
People would have to rate mechanics 1 to 5 stars, depending on how fun the mechanic is.
EDIT: actually I am not sure rating would be a good idea... Rather than rating, people could favorite/like certain mechanics. Mechanics that you favorite/like will end up on your personal list of mechanics that you like.
So pretty much, if someone is browsing through the database and find some mechanics that they want to use in a future game, they could say that they like that mechanic. Then when that person wants to make a new game they can look through the list of mechanics they like and use some in a game (rather than looking through the database again to find the mechanic you remember that you liked).
The only problem with this is that your like list will overflow with mechanics you like but don't want to use in a game. So maybe there could be 2 different buttons you can press
If you like it but are not planning to use it:
If are planning to use it in a future game:
You could rate various elements besides preference. For example, is the mechanic heavy, easy to use, requires a lot of components.
But still, those could be instead placed in the list of pro and cons of a mechanic.
But better late than never, right? I think the idea of some form of mechanic/wiki has a lot of merit. If nothing more than to help inspire newbies such as myself. I've been kicking around the idea of designing my own games for years but never really got into it. Now that the kids are all grown up and two out of the three are out on their own I have time to dedicate to personal en-devours of my own.
I build web applications for the government which are basically database driven websites that allow end users to input and maintain information. I also do my own freelance web design so hosting isn't really an issue for me (or development). Initial design and then the inputting of the content is where I'll fall short. I see you've all been kicking around some pattern ideas the past couple of posts so that's something to work from.
In my world of programming what you are all trying to describe here is what we call "design patterns" - just sounds like you have a lot more of than we do. Here's the definition of a design pattern:
"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application."
I could give you an example but it would probably look like gobly gook. They have some cool names though like flyweight and singleton and are broken down into categories like: creational, structural, behavioral, concurrency.
I did some computer programming in the past. But the main problem is all the main variations that a mechanics could have.
A more general mechanic could be for example "Auctions", you could refine the mechanic futher with "Close Bid Auctions". But even with a more precise mechanic as "close bid auctions", there are dozens of ways to implement this.
From my experience in design of classification scheme, I realised that sometimes it's better to have a less precise stucture if a lot of people are going to use it.
I think I could do that and people could simply create various pages about various mechanics and place them in the right category. If we end up having too much "Auction" mechanic page, we could subdivide further.
The content will probably have to be fed by crowd sourcing. I could make the structure for mechanics and components classification. I could at most feed the DB with the games in my collection (I don't have really have the time, but I could at least do a few as examples.)
We could end up with something like Wikipedia, where each mechanic, sub mechanic and component has a dedicated page of it's own with links on similar mechanics.
Yeah, I think a wiki like approach might prove best. Still you need some sort of defined structure. Let's approach it as that, a defined structure, and then figure out what to plug it into (i.e. database, wiki, blog, etc).
I have dig up in my paper notes and tried to find what I thought about it many years ago. I could only find 1 page that I scanned and which is available here:
http://lariennalibrary.com/extern/temp/scan_MechanicDB.pdf
I think my idea was to decompose each mechanic in a series of detailed properties that could probably be searched or filtered. Not sure if it could be possible to do, considering some properties could be very subjective.
I used "that's life as an example"
Else, I still think a plain wiki is the way to go.
A wiki would be amazing and very useful. I would gladly help if one popped up.
Like I said, I can supply the hosting, but I have no time to add content to the site besides suggesting ideas.
But I think there was another user that was interested in managing and hosting such site. Not sure if he is still interested.
what about using wikia. It hosts them and is free. I would be glad to write up the proposal and start the page. If you are ok with this I will write up the proposal tonight. If anyone has any ideas for sorting they would want to throw my way the bring it on.
This is not the site that has full of adds?
If adds are mandatory, that could scare people away. (visual pollution)
While if you host your self, you get zero adds. Or adds the way you want them.
If adds are mandatory, that could scare people away. (visual pollution)
While if you host your self, you get zero adds. Or adds the way you want them.
It has a few. Plus that site is already set up to make nice wikis. Just a though though.
 | Build your own [insert game genre here] (9) by larienna |
| Power Creep, a Dungeon Pages adventure (0) by jasongreeno |
| Board Game Blueprint - New Episode Every Wednesday (21) by The Game Crafter |
| Premium Bullet & Premium Toxic Waste Board Game Pieces at The Game Crafter (0) by The Game Crafter |
 | PoA — Major shift back closer to FCE (2) by questccg |
| What “Should” Be in an RPG Design Book (11) by lewpuls |
| Blank Poker Card Sale - 3 Cents Each! (0) by The Game Crafter |
| Blank Playing Cards - Bridge 57mm x 89mm UK (1) by questccg |
| Finally returned after all these years (1) by DyminoMonsters2004 |
| State of the let-off Union - November 2024 (0) by let-off studios |
| Shoppe: The Simulation of Guilds (1) by questccg |
| The fine line between a game and a simulation (22) by X3M |
| Only 24 hours left to bid on games for the Extra Life Charity Auction (0) by The Game Crafter |
| Songs of Conquest is now 60% off plus an additional discount for... (5) by questccg |
| Returned the reMarkable 2 and purchased the BOOX Go 10.3 (3) by questccg |
| Happy Halloween 2024 (0) by questccg |
| Epic Metal Monster Coins - Now on Kickstarter - Created by The Game Crafter (0) by The Game Crafter |
| DuelBotz: Sample New Card (12) by questccg |
| 2 levels for an unit (wargames) (6) by X3M |
| Dragon Spark Playthrough (0) by The Game Crafter |
| New Board Game Pieces - Premium Water Droplet & Premium Blood Droplet (0) by The Game Crafter |
| Designer with an 'almost' ready product (18) by questccg |
| Protospiel Madison - Only 17 Days Away! (0) by The Game Crafter |
| New Board Game Pieces - Premium Milk Bottle & Premium Beer Mug (0) by The Game Crafter |
| Testing chat GPT for mechanics searching (6) by larienna |
Slightly off subject.
In order to put the database on the web, I found 2 software lately:
Kexi, which is an open source equivalent to access.
MiniSQL: which is the database on which kexi run on (which mean 1 file database)
In order to make implementation easier (instead of installing my SQL) at least for testing, I thought I could use MiniSQl and maybe PMwiki to build a database application. I was also intending to do the same for a board game design tracking application. But I have not tested any of these yet and I currently don't have the time. So I am not sure if it could actually work.
As for the classification scheme, I could eventually try to work on it. What bother me the most is that if the database can be feeded by the public, there is a chance that some elements get classified at the wrong place. If this occur, it can lead to double entries, or not finding what you are searching. If it's feeded privately, then it demands a lot of work.