Collectible Card Game Headquarters

I am not sure about reading PrintedCard from individual txt files. All these data can be read fast enough from mtg-data.txt files (by Arch) - this should be faster (without that much io operations), yet we have to track somehow which cards are supported actually.

I'm already in the middle of the way refactoring deck editors, the decks themselves and quest inventory. It looks nice, but will take some time. CardList instances are banned where possible, avoiding to touch heavy Card class with its factories until battle begins.

Please stick to the cardname.txt files. Where would you load the card scripts from? Or the SetInfo? Then you would need a separate list anyway... just use what we already have working.

The PrintedCard for Forge's purposes is lightweight - it only contains strings and maybe a few integers. It essentially encapsulates the cardname.txt in memory. These can be stored in one master ArrayList, but multiple maps could be pre-built with particular keys, like a DB index to make access very quick.

Decklists, quest collections, sideboards, etc. should only store the card name and minimal meta data, like quantity, set code and foiling.

Fully Active Cards only need to exist in the battlefield part of the game.

Rob Cashwalker wrote:Please stick to the cardname.txt files. Where would you load the card scripts from? Or the SetInfo? Then you would need a separate list anyway... just use what we already have working.

The PrintedCard for Forge's purposes is lightweight - it only contains strings and maybe a few integers. It essentially encapsulates the cardname.txt in memory. These can be stored in one master ArrayList, but multiple maps could be pre-built with particular keys, like a DB index to make access very quick.

Decklists, quest collections, sideboards, etc. should only store the card name and minimal meta data, like quantity, set code and foiling.

Fully Active Cards only need to exist in the battlefield part of the game.

this sounds mostly like an agreement to Max mtg's original proposal to me. this is my understanding:

#1 - for deck lists, quest collections, etc.
#2 - load from res/x/{cardname}.txt mixed with mtg-data.txt and store all instances in memory for fast deck editor searches.
#3 - only instantiate when needed in a game.

Is there a need to do double parsing? Is there a disadvantage to having the Oracle text in the cards.txt files?

Hurray! We have agreed on datatypes.

friarsol wrote:Is there a need to do double parsing? Is there a disadvantage to having the Oracle text in the cards.txt files?

I suppose, oracle rules from mtg-data.txt are much easier and faster to parse:
1. read cardname
2. read and parse types
3. if creature, save p/t; if walker, write down loyalty.
4. save everying except last line as rules.
5. last line is sets info.

I have little idea on how can one extract rules from cardname.txt: looks like he should keep the K: lines, get the last part from the S: lines after description$, replace CARDNAME with actual card name... and this is yet the beginning.

friarsol wrote:Is there a need to do double parsing? Is there a disadvantage to having the Oracle text in the cards.txt files?

because we're using a zip file for reading the txt files, i see neither a significant advantage nor a significant disadvantage.

what kinds of Forge-specific information will Max mtg need to add to the #2 style cards? i remember a flag about whether the AI can use the card or not. where do we presently store that information? is there anything else that the deck generators and editors would need?

Max mtg wrote:I have little idea on how can one extract rules from cardname.txt: looks like he should keep the K: lines, get the last part from the S: lines after description$, replace CARDNAME with actual card name... and this is yet the beginning.

Rules aren't yet in cards.txt because I've been holding off running the script I have to extract and add Oracle data to them due to this and previous discussions on this topic. When added there will be a line starting with Oracle: that will have all Rules text of the card.

Braids wrote:this sounds mostly like an agreement to Max mtg's original proposal to me. this is my understanding:

#1 - for deck lists, quest collections, etc.
#2 - load from res/x/{cardname}.txt mixed with mtg-data.txt and store all instances in memory for fast deck editor searches.
#3 - only instantiate when needed in a game.

No, not quite. Only need 2 classes, basically combine #1 and #2. One holds the raw text from the cardname.txt files and is used for display, searching and sorting purposes. The Active one is used only in game.

Decks don't contain objects, they contain plain text, which is why #1 isn't necessary.

Max mtg wrote:Hurray! We have agreed on datatypes.

Not yet...

I suppose, oracle rules from mtg-data.txt are much easier and faster to parse:
1. read cardname
2. read and parse types
3. if creature, save p/t; if walker, write down loyalty.
4. save everying except last line as rules.
5. last line is sets info.

I have little idea on how can one extract rules from cardname.txt: looks like he should keep the K: lines, get the last part from the S: lines after description$, replace CARDNAME with actual card name... and this is yet the beginning.

No need to parse oracle text. We parse cardname.txt perfectly well right now. Just change CardReader.loadCard to not directly instantiate abilities and triggers. Just populate the basic card object with plain text.

The process is advancing well. I came from compile time errors to runtime errors, logical yet to come.

Rob Cashwalker wrote:

Braids wrote:this sounds mostly like an agreement to Max mtg's original proposal to me. this is my understanding:

#1 - for deck lists, quest collections, etc.
#2 - load from res/x/{cardname}.txt mixed with mtg-data.txt and store all instances in memory for fast deck editor searches.
#3 - only instantiate when needed in a game.

No, not quite. Only need 2 classes, basically combine #1 and #2. One holds the raw text from the cardname.txt files and is used for display, searching and sorting purposes. The Active one is used only in game.

Decks don't contain objects, they contain plain text, which is why #1 isn't necessary.

how do we differentiate card art, then? at first, it sounds like you're suggesting that the primary key for a database of #2 instances be {name + set + artIndex}. then we'd be copying Oracle text for every printing of every card. it would be very heap-wasteful. i think the primary key for a database of #2 instances would be just the canonical ASCII card name instead. that would be much more efficient, and easier to perform lookups.

but i think you realize this. so, instead of #1, we just pass Strings around for deck contents? it's fairly standard practice to create an abstract data type {class} from a string with distinct parts: name, set, and art index. i think we should leave this up to Max mtg. i think Max just doesn't want to represent #1 as a single string, but rather break it up into its component pieces.

Rob Cashwalker wrote:No, not quite. Only need 2 classes, basically combine #1 and #2. One holds the raw text from the cardname.txt files and is used for display, searching and sorting purposes. The Active one is used only in game.

Decks don't contain objects, they contain plain text, which is why #1 isn't necessary.

Decks already used by forge do contain objects, by the way, in lines like CardName|Edition... it's somwhat ugly, don't you think so?
In the same way artIndex and foiling might be added separated by pipes, though I would prefer xml for that:

Code: Select all

<card name="Plains" set="M11" artIndex="1" foil="0" quantity="3" />

which can be stored in even more compact form:

Code: Select all

<c n="Island" s="CMD" i="2" q="3" />
<c n="Jace, the Mind Sculptor" q="1" f="1" />

attributes whose values equal zero or can be randomly generated are omitted, thus Jace 2.0 was printed only in one set - may drop its set from tag without problem, so the random set chooser will guess it correclty

I'd prefer JSON to XML. XML is so bloated.

friarsol wrote:I'd prefer JSON to XML. XML is so bloated.

QuestData is saved in XML anyway. As for other decks, unrelated to quest, they don't need to switch and may still use common format.

instead of creating yet another decklist format, i think the mwDeck format would suit our needs.

sample lines:

Code: Select all

SB: 4 [OD] Mountain (2)
1 [WWK] Jace, the Mind Sculptor


`
in regex/BNF:

Code: Select all

deckListEntry := space* (sideboard)? space* quantity space+ "[" setName "]" space+ cardName (space+ "(" artIndex ")")? space* newline
sideboard := "SB:"
space := " "
quantity := postiveInteger
positiveInteger := [1-9]+[0-9]*
setName := [^]]+
cardName := .+?
artIndex := positiveInteger
newLine := \r\n?


`
in extended Perl regex format where spaces are ignored:

Code: Select all

^ \s* (SB:)? \s* ([1-9]+[0-9]*) \s+ \[ ([^]]+) \] \s+ (.+?) ( \s+ "(" ([1-9]+[0-9]*) ")" )? \s* $


group 1 is either "SB:" or empty.
group 2 is the quantity.
group 3 is the set identifier.
group 4 is the card name.
group 5 must be ignored.
group 6 is either the art index or empty.

edit: i'd be happy to create load/save code for this format.
edit2: i know we don't (yet) support sideboards, so group 1 would be empty until we do.