DanDan Variant

[agylesox]

Summary

Implements Dandan as a game mode creating shared zones and match rules in the engine, plus Dandan-specific layout and zone/hand presentation in the desktop client.

---

Gameplay / rules engine

• Match setup: Dandan uses a shared deck and shared Library / Graveyard wiring; sideboarding is disabled for this mode where applicable (forge-game, e.g. Match, GameRules).
• Drawing and zones: Draws resolve against the canonical shared library; zone routing uses the shared player’s zones so all players see one pile (forge-game, e.g. Player, GameAction).
• Rules that touch shared graveyard: Targeting / validity / restrictions account for a shared graveyard so cards there behave correctly for Dandan (forge-game, e.g. CardProperty, SpellAbilityRestriction related to card ownership and card controller rules).
• Canonical “view” of shared zones (engine-side): DanDanViewZones exposes a single consistent card sequence for library/graveyard for UIs and tooling that consume GameView (forge-game).

---

UI / client

• Match layout: Dandan matches use the Dandan layout file instead of the default match layout when rules say Dandan, so the shared graveyard is visible in the middle of the screen (CMatchUI, ForgeConstants / MATCH_DANDAN_LAYOUT_FILE).
• Deck Selector ToolTip: In VLobby, hovering over the deck name now shows the comment in the .DCK file as a tooltip to give the user more information on the specific deck.

---

Out of scope

• Changes to AI to include DanDan specific heuristics for evaluating top of the library.

---

[Jetz72]

Ambitious project. The concept of shared zones seems useful to a few other variant formats (e.g. Shared Planar deck option, Bounty deck), though it looks like your implementation results in a lot of DanDan-specific checks and branches dotted throughout the code. I wonder if the concept can be generalized.

Have you tested the shared zones with more obscure mechanics, such as subgames and Karn's game restart effect?

I feel some things like your deck comment support and game simulation changes could stand alone as separate PRs.

[agylesox]

• I think the Dandan specific checks mostly sit in the CardProperty due to needing to ignore ownership and control when dealing with the shared graveyard. But you are right and I agree, that is clunky. I will see if there's a better way to handle that.
• I did not check how it works with Karn or Shaharazad. I'll check and see what happens. I think one of the discord members has a Shaharazad version that would probably be a good test.
• Deck comment support and Game sim changes - you're right. Those could have been / should have been separate PRs. They got lumped into this because they were tools I needed as I was going along, but I can separate them if that's helpful.

[Jetz72]

• They got lumped into this because they were tools I needed as I was going along, but I can separate them if that's helpful.

Helps a bit by slimming down what needs reviewing here, but also it'd probably get those parts merged faster. I suspect reviewing this will have to wait a bit for most of the team, now that we're in the middle of reveal season.

I think the Dandan specific checks mostly sit in the CardProperty due to needing to ignore ownership and control when dealing with the shared graveyard. But you are right and I agree, that is clunky. I will see if there's a better way to handle that.

Might extract things like getController.equals( into some helper methods, to check if a card or even a zone is owned/controlled by a player. Can pack the weird edge case of shared zones into that and then do some structural searches of the code base to figure out all the places where the helpers can be inserted.

[agylesox]

Have you tested the shared zones with more obscure mechanics, such as subgames and Karn's game restart effect?

Shahrazad does appear to be working in DanDan mode.

• Spawns the sub-game from the parent with the remaining library
• If a sub-game spawns from the sub-game, it spawns with the remaining sub-game library
• Losing a sub-game puts you back to the game that spawned it, with the loser losing half their life. Cards from the subgame are shuffled and become the library of the spawning game and the spawning game resumes.

Playtesting through the UI, I think I got to 4 sub-games deep, including resolving a sub-game, returning to the spawning game and then launching another sub-game.

[agylesox]

I feel some things like your deck comment support and game simulation changes could stand alone as separate PRs.

Moved comment on mouse hover to PR #10263

[tool4ever]

bad artifact