Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Hi! I think that the rules (and the developer rulings) in this case are quite clear. You should do as much as you can, even if that means only spending one or two resources. In fact, the rules (version 1.6) for the Choose keyword say: 

When an encounter card requires a player to choose an option, they must choose an option they can resolve. If they cannot fully resolve any option, they must choose the option they can most fully resolve.

This is specific for encounter cards. It is not the same as spending resources for an action or to pay for a card (in which case I agree that either you can or cannot). 

Thanks!

(1 edit)

Hi @quantumodo,

Thank you for your reply.

While we acknowledge the FAQ addresses this issue, we believe the resolution method is not correct. The card “01123” is unique in its ability to ask players to spend resources or perform actions that may not be possible. Other effects do not combine resource spending with potentially unresolvable actions, such as “16078,” “16146,” “02046,” and “40072a.”

Consider an encounter card that reads:

Choose one: 1. Spend [energy] resource 2. Spend [physical] resource 3. (an action you cannot perform).

If you have two cards in hand - one generating energy resource and the other generating physical resource - both options 1 and 2 can be resolved. In this case, what should the engine do if the player clicks Cancel?

Now, imagine you have only one card, “50014,” in your hand, and you are playing as “03001b” with two allies in play, “08012” and “52033,” both of which have the “S.H.I.E.L.D” trait. This means “50014” can generate energy resource by exhausting “08012” or physical resource by exhausting “52033.” Again, what should the engine do if the player clicks Cancel?

Additionally, the engine is not human and cannot determine which option the player “can most fully resolve.” Coding for every possible situation would be challenging, especially as FFG continues to update the rules.

We believe the engine should not attempt to decide which cards to spend as resources without consulting the player when they click the Cancel button. The player’s hand is hidden information, and the engine should not make assumptions about it.


Additional Information About Effects

An effect has three parts:

  1. The operation
  2. The targets
  3. The cost

Spending resources is the third part of resolving an effect; it is not the entirety of the effect.

“01123” reads:

Either spend [energy] [mental] [physical] resources or exhaust each character you control.

This creates two effects for the player:

  1. Effect 1:

    • Operation: None
    • Targets: None
    • Cost: Spending resources
    • The “can most fully resolve” rate of cost is unknown because it involves spending resources, and the outcome will only be known once it is attempted.
    • The “can most fully resolve” rate of targets is 100% since it does not require a target.
  2. Effect 2:

    • Operation: Exhaust targets
    • Targets: Each character you control
    • Cost: None
    • The “can most fully resolve” rate of cost is 100% since there is no cost.
    • The “can most fully resolve” rate of targets is 100% if you have any characters to exhaust, or 0% if you do not.

As you can see, coding an algorithm to compare the “can most fully resolve” rate is complex due to the lack of a standard rule.


What are your thoughts on this? If you have a different perspective or additional insights, I’d love to hear them.

Thanks for the explanation. I agree that implementing this can be very difficult if you wnt to address the more general situations. As a compromise, I think that it would be OK (at least, for me) if you let the players decide to resolve one of the options partially if they can. I will choose that option on my own to stick to the rules, even if the app allows me to choose not to fulfill any.  

This may not be the best solution but, what if there is a way to manually discard cards from hands (and draw), as a backend option or developer backdrop, something hidden as a last resource solution in case something like this comes up.