I am beginning to think that the apparent economy of the “(x)” construction is illusory, and that the space it saves is not worth the cost it demands in player memory/attention. Feel free to move this into the RB thread if you think it fits best there, but as it’s more UX/UI than rules intepretation, I thought to open a new thread and sketch out my experience.
The “(x)” construction saves (often minimal) space on cards but functionally increases the rules overhead placed on players, because it is ambiguous. I assume the intention here is that players will eventually snap onto a thematic interpretation of the keyword (e.g., “Bolster” enemies before combat). But in practice, what this amounts to is requiring the player to memorize multiple interpretations of the same abbreviation AND the contexts in which each is correctly invoked. At a skim, I count 6 distinct uses of the (x) construction
- Set target skillcheck/Progress values, as in check MUSCLE(3)
- Save 2 text characters by not typing “HP” as in Raise(x) and also Heal(x)
- Specify a number of cards to draw, as in Bolster(x)
- Specify a number of cards needed to trigger an Ability, as in Equip(x)
- Specify a keyword to look for when drawing cards, as in Discover(x) and Spawn Faction(x)
- Specify the character targeted by a status effect As in Entangle(x), Sunder, Stun, Weaken)
The only place the ambiguity seems to be recognized at time of writing is in the construction “(x Time)”, which overtly specifies the value that x refers to. I think Uses 2, 3, and 5 above are ripe for similar specification: “Raise x HP”, “Bolster with x equipment cards”, “Discover Item with x keyword” etc. The (x) construction might, indeed, be largely abandoned in such cases to reduce its overall ambiguity and improve clarify of the relevant cases.
You might also consider enriching specificity by not using round parentheses every time. Let (x) specify a target value as in skillchecks. Let [x] specify a number of cards. Let <x> specify a targeted character. Let {x} specify keywords. Or something like that. I’m not thrilled with this option since it really just tacks on an additional formalism in recognition that the existing one is ambiguous. It’s the equivalent of swapping (x) for (x)*, (x)**, (x)*** etc . But it might aid some lookup. And there’s something a little iconic about using square brackets for a cardcount.
I’ve been trying to find a good way to underscore the issue here. One way to capture part of it is that in all these cases, what you essentially need to communicate to the player is a Subject, a Verb, an Object, and sometimes a Quality. The Subject is essentially always the Player who is being told to execute some rules-driven upkeep. The keyword that comes before (x) is almost always the Verb – but notably, not in Equip(x) as best I can see – it is very un-intuitive to my ear to use the imperative verb “Equip” to mean not “actively assign/distribute equipment” but instead “trigger an ability if a sufficient amount of equipment has already been equipped.” Likewise (X Time) omits the verb completely. Use-cases like 6 above show (x) clearly referring to the Object of an action. Use-cases like (5) above show (x) clearly referring to a Quality of the denizen to be spawned.
In general, I think the grammar of natural language has got all this pretty well nailed down, and I think it generally impairs learnability to flout/collapse those critical distinctions, as “(x)” seems to do. I’m not saying I won’t be able to memorize all this – but I would really prefer not to have to.