Collectible Card Game Headquarters

Came across such code in GUI_Quest_DeckEditor:: public void updateDisplay()

Code: Select all

       // CardList top = readCardpoolAndConvertItToCardList();

        ReadBoosterPack pack = new ReadBoosterPack();

        // update top
        for (int i = 0; i < top.size(); i++) {
            Card c = top.get(i);

            // add rarity to card if this is a sealed card pool
            String cardName = c.getName();
            if (!pack.getRarity(cardName).equals("error")) {
                c.setRarity(pack.getRarity(cardName));
            }

            boolean filteredOut = filterByColor(c);

            if (!filteredOut) {
                filteredOut = filterByType(c);
            }

            if (!filteredOut) {
                topModel.addCard(c);
            }
        }// for


Did I get it correctly that rarity is a function of card's name?
I decided to check that in card descriptions

Code: Select all

Name:Act of Treason
ManaCost:2 R
Types:Sorcery
Text:no text
A:SP$ GainControl | Cost$ 2 R | ValidTgts$ Creature | TgtPrompt$ Select target creature | LoseControl$ EOT | Untap$ True | AddKWs$ Haste | SpellDescription$ Gain control of target creature until end of turn. Untap that creature. It gains haste until end of turn.
SVar:Rarity:Uncommon
SVar:Picture:http://www.wizards.com/global/images/magic/general/act_of_treason.jpg
SetInfo:M11|[b]Common[/b]|http://magiccards.info/scans/en/m11/121.jpg
SetInfo:M10|[b]Uncommon[/b]|http://magiccards.info/scans/en/m10/124.jpg
SetInfo:M12|[b]Common[/b]|http://magiccards.info/scans/en/m12/121.jpg
End

As this example shows, card rarity varies from one set to another, and it must not be a property of card nor be a function of card's name.

So I suggest the card rarity should be considering only being tied with a set the card belongs to
and Card.set/getRarity be replaced by more flexible solutions.

Just a note: Unless each printing of a card would be shown seperately (which is not very practical), the deck editor would need to display the combined rarities like C/UC or UC/R (and sorting for rarities needs some more work).

Sloth wrote:Just a note: Unless each printing of a card would be shown seperately (which is not very practical), the deck editor would need to display the combined rarities like C/UC or UC/R (and sorting for rarities needs some more work).

The deck editor won't cards as operate strings alone anymore. It will have a set of CardReference (CardInInventory) structures, where name+set+index are defined (while function rarity(name,set) gives us a single result). So there won't be any combined rarities.

Max mtg wrote:

Sloth wrote:Just a note: Unless each printing of a card would be shown seperately (which is not very practical), the deck editor would need to display the combined rarities like C/UC or UC/R (and sorting for rarities needs some more work).

The deck editor won't cards as operate strings alone anymore. It will have a set of CardReference (CardInInventory) structures, where name+set+index are defined (while function rarity(name,set) gives us a single result). So there won't be any combined rarities.

This sounds annoying. Each different printing of a Swamp from each Set would show up separately in the Deck Editor? There are probably around 100+ different printings of each Basic Land, if you keep getting a Unique one each time you buy some, it can just fill up a massive amount of your Editor with repetitive, unnecessary extra information.

friarsol wrote:This sounds annoying. Each different printing of a Swamp from each Set would show up separately in the Deck Editor? There are probably around 100+ different printings of each Basic Land, if you keep getting a Unique one each time you buy some, it can just fill up a massive amount of your Editor with repetitive, unnecessary extra information.

Yes, it will show up as a separate entry. When you have a small collection that is not a problem. When it's larger, just use appropriate filters, you'll need them anyway to find one card of several hundred cards you've collected during your quest.
The only case when all 100+ different printing would appear is in deck editor outside of quest mode, when you choose among all the cards ever printed in Magic. There would be 10k+ records and basic lands won't be consuming most space. But, anyway for that case a 'hide reprints' option will be in its place.

I already came across refactoring of DeckEditor for quest mode, and I want it to avoid using those huge Card class instances. I need to create CardOracle class (#2 from the topic for issue 157), fill them with card descriptions (looks like I'll have to read Arch's mtg-data.txt) and use these objects for displaying general information about cards in the datagrids and previews on the right side (both classes should accept CardOracle in their setCard methods)

Well, does anyone still need SVar:Rarity?

There may be a couple holdouts in the code that uses the SVar Rarity as opposed to the set rarity. Most likely they can be converted, however, all code that checks a card's SetInfo needs to assume that that data may not have been assigned to that card object yet. So if there is no current set assignment, always assume it's the most recent printing.

Without significant changes, Basic Land from different sets should be avoided. Even in regular constructed mode, you could build a deck with 1x land from each set, and the editor would be filled with each individual card. The resulting deck file will be confusing as well.

Rob Cashwalker wrote:There may be a couple holdouts in the code that uses the SVar Rarity as opposed to the set rarity. Most likely they can be converted, however, all code that checks a card's SetInfo needs to assume that that data may not have been assigned to that card object yet. So if there is no current set assignment, always assume it's the most recent printing.

Without significant changes, Basic Land from different sets should be avoided. Even in regular constructed mode, you could build a deck with 1x land from each set, and the editor would be filled with each individual card. The resulting deck file will be confusing as well.

How is it possible for a card to have setinfo unassigned? Isn't that info loaded together with card name and rules, is it?

Why should they be avoided? People are spending time and money to obtain basic lands from special editions in RL. They collect Zen full-art lands, they pay $20 for full-art foils from UN- sets. They would not do this if it had no sense and was to be avoided. Do you mean to say that Forge should not provide this experience of collecting preferred prints of lands, building a deck with them and being proud of it?

As for significant changes - there's no problem, I am able to code them.

SetInfo is loaded when read from the file, but a specific Set is not assigned until the card is loaded for battle, or is read from a deck file. Look at all the references made to dealing with SetInfo across Forge. Notice they all check to see if it's currently assigned, if not, assign it then.

Avoid it for the reasons mentioned.. clutter in the grid and clutter in the deck files are good primary reasons. Enforcing particular cards to be foil or from particular sets isn't secure, just edit the deck file.

Rob Cashwalker wrote:Avoid it for the reasons mentioned.. clutter in the grid and clutter in the deck files are good primary reasons. Enforcing particular cards to be foil or from particular sets isn't secure, just edit the deck file.

Clutter is a consequence of poor visual design. Magic Online has all that features (foiling, sets, variants) and thousands of ppl play it.

The main objective of this foiling and set assigment is improvement of quest mode, to make some nice rewards.
Any software run on a client's computer is insecure by definition, because its user can edit files / disassemble code / modify memory.

Magic Online has all that features (foiling, sets, variants) and thousands of ppl play it.

Forge is not Magic Online.

As a reward, sure, it's cool, there may only be a handful of those cards in any given quest. Other than that, it's not worth it.

Max mtg wrote:So I suggest the card rarity should be considering only being tied with a set the card belongs to
and Card.set/getRarity be replaced by more flexible solutions.

why not make it the lowest rarity level at which the card was ever printed? for example, Ajani Goldmane would be rare, not mythic, because it was printed in Lorwyn as a rare.

edit 1: i have to side with the "way things are", that being extremely specific about a card's set is too much of a bother. i don't like the idea of having to download a low-res image of every card in every set, especially since those images are nearly identical. this isn't Magic Workstation; it's Forge. i prefer the images res/pics directory to be flat {except maybe indexed by first letter of card name, like cardsfolder's .txt files}. if a user likes a specific picture, s/he can download it manually and replace an existing one.

edit 2: it would be ultra nifty if i could right click on a card during a game, be able to see the different pics for that card that are available {downloaded on the fly from magiccards.info perhaps}. and choose one as my favorite, thus automating the process in edit 1.

Braids wrote:why not make it the lowest rarity level at which the card was ever printed? for example, Ajani Goldmane would be rare, not mythic, because it was printed in Lorwyn as a rare.

Why not the highest? I can't see any reasons behind either variant.
For pauper format, for instance, they consider the most recent rarity.
Anyway, rarity is a property of card-in-set, not card itself.

Braids wrote:edit: i have to side with the "way things are", that being extremely specific about a card's set is too much of a bother. i don't like the idea of having to download a low-res image of every card in every set, especially since those images are nearly identical. this isn't Magic Workstation; it's Forge. i prefer the images directory to be flat {except maybe indexed by first letter of card name, like cardsfolder's .txt files}. if a user likes a specific picture, s/he can download it manually and replace an existing one.

Does the project being Forge mean we have to restrict cards to have only one image?
There already is an option in menu "Download LQ Set images" - that's exactly what I am going to use... in case there are any images. If not, fallback to img from flat storage.

Max mtg wrote:Does the project being Forge mean we have to restrict cards to have only one image?
There already is an option in menu "Download LQ Set images" - that's exactly what I am going to use... in case there are any images. If not, fallback to img from flat storage.

no, but it means we don't have to strive to the same level of perfection as Magic Workstation. MWS was partly meant to be an inventory management tool. Forge is not.

ok, i guess as long as i can keep my flat {or somewhat flat} storage, i won't complain.

One of the primary reasons for the SetInfo is to facilitate proper formats for Drafting. To build a pack, you need to know the rarity from that set.. 9th edition Serrra Angel is rare, but is now uncommon. (Figured, half-a-year prior, I had just picked up heavily played Revised printings for cheap)

A side benefit was the ability to deal with set-based pictures. So when you're drafting M12, you don't see the Revised Llanowar Elves, which kinda ruins the experience for most folks. If the set-based picture isn't found it always reverts to the single-picture if present. It may be a simple tweak to check folders with the first letter before looking in the main folder.