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?
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.
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.
It is a method I am experimenting for myself, that could eventually teach to other. I am exploring other alternative to mechanic searching.
Hmm! I'll take a look, it could be interesting
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++)
Java
Delphi
I never realised that!
But like I said I don't want to make any programming language.
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
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.