Collectible Card Game Headquarters

Dear friends,
While I'm still having some moderately tough time at work (and as such unable to get down to my potentially most ambitious AI improvement/AI profiles project), I decided to take on a smaller-scale Forge project first, and that is going to be improving the usefulness of Foil cards in Forge. As such, here's the thread for brainstorming ideas and for WIP progress reports.

RATIONALE: As of right now, support for foil cards in Forge is really basic. There is no way to actually have a specific foil card in a deck, no way to buy a foil card in a quest shop, no foil cards appearing in boosters, and no price distinction between foil and non-foil cards. The only way to see foil in Forge is to enable the Random Foil option which randomly foils random cards with a certain chance, regardless of the set the card is from (Alpha foils, anyone? ).

PROPOSED IDEAS: For starters, I plan to take the following steps one by one to ensure the basic support for differentiation between foil and non-foil cards. Further steps may later be taken (by me and/or someone else) to add actual foil card support to quest mode, boosters, deck editor (sorting by foil/non-foil), etc.

1) Improve the deck format to support foil cards. Ideas are welcome as to how to best do it. Right now my idea is to add a special suffix to the line specifying the card which, if present, will indicate that the card is foil:

Code: Select all

2 Tarmogoyf          // two normal Tarmogoyfs, random set
1 Tarmogoyf|{F}      // foil Tarmogoyf
1 Tarmogoyf|MMA|{F}  // foil Tarmogoyf from the MMA set


Potentially, if necessary, this may open up the possibility to specify cards with specific art index using similar suffixes (e.g. the digit 3 in braces to specify art index 3) - we'll see if it's going to be a possibility.

2) Make the game recognize foil cards in the match according to the suffix specified in the deck file, and foil the card on the battlefield accordingly (could be a simple matter of setting isFoil, or whatever is currently used for random foiling, when loading the deck).

3) (Maybe) consider separating the modern and pre-8th edition foil card styles (instead of using one foil card sheet, use two foil card sheets, one for the modern post-8th edition cards and the other for the old style pre-8th edition cards - that'll potentially allow someone to come up with separate graphics for the foils; as far as I remember, pre-8th edition foils only had the border and the star logo foiled as opposed to the entire card).

4) Implement the restriction for which sets support foiling and, if so, which foil sheet they should be using. Since we already have a very nice set of definition files for MTG editions and sets (I mean the data files in the "editions" folder), this can be easily implemented as an extra parameter there, something along the lines of:

Foil=NotSupported // e.g. for LEA, 4ED
Foil=OldStyle // e.g. for 7ED
Foil=NewStyle // e.g. for M13

Does anyone know which set was historically the first to have foils? (and which expansions have foils and which don't?) Is there any source for information like that?

5) Add support for foil cards to the deck editor (so that it's possible to see which card is foil and which one isn't, and sort accordingly), booster generation (I don't know the exact rules though, as in "what the chance of a foil card appearing in a booster is") and quest mode (so that it's possible to buy/win foils). Not sure if this will be done by me and immediately, but we'll see. Anyhow, suggestions are welcome as to what the price change should be for foil cards, and what the chance of a foil appearing in the quest shop, should be.

Thank you in advance for suggestions, ideas, and help. I'll try to start on this project as soon as possible.

- Agetian

Agetian wrote:Does anyone know which set was historically the first to have foils? (and which expansions have foils and which don't?) Is there any source for information like that?

Before I even looked it up, I was pretty sure it was Urza's Legacy, since i was at the prerelease and it was a pretty big deal. "Wizards only cares about the collectors etc etc"
http://wiki.mtgsalvation.com/article/Foil_card

1+2. I've never seen a 'plus' sign in a card's name. A trailing plus (or asterisk) on card name might be shorter than "{F}" after a pipe and easier to parse. We may also instruct CardDb to return foiled cards in that case (and make a cache-map from common card to a matching foiled counterpart to ensure reference equality). (That also reminds me of some CCGs where you can upgrade and evolve your cards)
(that is just implemented by the r22298)

If you want deck reader to recognize artindices, look at forge.deck.CardPool.fromCardList(Iterable<String>). Should not be hard at all.

3. Does not matter for me as long as you don't try to implement that on server side.
The modern foiled pictures will be incorrect anyway. To produce correct ones, we'll need alpha maps (that are used to store "shineness") as seen in this article: http://www.wizards.com/magic/magazine/a ... rcana/1232.

4. Good point. The used foiling technique сan be added as an attribute to CardEdition.

5. Best of luck there. That seems to be the most complex part of the task. Deckeditor was not simple, now it became even more puzzled after doublestrike's changes.

@ friarsol: Thanks for the info, that article will come in handy!

@ Max Mtg: Thanks for your input and for the commit contribution!

- Agetian

I just cannot sleep thinking, which suffix is better for foiled cards: asterisk or a plus sign?

@ Max: I was thinking about that too and I believe + and * have about equal chance of appearing in a card name in the future (almost zero, to be honest), but I think the caret sign (^) is practically guaranteed not to ever appear in a valid card name because it's not a standard punctuation sign and its use is pretty specialized. After all, it's even one of the metasymbols in regular expressions that is used for at least two different things. What do you think?

Here's another thing to think about: all foils have black borders. While it's an easy matter to make them draw with the black border in the code, there's a potential issue with the earlier core sets with foils (e.g. 7ED, 8ED) because their full card pictures have a slight white border around the graphics. As such, if we force the game to draw foils with black borders, foils from white-bordered core sets will show up with a "double border" (a thin white border surrounded with a thin black border). Which one is better - have that happen or just keep them white-bordered for now, even though it's historically incorrect?

- Agetian

I think the symbol has also to have some meaning "this card is special". Plus means "better than whatever is before plus" (however it's not really better) , asterisk reminds of a callout in books. It does not declare that the object is better, but has some different property. Caret sign is associated with nothing at all - I've seen it in computer language manuals for first time, it denotes a power-of operator or binary XOR.

I thought of detecting the border and drawing only the part of card inside it.

Option 1: Analyze the picture pixel by pixel from its edges on a stripe chosen somewhere in the middle or the card. Border would end where the next pixel has a too distinct color. Draw the whole of border programmatically, paste only the inner part of the picture. However, this might look ugly if the picture border is not sharp and antialiased with the first pixel of inner card frame (that is white, red, blue... etc).

Option 2: Use crops. Will be able to draw any border, but will have to remember which dual-colored cards have gold frame and which ones have hybrid ones and will have to layout the Oracle text in the same manner as on original card... no idea how.

Option 3: Leave those borders alone. Will be historically incorrect, but will affect only 4 editions: 6ED though 9ED. (Do 6E and 7E also use black borders for foil?). Players will survive.
Option 3a: Semi-automatically (using some photoshop action, but with manual control) paint black borders on card images from 6E-9E, download them as separate sets. When the card is foiled use picture from that set.

To be honest, I don't like the idea of using crops instead of full card art for the only reason of drawing correct borders for foil cards from 4 old core sets - not only it adds an extra complication, but it also makes all of the cards of the battlefield look non-genuine because a good part of them will have to be generated from bits and pieces... So, I think for starters we'll resort to a double border thing (not a big deal tbh) and then it might be viable to upgrade that to something like 3a or maybe 1. Thanks for the input, Max!

P.S. Have never seen a 7ED foil card myself, so no idea about what border it uses...

- Agetian

I think the solution to the false black border is even simpler than that. The HQ images (from which the LQ images are generated) are centered such that the width of the border is 10 pixels on each edge. I'm not sure if this pixel-perfect for every card, but I believe it is. Similarly, LQ images should have a 4 pixel border. Since they've been downscaled in different batches over time there may be a little more variation, but this can be discovered in test.

As long as Forge can detect the difference between an HQ and a LQ image, adding a 10 pixel interior border should universally convert all HQ images to black border, as will a 4 pixel interior border for the LQ files, no per-card computation required. If traces of white border slip through in test, the interior border can be upped to 11/5 pixels for certainty with no substantial loss of information.

As for the naming convention, my only thought is to use a tag or symbol that is not part of magic nomenclature (which disqualifies pluses and asterisks.) I think "#" might work, as I doubt it will ever appear in a card name or in rules text, and the slight slant of the vertical lines suggests the parallelogram silhouette of a card tipped in hand as if one is admiring the foiling.

That said, I personally dislike foils (sorry!) but would be very interested in a universal black border option... it's inaccurate, but it would remove the mish-mash of black and white borders when using "random card art" (which several other users have also mentioned as a turn-off.)

Edit: Oh, and "yay for crops!" Eventually. Whenever you feel like it. ^_^

Diogenes wrote:As long as Forge can detect the difference between an HQ and a LQ image, adding a 10 pixel interior border should universally convert all HQ images to black border, as will a 4 pixel interior border for the LQ files, no per-card computation required. If traces of white border slip through in test, the interior border can be upped to 11/5 pixels for certainty with no substantial loss of information.

Do you mean to use only images of two predefined sizes? What about XLHQ, or some different pictures downloaded from any third-party source (like russian or japanese card scans)?

Number sign is undesirable, as it usually stands for comment in our resource files.

I personally don't think Forge is ready for crops now.

Diogenes wrote:...would be very interested in a universal black border option... it's inaccurate, but it would remove the mish-mash of black and white borders when using "random card art" (which several other users have also mentioned as a turn-off.)

The Random Card Art option has nothing to do with the color of borders, it merely chooses different art for the same card from the same set - that is, if a card is from the 9th edition set, all of the cards from that set will be white-bordered no matter what the specific art version is. Conversely, all cards from Magic 2013 will be black-bordered, once again no matter which art index is chosen for each particular card from this set.

If anyone is up to the task to code the option to make all borders black, feel free to do it (definitely won't be me, at least not immediately), but please make sure it stays an option and not a requirement, personally I prefer the accuracy of visualization of cards with whichever borders they were printed (and I also know that there are enough people who like to have white borders on cards which are supposed to have white borders).

- Agetian

Max mtg wrote:Do you mean to use only images of two predefined sizes? What about XLHQ, or some different pictures downloaded from any third-party source (like russian or japanese card scans)?

Again, I'm not a programmer. I've seen all of your results and I totally defer your judgments, I'm just trying to be helpful. ^_^ Anyway, I figured this was an easier way to implement black borders for the white-bordered images Forge already supports than options 1, 2, and 3a. Since the LQ set is derived from CCGHQ team's HQ images and they have identical proportions, the border Forge generates already works for the HQ and XLHQ images perfectly. I figured it was like a nifty bonus that supporting those sets with this method would only require a different (but constant) width of interior border (pre-scaling.)

It would be nice if Forge could differentiate between CCGHQ/full-border/borderless images (since I imagine most scans on the net fall into that trio if they're not pics taken from a handheld camera.) I imagine it would be a lot more work to go further than that (the full option 1) and I don't know who would really benefit. (Oh, to be clear, I'm not asking for any of this, I'm just replying to the concern of foreign-language-scan users you brought up.)

Max mtg wrote:Number sign is undesirable, as it usually stands for comment in our resource files.

Oops. XD You have a point. (Two posts and I've managed to avoid snarkily suggesting the dollar/euro/pound-sterling symbols.)

Max mtg wrote:I personally don't think Forge is ready for crops now.

That's the sense I've gotten, I didn't mean to push for it. Sorry. I do hope it's not considered against the "vision" of Forge, though. It would be a nice addition at some point in the far future, as it would make playing without any images at all infinitely easier.

Hope I didn't overstep. Thanks again for the work you guys do!

Agetian wrote:The Random Card Art option has nothing to do with the color of borders, it merely chooses different art for the same card from the same set - that is, if a card is from the 9th edition set, all of the cards from that set will be white-bordered no matter what the specific art version is. Conversely, all cards from Magic 2013 will be black-bordered, once again no matter which art index is chosen for each particular card from this set.

What I meant was that when you have "random art" selected, quite often constructed decks which normally come from an all-black-border environment or format will have one or two white bordered variants of those cards appearing amongst the majority black bordered cards. I've seen users here complain about this (not as a bug, per se, but as a minor annoyance,) and honestly they kind of infected my mind with the idea that it's displeasing. Since the conversation was about falsifying black borders on white-bordered foils, I just thought I'd mention that there are users who would like the option to force this for non-foil cards as well (and I'm one of them now, I guess. ) I'm not mentioning it as anything other than an option, but I'll confess that I'd probably default to it on.

Anyway, nothing could be worse than the old white-piping/black-border look before white borders were added.

Diogenes wrote:I'll confess that I'd probably default to it on.

I'd disagree on this point and would default it to off. At least as a person whose contributions to the project (including white borders, by the way) have been geared towards making the feel of Forge more authentic. For the same reason, I dislike crops (at least MTG engines where the only option was a cropped image over a generated card design have never appealed to me; I'd say Microprose's Shandalar was the closest to having tolerable crops for me, but even back then I had a gripe with the game for that particular reason). As options, both are fine with me (it's great to have a variety of options that satisfy different kinds of users), but if things like that start to become enforced requirements in Forge it may well be the day I quit the project. But hey, let's just agree to disagree.

- Agetian

> Random art:
Since a small amount of decks specifies cards' set codes explicitly, random sets are used. This is how people end with white-bordered cards in a deck that's not suposed to have those.

@Agetian, there are more sets with white borders - just remembered it! - Portal series and all those Starters.

Agetian wrote:

Diogenes wrote:

Max mtg wrote:I'll confess that I'd probably default to it on.

I'd disagree on this point and would default it to off. At least as a person whose contributions to the project (including white borders, by the way) have been geared towards making the feel of Forge more authentic. For the same reason, I hate crops. But hey, let's just agree to disagree.

- Agetian

I'm mostly with you on the authenticity issue, it's just that until Xitax updated his set-assigner to work on a 32-bit OS I had to enable "random art" to see more than one image per basic land type per game: either one island forever (usually the overflowing chalice Zendikar island for some reason) or a couple of Romance of the Three Kingdoms stragglers finding their way into Mirrodin or wherever was most inappropriate. I was never a fan of white borders since they premiered, and this cemented my dislike for them. It's the one concession I'll happily make.

Anyway, sorry for wandering off-topic. We'll agree to disagree amicably. <shakes on it>

Max mtg wrote:@Agetian, there are more sets with white borders - just remembered it! - Portal series and all those Starters.

Oh, Chronicles too, now that it's supported.