One thing I've realized while designing both my board and card game is that one of the easiest ways to slow a game down is to have a lot of math involved. More specifically, if you have to frequently add or subtract a lot of small numbers. If you have combat in your game, maybe an easy way to figure out who wins is each side has a total strength value and the highest value wins. That sounds simple enough, especially if there are only a few units on each side. However, if you have a lot of units, that combat gets significantly slower when adding all the numbers. This gets even worse if you both add one unit at a time back and forth because you have to keep recalculating things.
Let's give an example. Say you have a combat card game where each player has five card numbers whose values range between 1 and 5 with both positive and negative values. Each player goes around the table and places a card either in front of themselves (to bolster their strength) or in front of others (to weaken their position). The first round is easy enough, generally everyone will have a single card in front of them. The second round isn't too bad, the third may start to get a little confusing, but then the fourth and fifth round get really confusing for anyone who has a bad short term memory or who got distracted when someone else played a card. "I've got 2+1+3+2+4, you've got 3-1+4+5-2, you've got 4+4+3+1+1, and you've got 1+1+2+4+1..." Maybe those calculations aren't hard for you, but if you have to do that every round of the game, it will slow things down. Even worse if those calculations do take you a minute or two.
On top of the calculation slow down, another issue with math heavy game design is you always have to decide what happens with a tie. Who do ties benefit? What if every player somehow tied in something involving more than two players? Of course, this is something to keep in mind while designing any game involving numbers (no matter how few).
I haven't quite figured out a great solution for this issue without imposing (seemingly) arbitrary limits, but it's yet another simple system that overcomplicates a game that I am on the lookout for. I've also been trying to think of any game I've played that has a lot of math involved frequently. The games I can think of that have point addition are at the end of the game like Dominion. The combat games involving numbers are a one number vs. one number affair like Risk or Nexus Ops. Maybe I've just stumbled upon an easy rookie game designer mistake to make?
In my one foray into game designing, I ran into a similar issue. The game was on a hex grid, and I had to-hit rolls be on a d20, minus the number of hexes between the attacker and target; positive results hit. It turns out that counting out how many hexes are between units is really slow. Maybe if I'd done a d10 that would have been better, I don't know.
ReplyDeleteOn the flip side, I think some minimal amount of math is ok. I don't have a problem adding up scores at the end of a game. I overheard a complaint about Lost Cities that the math in it outweighed the fun, and this baffled me. All you do in Lost Cities is add up the cards, and subtract 20. You can't make it any simpler without ruining the implicit bidding part of Lost Cities that makes it so fun. I think that addition and subtraction of integers for score calculation is an acceptable level of math, without slowing anything down. Maybe I'm crazy.
I think it depends on how frequently you're doing the adding and subtracting and how many separate numbers there are to add up at once. I think score calculation at the end of the game is no problem because if that takes awhile it only happens once. But something that happens every round (or for combat games multiple times every turn) probably shouldn't be super math-y.
DeleteIt's basically like in programming if you have a complex algorithm that takes a few seconds for the computer to process. Using it in response to an infrequent event isn't going to hurt your overall runtime, but putting it in the system tick function so it happens repeatedly will add up over time and make a slow program.