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:

[table][tr][td]indicators[/td][td]confirmation[/td][td]outcome[/td][/tr]
[tr][td]courage + skull[/td][td]courage[/td][td]some outcome[/td][/tr]
[tr][td]mind + skull[/td][td]mind[/td][td]some other outcome[/td][/tr]
[tr][td]gift[/td][td][/td][td]a different outcome[/td][/tr]
[tr][td]skull[/td][td]skull[/td][td]another different outcome[/td][/tr]
[tr][td]skull[/td][td][/td][td]yet another different outcome[/td][/tr][/table]

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:

[table][tr][td]2+courage plus skull[/td][td]some outcome[/td][/tr]
[tr][td]2+mind plus skull[/td][td]some other outcome[/td][/tr]
[tr][td]gift[/td][td]a different outcome[/td][/tr]
[tr][td]2+skull[/td][td]another different outcome[/td][/tr]
[tr][td]skull[/td][td]yet another different outcome[/td][/tr][/table]

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?

Thanks,

Paul

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:

[big courage symbol][small skull symbol] [outcome explained in text]

Eero,

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.

Thanks,

Paul

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

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:

[table][tr][td][/td][td]Hand[/td][td]Meaning[/td][/tr][tr][td][/td][td][Bigsymbol][Smallsymbol][/td][td]...[/td][/tr][tr][td]or[/td][td][Symbol][Symbol][Symbol][/td][td]...[/td][/tr][tr][td]not[/td][td][Symbol][/td][td]...[/td][/tr][/table]