Skip to content

2025‑04‑19 Report

Overview

Today we completed a major refactoring of the core engine modules (play/ and cards/), introduced a robust macro‑driven effects registry, and achieved full test coverage across both subsystems.

Key Accomplishments

  1. Types Templating

  2. Defined CardTemplate(name, cost, type, data) as the single canonical representation for all cards.

  3. Added convenience constructors:
    • Treasure(name; cost, coin_gain)
    • Victory(name; cost, vp)
    • Action(name; cost; kwargs...)

  4. Exposed card_info to merge or isolate raw data fields into a NamedTuple.

  5. Player Module (play/)

  6. Redesigned State struct: added played pile, reordered fields to “noun first,” and adhered to “module‑prefix” naming.

  7. new(deck_starting; deck_shuffle=true) supports optional shuffle.

  8. Provided simple getters: deck_size, hand_size, played_size, discard_size.

  9. Effects Framework

  10. Macro registration: @register :sym fn registers an effect at compile time, warning on overwrite.

  11. Dispatcher: dispatch(card, player, game; args=nothing)
    • Reads card.data[:effects] symbols
    • Looks up each effect via Registry.get (now using Base.get to avoid recursion)
    • Supplies either the keyed value from card.data or the fallback args.

  12. Improved parameter passing by using keyword args and per‑effect defaults.

  13. Cards Module (cards/)

  14. Simplified Registry: Dict{Symbol,CardTemplate} with set!/get/exists/list_cards.

  15. Centralized macro @register :Name expr in cards.jl—no per‑file using needed.

  16. Enhanced SetsLoader.sets_load!(; sets, cards) to support both set‑level and card‑level filtering, matching filenames in lowercase to symbol inputs.

  17. Testing & Coverage

  18. Play tests (test_play.jl): covers Types, Player, Effects, and macro registry without any dependency on Cards.
  19. Cards tests (test_cards.jl): covers Registry API, @register macro, and SetsLoader behavior.
  20. Result: 6 modules, 19 tests, 100% passing.

Next Steps

  • Refactor game/ module
  • Design global game state (supply piles, trash, turn phases).

  • Implement turn flow: Action → Buy → Cleanup.

  • Enhance Effects DSL

  • Support conditional and composite effects.

  • Consider a mini‑DSL or additional macros for complex card logic.

  • Documentation & Reporting

  • Update reports.md with game/ design diagrams.

  • Add usage examples and a quick‑start guide.

  • CI & Quality Metrics

  • Configure GitHub Actions to run tests and publish coverage.
  • Automate daily report generation and badge updates.

Conclusion

The foundation for card definitions, player state, and effect dispatching is now rock solid and fully tested. Tomorrow we’ll extend this core into a full game loop and start wiring up actual gameplay.