some kind of mathematical notation?

Started by Paul Czege, January 31, 2011, 08:48:08 PM

Previous topic - Next topic

Paul Czege

My current game design project has resolution mechanics that involve drawing tokens of various types from a bowl, and interpreting the combinations against a menu of possible outcomes. Some of the token types are Courage, Mind, Skull, Silence, Gift. My current method for representing the combinations in the "menu" is a table that shows the "indicators" and the "confirmation" for each outcome. Like this:

courage + skullcouragesome outcome
mind + skullmindsome other outcome
gifta different outcome
skullskullanother different outcome
skullyet another different outcome

A player always draws just four tokens from the bowl. Often you can "buy" only one outcome from the menu with the specific combination of tokens you pulled, but you can sometimes "buy" several outcomes that only require one or two tokens.

You need one of each token type listed in the first column. These are the "indicators". And you need at least one, but can have multiples of the token type listed in the second column. These are the "confirmation". There's a full sheet of these outcomes (twenty in all), so they cover lots of possible token combinations.

Here's my question. I'm second-guessing this presentation. I was thinking it was more like a menu, and so, less threatening than something that looks like a mathematical equation. But now I'm thinking I should at least consider a presentation that looks more like mathematical notation. Something like this:

2+courage plus skullsome outcome
2+mind plus skullsome other outcome
gifta different outcome
2+skullanother different outcome
skullyet another different outcome

What do you think? Is that harder or easier to use when you're staring at the four tokens you've drawn and need to figure out which of the twenty possible outcomes they satisfy? Is there a cleaner mathy-like notation than what I came up with? Or some other presentation I should consider?


"[My Life with Master] is anything but a safe game to have designed. It has balls, and then some. It is as bold, as fresh, and as incisive  now as it was when it came out." -- Gregor Hutton

Eero Tuovinen

Clarification for your rules explanation: are you allowed to have 2+ tokens that are not the confirmation for your chosen option?

This is not a random-access list, as I understand it: you do not take up the list at some point in play and choose an option from it so much as you compare a given input (the tokens) against the chart to find out which outcome matches the input. The tricky part is that the user still has to browse through the entire list to confirm that his list of options is exhaustive. This latter bit is what makes the game procedure potentially frustrating, as it takes time to scan through the list and remember that you can now choose between options A, B, C... and D, apparently, and E. Ideally your representation makes this process as easy as possible.

The first thing that occurs to me is that the best interface for this sort of thing would be computer-based: the optimal tool for this would be a filter function that'd simply filter the applicable options from the master list. Very simple to create and rewarding to use, as we know from many common applications. Unfortunately this is probably only a secondary representation, if that, for your game.

Considering paper layouts, it might be worthwhile to create multiple look-up tables, depending on the internal logic of how the options split up between symbol combinations. For example, if having 2+ tokens of a given type gives you access to a certain set of options that use the token in question as confirmation, then perhaps listing those separately under their own header would make it quicker for a player to find what they're looking for. With four tokens the situation is always that either you don't have any confirmation (in which case you don't need to browse through actions that need confirmation), or you have one, or you have two; if the tables were split accordingly, you could just go to the correct subtable for your hand and consider a more manageable list of options. It wouldn't hurt to list the same option multiple times under different tables as well, of course.

As for the specific representation, I strongly favour the second take; the first one with "indicators" and "confirmation" is not as understandable at first glance, as it's not clear whether the requirement for confirmation is in addition to the indicators requirement, and it's also not clear whether you're allowed to have multiple tokens of a type that is not confirmation. (You'll notice that the first of those misunderstandings makes perfect sense if you also assume the second - the table is not clear on whether "confirmation" is a permission to have multiple tokens of that type or requirement to have more than one.)

What I'd probably do myself here with the presentation would be to make it graphical: your situation is basically that all of your options require either a "small" (at least one) or "big" (at least two) amount of a particular symbol, so you could simply make your list accordingly; instead of words, use symbols like boardgames do:
Quote[big courage symbol][small skull symbol] [outcome explained in text]
You could represent the "bigness" in graphics by literally using two sizes of symbols in your layout, or by color (or grayscale shade), or even by typesetting two identical symbols together to indicate the "2+" requirement - whatever, as long as it's easy to pick out the symbols from the list.

Interesting mechanic, by the way. Sort of an extended take on Bacchanal. I think this is a development of that barbarian game you wrote for some contest a couple years back.
Blogging at Game Design is about Structure.
Publishing Zombie Cinema and Solar System at Arkenstone Publishing.

Paul Czege


Yes, it's very much a descendent of Bacchanal. And yes, to clarify, it's one each of what's listed in the indicators column (multiples not allowed), plus one or more of what's in the confirmation column.

Also I really like the "big icon" for two or more and "little icon" for just one suggestion for doing it graphically. It's exactly the sort of suggestion I was hoping for. "Don't do that you idiot, do this instead." I'll almost certainly do it this way. It will work for almost all of the options in the menu.

But a few of the options will need special treatment:

  • Two of the options have "or" situations in the indicators column, where any single one of three different tokens can be the indicator.
  • And two of the options have something like "you can't have any Skulls among the tokens you drew" for the confirmation.

I have thoughts for how I might handle these graphically. But I don't want to taint you with my ideas before hearing how you might do it, because you're clearly more clever at this kind of thing than I am.


"[My Life with Master] is anything but a safe game to have designed. It has balls, and then some. It is as bold, as fresh, and as incisive  now as it was when it came out." -- Gregor Hutton

Ron Edwards

I'm not Eero, but ...

- the multiple alternate eligible symbols could be done in an indented column with "or's" leading them

- the ineligible symbols could be listed with little X's over them

Best, Ron

Eero Tuovinen

Could also do slashes for "or", like [symbol]/[symbol]/[symbol]. After all, remembering the mark-up won't be a problem for the player once he's familiar with the table, so it can be a bit esoteric. That's a difficult exception, though, so it's probably best to explain it in a footnote. For instance, one might wonder whether you're allowed to have several of the options in your hand, or if you can only have one of them for the option to be eligible.

X's over the symbols seems good, although I'd clarify that it's probably better to put small X's above the symbols for clarity's sake if the symbols themselves are at all difficult to differentiate with scribbling over them. One might also use the logic symbol "¬" to indicate negation, but it's a bit out of place in a graphical depiction.

The advantage of intending is that you can put "or" and "not" both in the same position on their respective lines, making for a tidy table. I might do something like this:

Blogging at Game Design is about Structure.
Publishing Zombie Cinema and Solar System at Arkenstone Publishing.