Skip to Content

Thoughts on a Board Game Modeling Language

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

The goal here is not to make a universal tool to map any possible board game, but rather make a tool for myself that could facilitate me the design process. It might give a style of board game on it's own which ends up more complex and detailed than regular board games, but since I am aiming for solo board games it does not matter much to me.

Like this discussed in many recent thread, I seem to have problems searching for mechanics and trying to find how to implement concepts. As a ex-computer programmer, when you make a software, you don't have to search for ways to implement your software. There is a method and you apply it. In the computer world, you use relational database models, or UML.

If I were making video games, I could easily implement any thematic idea this way. You simply define concepts, list their properties and define common process that needs to be done with each concept. Then when you have a "Working" software, you can refine and optimise the software to increase efficiency, avoid redundancy, etc.

My objective is to do the same with board games. I don't want to search and test for years for mechanics I could use before having a working game, I want to implement a working game in the initial design, and then refine the game to make it convenient and fun to play.

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

So I am thinking to first start designing like a video game. Create the relational database, and maybe define some process or routines with those data. I am currently making a test to see how it could work, I will make an article later abour it. During this process, there are some design desicions to take according to the features you want.

When I have my data model, I now try to convert it as a board game model. During this second steps, there are other design decision to take which are less systematic. This is where the compression phase takes place. From what I have experienced so far:

- Remove variables that seems non important or too hard to implement
- Change variables as constants, if there is no convenient way or interest to keep track of it as a variable.
- Change the position of a variable somewhere else for being more convenient.
- Determine on which type of component (card, token, etc) the information will be displayed
- Determine if the a variable should be visible by everybody, by the owning player, or by nobody. This will impact components used.
- Reduction of values: Change the range of values from let say 1-100 to 1 to 5 for conveniency.

I only worked with data so far, I did not try to work with process (rules) which should be another important half of the process. I started with what I am familiar with. But so far I seem to be able to put on the table a working game by simply following a process.

I am sure that after playing my first game, there will be some optimisation and simplification to do, but at least I should have something to work with. I might test if adding or removing new concepts to the game could be done by changing the relational model and then propagating changes to the board game model.

Do you think that could be a viable method for desiging board games?

Do you have any suggestions I should explore?

Zag24
Offline
Joined: 03/02/2014
Are you talking ...

Are you talking about a program which you use to model board games? Such a thing would be cool as a prototyping and play-testing tool, but it's probably too hard to make it complete. After all, if you haven't accounted for someone's new mechanic, they are stuck.

If you simply made a really good framework that is extendible, then only programmers would be able to use it.

If you really wanted to spend four or five full-time person-years on development, then you could have something pretty awesome. You'd have to have a bunch of standard components and make it easy to define them, but make an actual programming language for rules. (Nothing less would cut it, I'll bet.) Then there's multi-player, including timing, etc. The ability to program at least simple bots. All in a general purpose tool that could represent everything from Seven Wonders to Lords of Waterdeep to Dominion with some of the funkier expansion packs. Don't forget games with turns made up of phases, games with simultaneous actions, games where pieces change owners or have no owners. Yikes. I'm going to increase my estimate on person-years of development.

Of course, to be successful, you'd have to have integration with The Game Crafter, DriveThruCards, etc. so people could upload their game directly once they were done testing. Add another half a person-year.

In the class I used to teach -- Advanced Object-Oriented Development in C++ -- I used to give an assignment to design a framework with which people could program card games with minimal effort. I'm just talking about games played with standard ace-through-king playing cards. I actually had someone try to implement that as their final project, and he couldn't believe how the project requirements grew out of his control. He ended up just implementing Crazy Eights and Gin Rummy, and that was pretty good. When I asked him about Go Fish he gave me a dirty look. (... because it has an entirely new mechanic, the player asking another player for cards.)

But hey! Don't let me dissuade you. I'm a crusty old software engineer with too much experience, left paralyzed by insurmountable opportunities. Ummm, good luck!

McTeddy
Offline
Joined: 11/19/2012
To be honest, I'm kind of

To be honest, I'm kind of with Zag. A framework could be a useful possibility, but anything more than that would be a MASSIVE undertaking.

While I've seen some useful board game programs such as ZunTzu or Vassal, they rarely enforce much BECAUSE of the difficulties of programming every possible mechanic.

If you're extremely experienced you could probably create a decent visual scripting system, but it would take quite a bit of time. I've been doing game programming for 20 years and I still hesitate to start a project more complex than a CCG.

- - -

The other option is what most of us video game devs do. Build one small game that uses some reusable functions that you'll plug into later project. After a few dozen games you can have a decent set of tools to assist your programming.

- - -

But realistically, I don't think many people will use the tool.

Learning how to use advanced tool-sets will require a large time investment when they could just use index cards and a pen.

If it helps YOU as a designer, it could be worth doing. But I'm not sure there is much of a market for the tool.

DChristiany
Offline
Joined: 04/23/2014
Machinations

I'm not sure if this is relevant, but the closest thing to UML I know of in game design is http://www.jorisdormans.nl/machinations/

I have no experience with it, so can't comment on that.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Quote: Are you talking about

Quote:
Are you talking about a program which you use to model board games? Such a thing would be cool as a prototyping and play-testing tool, but it's probably too hard to make it complete. After all, if you haven't accounted for someone's new mechanic, they are stuck.

Not necessarily a program, a piece of paper could work fine. I don't intend to map thing universally. Like I said, it could create a specific style of game on it's own. The purpose is not to model any kind of board game possible.

The goal avoid mechanic searching which is very unreliable since if could take from 1 week to 10 years to find the mechanic you need. I want to devellop ideas, not stumble upon ideas.

Quote:
If you simply made a really good framework that is extendible, then only programmers would be able to use it.

A framework could be a useful possibility, but anything more than that would be a MASSIVE undertaking.

Having a board game programming language would be interesting though, wouldn't it? To be able to just code out your board game using a recognizable language.

I DON'T WANT TO DO ANY PROGRAMMING. Only the conceptual model is tranformed as a board game. But once the board game is complete, if you want to port that idea as a video game, it should be much more easier because the core structure was a relational/object database.

Quote:
If it helps YOU as a designer, it could be worth doing.

It is a method I am experimenting for myself, that could eventually teach to other. I am exploring other alternative to mechanic searching.

Quote:
I'm not sure if this is relevant, but the closest thing to UML I know of in game design is http://www.jorisdormans.nl/machinations/

Hmm! I'll take a look, it could be interesting

Quote:
1st Designer: "I wrote my board game in CATAN."
2nd Designer: "What!?! That's so outdated! Learn BRASS, it's a much better language."
1st Designer:"But it's so low level."
2nd Designer: "Wow, you're such a n00b."
3rd Desginer: "GOA r0xxx333eerrrzzzzz."

Ha, Ha, Ha! I prefer C++ (CATAN++)

Quote:
Boardgames that are also programming languages - sort of

Java
Delphi

I never realised that!

But like I said I don't want to make any programming language.

Quote:
It sounds like the "Data" for this process would be thematic elements. This would cover resources, political factions, currency, structures, etc.

This Data would then be organized in some way. Methods of obtaining or trading for resources, physical layout of locations on a board, methods used to build structures, etc.

For example, I am esperimenting with a solo ww2 pacific game right now. So you could have in your game the following entity with attributes:

Fleet: Location, fuel, Morale, Fatigue,
Ship: HP, Strength, weapon type, ship type, cargo, experience
Bases: Name, location, Defense, Troops, supplies, planes,

With this you create the object or relational database model. Ships are located into a fleet.

I realized that the "Process" related to each object is somewhat related to the commands those entity could make (generally displayed as a menu in video games). Else it's simply the turn order like found in board games. So for example:

Fleet (Actions done at the sea): Move, dock, Rest, Attack
Bases (Actions done docked at a base): Rest, Repairs, Infiltrate, Steal,

Turn order for each turn would be something like
A- Do an action for the day
B- Time increases by 1 day and update the board

Quote:
Once organized, there would be some way to optimize how the data was presented. Resources become cubes, currency chits, structures cards, and so on.

Once all that is completed, then the Process (rules) can be applied to overlay these basic thematic components.

Then the conversion from database to board game takes place, first fitting the information on components:

Fleet: Dashboard with tracks
Ships: Rectangular tokens
Base: Rectangular area on the edge of the board, or cards

For each attribute, you try to see how they could be transposed:

Fleet:
Location: Pawn on the map
Fuel, Morale, Fatigue: Variable values: A token for each attribute placed on a track from 1 to 10.

Ship:
HP: Use a die on the ship to keep track of damage.
Strength: Fixed value
Weapon type: Fixed, use an icon
Ship type: Fixed value, use an icon
Cargo: Use a token on the top of the ship, OR place on fleet dash board, nb of token must not exceed cargo limit.
Experience: Move the value in the fleet. Record EXP for the whole fleet instead of individual ships (use token on track)

Bases:
Name: Print on map and edge of board
Location: Marked on the map.
Defense: Fixed Value
Troops: Use a die or tokens to keep track of troops available.
Supplies: Do not keep track, use an "unsupplied" marker if supply lines are cut.
Planes: Do not keep track of nb of planes, rather keep track of airport size available, it will influence nb of planes in air strikes.

You can then translate all the actions listed above as board game rules. This will be all the thing the player will be able to do on his turn. Then you can add other rules found in the turn order, like updating the board.

So in theory at this point, you should have a working game. Not a fun and good game, but at least, you can play it. Then while playing it you will see issues like variables that does not changes enough, or some process that takes too much game time to manage, or some things which are simply not fun. From there you could make some modification, add and remove stuff to eventualy make the game convenient and fun to play.

Hope it makes more sense now. I'll eventually make an article of a complete example when I am done with my game idea.

X3M
X3M's picture
Offline
Joined: 10/28/2013
This one time

I once tried to map out all the possible damage calculations that there are in games (video and board).

I faced the following problems:
- I didn't know what is out there, so I needed help. At least I knew the ones that I already discovered by playing.
- Some theory of the calculations and the actually calculations (happened in video) didn't match up. So while one was described, the creators actually applied another one. Warcraft2 was one of such games. Some sites still differ in how it is calculated.
- Naming. How to name a certain calculation? I think with what you are trying to do. It will be much more of a problem. Perhaps naming the game where is comes from.
- Date. Very important since some games are still changing over time. For example, the damage tables could change. So each one would be getting a date?

Perhaps you faced similar problems already?
The only advice that I can give is deal with one board game at a time. Then disect is completely and place it in your library. Don't try to map groups of mechanics like the damage calculation. Since there are way more games out there then there are mechanics in one game.

After a while, you will probably face grey area's just like how Pluto is now not a planet any more. Then you need to add new rules to how you map things.

Syndicate content


forum | by Dr. Radut