Collectible Card Game Headquarters

I think I have now got to the point where I've done as much as I can to implement all the different counter types. As a disclaimer, this isn't implemented! (But hopefully will). Putting all the changes and additions into one easy place will also help other coders and scripters as there are lots of changes, though shouldn't have much of an impact to the player.

Nuts and Bolts

Magic.Model.MagicCounterType:

All counters are now included in this file, taken from the latest oracle text. This even includes the more bizarre counters such as scream and +0/+2 (Don't know which cards those are from? Here you go: Endless Scream and Frankenstein's Monster).
Also added are a score value for use by the AI (more of that later) and being able to pull the relevant counter if you have a String of its name via MagicCounterType.getCounterRaw(String), which allows certain Abilities and Costs to work.

Magic.Model.MagicAbility:

For card scripters, there's a streamlining of card Abilities, and some impact on the behind the scenes working. All have been modified to allow the new MagicComesIntoPlayWithCounterTrigger format (see below).

Added to MagicAbility.java:

• EntersWithCounter ("enters with counter <CounterType> <n>") – This will be the main ability for use with counters. Will accept any counter type and add the relevant amount.

• EntersXCharge ("enters with counter charge X") – An extension on EntersXPlus. Due to the functioning of the calculation of X, there's no simple way of being able to use any counter type (see MagicWhenComesIntoPlayTrigger). Currently, only charge and +1/+1 counters get added to cards X amount at a time.

• Loyalty ("loyalty <n>") – Included to use loyalty counters, adds <n> loyalty counters as it enters the battlefield. Would prefer to use Loyalty as a card definition, but having definitions that create triggered events is beyond me for the moment. This more closely matches the cards than having to use "enters with counter loyalty <n>".

Modified in MagicAbility.java:

• EntersXPlus ("enters with counter +1/+1 X") and Multicounter ("enters with counter +1/+1 for each kick") – Has now had its text changed to match the 'new' "enters with counter" format.

Removed from MagicAbility.java:

• TapAddCharge ("tap add charge") – Could already be performed with 'pay :PN puts a charge counter on SN.

• EntersCharged ("enters with counter <CounterType> <n>") – This has simply been renamed, script usage remains the same.

• EntersMinus ("enters with -1/-1 <n>") and EntersPlus ("enters with +1/+1 <n>") – Individual counter types no longer need separate abilities.

Magic.Model.Event.MagicRuleEventAction:

This is the second section of streamlining for scripters. These Effects have been merged together to create two universal set of rules for counters.

Added to MagicRuleEventAction.java:

• CounterOnSelf ("put <amount> <CounterType> counter(s) on SN.") – This will allow any amount of any type of counter to be placed on the permanent.

• CounterOnChosen ("put <amount> <CounterType> counter(s) on <chosen>.") – The same as CounterOnSelf, but on any permanent. This also includes selecting the correct MagicTiming, MagicTargetPicker and MagicTargetHint. This it works out from the CounterType chosen, and the score of that CounterType (see Brain and Engine).

Removed from MagicRuleEventAction.java:
With the universal Rules for counters, specifying countertypes by separate rules is no longer necessary.

• GrowSelf ("put <amount> +1/+1 counter(s) on SN.")

• GrowChosen ("put <amount> +1/+1 counter(s) on <chosen>.")

• ShrinkChosen ("put <amount> -1/-1 counter(s) on <chosen>.")

• ChargeSelf ("put <amount> <type> counter(s) on SN.") – This looks at first glance to be able to do what CounterOnSelf achieves. However this puts charge counters on the permanent, and calls them by a different name.

Also removed is 'MagicCounterType englishToCounter' as the MagicCounterType now has its own way of selecting the correct CounterType from a String.

Magic.Model.Event.MagicPermanentActivation:

The final section for scripting, this time changes to the Costs.

Added to MagicPermanentActivation.java:

• "Remove <amount> <CounterType> counter(s) from SN" – This cost covers all CounterType payments.

Modified in MagicPermanentActivation.java:

• "Sacrifice SN" – This now replaces . Yes, I know, it doesn't involve counters in any way, but if we're going to one day have Snow mana, we have to make room for it sometime .

Removed from MagicPermanentActivation.java:
Individual costs for each CounterType are no longer necessary.

• "{S}"

• "{+1/+1}"

• "{-1/-1}"

• "{C}"

• "{C2}"

• "{C3}"

The Peripheries

The remaining file changes are mainly housekeeping and referring to newer formats, they are mainly behind the scenes, but may pop up in groovy scripting.

• Magic.Model.Trigger.MagicWhenComesIntoPlayTrigger – Includes the new XChargeCounters trigger from the EntersXCharge ability from MagicAbility.java.

• Magic.Model.Trigger.MagicComesIntoPlayWithCounterTrigger – This trigger no longer requires a 'description' string for the CounterType, this is automatically obtained from MagicCounterType.getName() instead.

• Magic.Model.Trigger.MagicFadeVanishCounterTrigger – This took a while to get right. Instead of referring to a string describing the CounterType, the actual CounterType is referred. No functional change, but looks quite different now in code. Uses the relevant CounterType instead of charge counters

• Magic.Model.Trigger.MagicCumulativeUpkeepTrigger – Now uses age counters instead of charge.

• Magic.Model.Trigger.MagicLandfallTrigger – Now uses quest counters instead of charge. Also uses the renamed MagicSimpleMayChoice (see below).

• Magic.Model.Choice.MagicSimpleMayChoice – The ADD_CHARGE_COUNTER has been renamed ADD_POS_COUNTER. Originally expecting to add ADD_NEG_COUNTER as well, before realising that if you had a choice to add a 'bad' counter to a permanent, you'd probably always choose not to. Who knows what future cards will bring…

• Magic.Model.Event.MagicLevelUpActivation – Now refers to level counters instead of charge.

• Magic.Model.Event.MagicPlaneswalkerActivation – Now refers to loyalty counters instead of charge.

• Magic.Model.Condition.MagicConditionFactory – The conditions referring to specific counters have been removed as the CounterAtLeast condition already allows for any CounterType to be referred. (Conditions removed: ChargeCountersAtLeast and PlusOneCounterAtLeast)

Brain and Engine

If you've got this far, I'm stunned
The final (honest!) changes are for some final mechanics to allow the more obscure power and toughness modifying counters to function, and to the AI to understand what the hell just happened to all these changes!

Magic.Model.mstatic.MagicPermanentStatic:

Adding all the CounterTypes also includes the full range of power and toughness adjusting counters. Things like +0/+1, +2/+0 and -2/-2. These new additions have been named following the pattern for the previous +1/+1. So that means that PlusZeroPlusOne is +0/+1 and PlusTwoPlusZero is +2/+0.
Glad that all makes sense. As the +1/+1 counter isn't called PlusOnePlusOne, the +2/+2 counter is called simply PlusTwo. The same goes for MinusTwo, being -2/-2.

Magic.ai.ArtificialScoringSystem:

The scoring system for the AI has been upgraded for the new CounterTypes. Previously the score for each charge counter was +1. Taking this as a base, all other counter types were given values of either 1, 0 or -1. The values hope to make sense on the effect the different CounterTypes can have on permanents.
The scores all assume that you are the owner and controller of the permanent that the counters are on, not the owner of the counters themselves.

• 0 = Ignore (for stat adjusting counters or counters that are used both positively and negatively, or counters that mark a rule change for that card while present)

• 1 = Count (counters that are only used positively (e.g. Counting a spendable resource, negative impact if decreased to a certain value, positive impact if increased to a certain value))

• -1 = Count (counters that are only used negatively (e.g. positive impact if decreased to a certain value, negative impact if increased to a certain value))

Not all of the counters fall into these guidelines, but they are a good place to start if/when more counter types are added. Some of the current scores may change if the AI is acting strangely with them.

Card Scripts
I'm fairly sure I've managed to catch all the changes and edit card scripts accordingly, but if some have slipped through the net, all the above should be able to point in the right direction.

Icon Images
The current rendering of counter types, and ability symbols for that matter, are not always the best for readability. 16x16 images are always going to be tricky to distinguish, and trying to find things that can thematically express sometimes abstract concepts at such a small size is difficult.

• To aid with visibility, the counter number will only show if there's 2 or more counters on a permanent. The value of 1 is redundant if you can already see an image.

• Hopefully some budding pixel artists can help! But if you do find a suitable image, take into account its original size. Shrinking a large image down to 16x16 pixels will regularly resemble a blurred mess.

• The left-most half of an ability or counter icon is the most visible, so if there is some blank space around the image, pushing it to the left-most side will certainly help.

• Big (well, you know, as big as 16 pixels will allow) and bold! I know that some of my submissions have been pretty poor for this, especially icons that share a colour with the colour-types in Magic (black on black isn't a good look).

I'm hoping that there won't be many bugs or strangeness occurring, and I've tried to break things playing the most counter-filled decks you've ever seen. My clone at https://code.google.com/r/shawnieboyuk- ... ter-types/ is available for scrutiny and testing. I can only hope I'm able to give a big contribution to this great program! Can't give enough praise for the work that Melvin does maintaining this

Wow, unbelievable stuff, thanks ShawnieBoy!

I echo @Huggybaby's sentitments. Could you post a screen shot showing a card with a couple of abilities and multiple counters. This is probably a stupid question, but is there a reason why the icons cannot be bigger, say 24x24 or even 32x32? I appreciate that this covers up more of the card but currently the text in the bottom half of the card is illegible anyway at the sizes displayed so why not use the space?

@ShawnieBoy Nice work and thanks for the detailed explanation. Merged into main repo, first bug fix applied https://code.google.com/p/magarena/sour ... cff20ea7f1 (planeswalker state check and damage should use Loyalty counter instead of charge coutner).

@Lodici Agree, would be good if we can make use of the space taken up by the card text.

Thanks guys

There didn't seem to be a reason that the icons can't be bigger - I'll get right on it!

And I also now realised that my search/parse program wasn't looking into the .groovy files, thanks for the fixes and pieces that slipped through the net.

Oh and here's a quick boardstate

I've been having a look at the rendering of abilities and counters and I've discovered a few things I need to query.

I'm not really a Java person, but have been learning fast, and have noticed that both java.awt.Graphics and java.awt.Graphics2D are in use in different places. At first I thought that the 'Graphics' version was being used for backwards compatibility with older versions of Java, but some files use one over the other, and some even use both (reading that 'Graphics2D' is essentially the same as 'Graphics', but with some extra functions makes that seem unnecessary). I couldn't find out when the 2D version was implemented, although there's a book published in 1999 which covers it, so it must be fairly old. So do I upgrade everything to the 2D version?

There's two separate renderings for the cards, one for in your hand, graveyard, library etc. (ImageCardListViewer), the other for the Battlefield (ImagePermanentViewer). As far as the icons on the cards, they're both doing the same thing, but the battlefield version is better, as it crops the icons if the try and spread off the card. As there's no 'word-wrap' equivalent for the icons (I'm working on it), you can see them continue off the card while in your hand. (Have a look at Akroma, Angel of Wrath). I don't want to step on any toes, as I know Lodici is the visuals-guy, but I think that the whole Magic.ui.Viewer folder can do with a tidy-up...

As for the icon sizes themselves, 32x32 is a bit too large. Only taking into account cards in hand, you can only have around 5 or so icons visible before you start going over the card picture. 24x24 looks like a better option for the hand. However with the scaling of cards on the battlefield, the icons and p/t don't scale along with it, and so will at some point cover the whole card. With the card-image pop up, that may not be too bad, so you can see what card's underneath them all, but with the possibility that there's not even enough room for all the icons on smaller scaled cards, it's possible to have the icons scale as well after a certain point(seeing as they were originally 16x16, there's a bit of elbow room). Should the card pictures be 'sacred' and never be covered?

Thanks for the screen shot.

ShawnieBoy wrote:So do I upgrade everything to the 2D version?

I tend to use the Graphics object if it is available otherwise Graphics2D. Please don't update the graphics object in existing code unless there is a clear reason to do so, such as a method or property that is only available from Graphics2D or a demonstrable performance improvement.

ShawnieBoy wrote:...I think that the whole Magic.ui.Viewer folder can do with a tidy-up...

What do you suggest?

ShawnieBoy wrote:Only taking into account cards in hand, you can only have around 5 or so icons visible before you start going over the card picture.

Is there a (theoretical) maximum number of abilities and counter types a card could have? Given the minimum size of a card image appears to be 100 width by 140 height then I reckon at 24x24 you could fit 2 rows of icons in the text area of the card, where the first row contains 5 icons and the second row contains 3 icons (so it does not encroach on the CMC overlay). So 8 icons in total - that seems like quite a lot.

Alternatively, how about building the icons up and from the LHS of the card. At 24x24 that is a column of about 5 icons and I reckon you could get at least two columns out of that and the card would still be identifiable via the artwork.

ShawnieBoy wrote:Should the card pictures be 'sacred' and never be covered?

I think you can cover a portion of the artwork (see column arrangement above) and still identify the card. The problem is that at the minimum card size (100 x 140) I find that it is the artwork that is only thing that helps me identify the card at first glance - obviously I would use the pop-up for the details. What might help is to display the card name using a text overlay along the top of the card (as is done in Forge).

Thanks for the reply, I think I can see why both versions of Graphics are being used now, and it's simple enough to convert to 2d in the code if needed. Will tread carefully on that one.

As for a theoretical Maximum of counters and abilities - well assuming we give each Ability Keyword an icon, abilities alone can get up the 30's if you really try, not taking into account Counters as well. A quick way of getting close to the 8-10 icon-slots is Oona's Gatewarden enchanted with a combination of Daybreak Coronet and Unflinching Courage - maybe sticking a +1/+1 counter on there as well. Akroma, Angel of Wrath is 7 abilities on her own. I'm fairly sure a Sliver deck could reach it too.

With the card size, the Maximum is 100x140, when the permanent is scaled down with the PermanentViewer, even less of the card will be visible. Kinda getting worried about that, scaling the icons with it is an option, or only when the card reaches a certain threshold. Has anyone been able to fill the battlefield to an extreme state? A screenshot of that would be handy to see how small the cards will go.

Having one dedicated card renderer for the image and overlay (abilities, pt, counters etc) which the other Zone viewers can access would be a good step forward - This will also give the possibility of rendering card frames separately to take card color/type changes into account as well (Lands and artifacts turning into creatures for example) - Even to the point of only needing cropped images for the cards, as we can then put together only the parts needed for the zones. ie. No need for card text for the battlefield, only hand and pop-up. This will also enable Oracle Text rendering for cards that have errata, creature type changes, etc (Yeah, I'm thinking big , but it must be do-able)

Ahh, sorry, got the sizes wrong >.< 100x140 does look like the minimum - that's not as bad then

ShawnieBoy wrote:Ahh, sorry, got the sizes wrong >.< 100x140 does look like the minimum - that's not as bad then

No, you are right - the minimum only applies to the ImageHandGraveyardExileViewer. On the battlefield anything goes...

ShawnieBoy wrote:Has anyone been able to fill the battlefield to an extreme state? A screenshot of that would be handy to see how small the cards will go.

It is possible to setup initial game states using classes in magic.test by using the "-DtestGame" VM argument. Here are screen shots using the TestAbilities class (-DtestGame=TestAbilities)...

At full screen -


Same view using the minimum allowed screen size


The only info I can glean from these screens (especially the minimum size) is that it is probably time to start a new game! Obviously icon overlays are academic when the game state is like this. In this situation I think you would need to skip overlays and use some other way of indicating generally that the original card has been modified in some way (eg, border color) and then show the icons and any other overlays in a popup view or even a permanent card view on the LHS.

I can think of a couple of things to improve the situation -
- there should be a minium useable size for cards on the battlefield. The tiny sizes in the above screens shots are next to useless. Instead use a more useful min size and implement scrolling should it be required.
- in the above screenshots there are approx 100 Accorder Paladins. Alot of the problems could be alleviated if a single image was used with a count overlayed on top. Coincidentally, something like my next update for the CardZoneView - here is the hand from the above screen shot where each distinct card type is shown with an overlayed count if there are more than one of that type.

I'm having to rein myself back a bit and focus on the icon rendering, and then work my way up the the card rendering. But that's all really handy, thanks

On a side note, I think I've found something a bit wasteful, or a workaround that's been hanging about:

The IconImages.java is building an ImageIcon for all the icons used. But as far as the card icons for abilities and counters, the ImageIcon isn't being rendered, the image is being pulled back out of the ImageIcon and being rendered instead.

Maybe I'm misunderstanding something, but the paintIcon isn't being used (e.g. FLYING.paintIcon(this, g, 100,100) instead of g.drawImage(IconImages.FLYING.getImage(),100,100,observer)) Seems a waste of time to build the IconImage and then take the image back out again.

ShawnieBoy wrote:Maybe I'm misunderstanding something, but the paintIcon isn't being used (e.g. FLYING.paintIcon(this, g, 100,100) instead of g.drawImage(IconImages.FLYING.getImage(),100,100,observer)) Seems a waste of time to build the IconImage and then take the image back out again.

I think ImageIcon is an interface that uses Image as a source therefore paintIcon() and getImage() basically do the same thing and act on the underlying image. I guess if "observer" is not required then paintIcon() would be just as effective. Good question though - forced me to revisit how I was using icons (https://bitbucket.org/lodici/magarena/c ... 7860de2911)

See also http://stackoverflow.com/questions/1119 ... difference.

I think the icon rendering is going to be a longer-term project for me. It seems such a simple thing, but everything I want to do cascades into re-doing the whole of card rendering! For now, I'll put forward some placeholder images for some counter-types that don't have any. And hopefully put in place an icon ordering system with icons staying the same size they are, for now.