Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deck validation #2

Closed
AlphaKretin opened this issue Dec 6, 2020 · 5 comments
Closed

Deck validation #2

AlphaKretin opened this issue Dec 6, 2020 · 5 comments
Labels
enhancement New feature or request

Comments

@AlphaKretin
Copy link
Contributor

Recording rambly self-notes from Discord
OK, I think I need to more thoroughly plan how I'm going to go about these legality checks
I'll leave aside histlander for now, still
In fact while I'll try to make it extensible, the most immediately necessary use is only one format
There are at least three different axes I can think of to validate a deck on
Deck size - in a master duel that's 40-60 main, 0-15 extra, 0-15 side. To allow e.g. speed that shouldn't be hardcoded
Cardpool - for TCG, that means checking no OCG or unreleased cards. This is something that should be highly configurable because tournaments will often have the purpose of trying out a new product that isn't quite official yet, or Ignis is slightly behind on publishing its release
Banlist - this is also something tournaments often wish to customise
It needs to not just check that the restraints are met, but enumerate any and all deviances from those restraints
Length is fairly simple to both check and report
Cardpool can rely on the scope field in ygopro-data for now, with the option to include a list of cards that should override scope and be considered legal/illegal as appropriate
ygopro-data also technically provides banlist data iirc but it's awkward. Again allow users to provide overrides

@AlphaKretin AlphaKretin added the enhancement New feature or request label Dec 6, 2020
@AlphaKretin
Copy link
Contributor Author

About to upload a minimum viable version of this based on current Emcee usage, but will need much expansion in the future

@AlphaKretin
Copy link
Contributor Author

and by "about to" i mean after half an hour of writing test cases and rebuilding decks that had 3 called by the grave because konami makes good banlist decisions

@kevinlul
Copy link
Contributor

kevinlul commented Dec 6, 2020

This is 100% bound to ygo-data so I will look at the vector idea again and put the coupling on a translation interface, which should also enable a YGOPRODeck data source.

@AlphaKretin
Copy link
Contributor Author

AlphaKretin commented Dec 8, 2020

Update on this: Card information is now entirely decoupled from ygo-data, using a bespoke card interface that the end-user can wrap any data source to. Users can also choose one of several predefined card pools when constructing a deck for it to be validated against. The only non-histlander aspect left to implement here is entirely custom card pools (and deck size if we decide it matters).

@AlphaKretin
Copy link
Contributor Author

in fact I might close this issue since it's beyond MVP at this point, and open more specific issues for card pools and histlander

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants