Revision as of 01:18, 6 September 2024

Alan said: "Card effects take precedence over the game rules."

• This concept Alan said in english is the function AttachCard(ShadowEraCard card, bool doCallbacks = true):
  1. AttachCard(): When a card is played or attached, the game makes it "linked" to a player, hero, or ally.
  2. During this pocress, if doCallbacks = true, additional logic, such as the card’s effects, is executed.
  3. Callbacks = Card effects: The callbacks trigger specific card effects, such as Rapid Fire allowing a hero to attack twice, or Net Trap disabling an enemy ally for several turns. These effects override general game rules.
  4. Effects > General rules: Once the callbacks are executed, the card effects modify or bypass the standard game rules. For example, the rule "one attack per turn" can be changed by the effect of Rapid Fire.
  5. Thus, AttachCard() and its callbacks manage these exceptions to the game’s general rules, allowing card-specific effects to take precedence when triggered.
• Relation to Traps and Why They Are Not Revealed
  1. The global mechanism for Traps, that they must remain face-down, is integrated into the steps of the Seek process. This mechanism takes priority over other rules, such as revealing a card that has been Seeked.
     
  2. When a Trap is Seeked, the face-down rule (PlayFaceDown()) inherent to Traps is triggered before any reveal function (RevealCard()) can be called. This ensures that the Trap stays hidden, overriding the normal rule that states Seeked cards must be revealed.
  3. This behavior highlights how card effects take precedence over standard game rules. The face-down condition bypasses the normal RevealCard() function, ensuring that Traps remain hidden in compliance with their unique mechanics.
  4. Therefore, while the Seek process normally requires cards to be revealed, the Trap mechanic ensures that this reveal is skipped. The handling of Traps shows how AttachCard() triggers card-specific logic (via callbacks) that overrides the default rules, allowing Traps to stay face-down as intended.
• Intentional or not?
  Yes we may say that the behavior of Traps not revealed after Seek function is intentionally coded by the developers, and here is why:
  
  1. Traps have specific mechanics that are fundamental totheir function: they are played facedown and only revealed when triggered. There is no excpetion; if a Trap is revealed faceup in the graveyard it is because cards are placed faceup in the graveyard; if a trap is returned to hand, nothing says that it should be revealed.
  2. The fact that Traps aren’t revealed during a Seek mechanism follows the logic of the game. The code appears to be structured to ensure this rule is confirmed by preventing the RevealCard() function from bieng triggered for Traps.
  3. Functions like PlayFaceDown() and specific conditions in the code show that the developers have built these special rules for Traps, and they take effect before the standard rules apply.
  4. Now, the following example code would essentially stop PlayFaceDown() from bypassing the reveal process for Seeked cards.
  5. So, if the deloppers of the game wanted to modify the PlayFaceDown() behavior as explicitly stated in the rulebook, they would likely handle the situation easily. It would only require a global phase test.

   if (isSeeked)
   {
       // Allow RevealCard() to be invoked for Seeked cards
       RevealCard(card);
   }
   else
   {
       // Keep the card face-down as usual (normal Trap behavior)
       KeepCardFaceDown(card);
   }

• Personnal Note:

Additionally, after examining the ShuffleDeck() function (located in GameModel.cs -> public static void ShuffleDeck(int side)), there is no "function" evidence suggesting that the deck needs to be shuffled following a Seek function.
Although some cards refer to the shuffle action, the specific mechanism for it is not detailed.