Cards with counters.

[DennisBergkamp]

Orpheu,

Thanks! Yes, I agree with option #1. Sometime tonight hopefully I'll insert your code into my Card.java, and update all the Planeswalkers to call the correct methods.

There's a lot of really cool cards with counters, I've been meaning to implement this for awhile now, so thanks again

[Orpheu]

No problem man. That was my pleasure...

Hopefully I will be able to help some more in the future.... Now I will start to implement the cards I was trying to...

When I finish I will share the code.

[jpb]

I agree with the solution which Incantus proposed. This would allow for easy to use and bug resistant counters. Creating a new class for each counter is a very concrete change that will most likely not have any interoperable effects on existing cards/counters. This solution looks to be the cleanest and has the least potential of introducing hard to track down bugs.

[Orpheu]

I think that for the large majority of counters a hashtable will be enough. In the future if we see the need to create a separate class we could maintain the same syntax of the counter related functions by changing the hashtable element for the new counter class and keep the key element has the counter name. The element of the counter name will simply pass into the new class counter.

What do you think of this solution?

[DennisBergkamp]

Orpheu,

I think this is fine. As you said, we could always switch to using a Counter.java class at a later point, and just have the same methods reference that class.

But then again, I'm definitely a messy coder so maybe listening to me wouldn't be the greatest idea

[DennisBergkamp]

I made all the changes to Card.Java, and went through CardFactory.java, GameAction.java and GameActionUtil.java, changing all the function calls to correct ones (age and loyalty counters). Eclipse's editor pointed out all the errors until I fixed it, so they weren't too difficult to spot. The Hashtable required me to switch to Java 1.5 for the project though, according to Eclipse, so I did. Everything seemed fine at this point...

However, when I compile and run, I keep getting an error:

"Sorry there has been an error

null

You may need to restart this program."

I'm not sure what's causing it... and when I run the program (after the error message), everything seems to run fine (I tested a few decks with Planeswalkers, loyalty counters were kept track off accordingly, as far as I could see).
Maybe it's because I had to switch to Java 1.5 ? I'm not sure what version I was using for the project before I got the error, maybe 1.4 ? 1.6?

Orpheu, after you changed your Card.java, did you get this kind of error when running the project?

[Orpheu]

The very first time I try to run it I get exactly that same error. lol

But is exactly the way you said it. After that error if you try to run again, every thing just work fine. Maybe forge could help us tracking this error.

If some else find out why we are getting this error it would me much appreciated.

Another chance is that this is not a error, just a compiling miss management of eclipse, that for some reason he don't compile all project, but just Card.java file or something like that, and he cannot find some variables or functions he's expecting. I'm saying this because in the following runs of the program everything just work fine, without any error message.

[Orpheu]

Hi!

I exchange some private messages with jpb, and we come up with the idea of using Enumeration to ensure that no one come up with a crazy name to a counter, or that it don't create a counter name that has already been created with a similiar but differente name ( for instance: "Fade" and "Fade Counter" ).

So we need to create a enumeration of counters in class Card.java with all possible counter values.

The new class Card.java will be:

import java.util.*;

enum Counters{
AGE, LOYALITY, MANA
}

public class Card extends MyObservable
{

(...)

private Command destroyCommand = Command.blank;

private Hashtable<Counters,Integer> counters = new Hashtable<Counters,Integer>();
(...)


public void addCounter(Counters counterName, int n)
{
if(counters.containsKey(counterName))
{
Integer aux = counters.get(counterName) + n;
counters.put(counterName,aux);
}
else
{
counters.put(counterName, new Integer(n));
}
}

public void subtractCounter(Counters counterName, int n)
{
if(counters.containsKey(counterName))
{
Integer aux = counters.get(counterName) - n;
counters.put(counterName,aux);
}
}
public int getCounters(Counters counterName)
{
if(counters.containsKey(counterName))
{
return counters.get(counterName);
}
else
return 0;
}

public void setCounter(Counters counterName, int n) {
counters.put(counterName,new Integer(n));
}

}

Then for calling the function you will use addCounter(Counters.LOYALITY,1) ( for example ).

[DennisBergkamp]

The very first time I try to run it I get exactly that same error. lol

But is exactly the way you said it. After that error if you try to run again, every thing just work fine. Maybe forge could help us tracking this error.

If some else find out why we are getting this error it would me much appreciated.

Another chance is that this is not a error, just a compiling miss management of eclipse, that for some reason he don't compile all project, but just Card.java file or something like that, and he cannot find some variables or functions he's expecting. I'm saying this because in the following runs of the program everything just work fine, without any error message.

Ahh, actually, I kept getting the error on runs afterward, but after clicking away the error, MTGForge seemed to run fine.
I was still getting the error though so I used the debugger to find out what was wrong. Turns out it was me, I put something in a stack description for Gilt-Leaf Archdruid (a card I just added) which was too long? Anyway, I shortened it, and now there's no errors anymore

Still I'm not sure why you got the error running the first time, that does sound like some compiling miss-management.

I exchange some private messages with jpb, and we come up with the idea of using Enumeration to ensure that no one come up with a crazy name to a counter, or that it don't create a counter name that has already been created with a similiar but differente name ( for instance: "Fade" and "Fade Counter" ).

This is a great suggestion, I will add the enum code sometime this evening (and update all function calls accordingly). When I previously programmed java by the way, it was 1.4 so it's interesting to see all of these "new" 1.5 features

[Rob Cashwalker]

Forge has mentioned often that it can only be compiled with Java 1.4. Don't know why, but that's likely part of why you're getting an error. If 1.4 can't handle the hashtable correctly, then switch to an explicit string array, it's simple, and forge already uses it, so there's plenty of sample code.

I don't like the idea of enumeration of counter types. There are a lot of obscure types, and while many of them might never need to be implemented, spelling the counter type consistently shouldn't be difficult.

But now you'll have to also figure out how to annotate the presence of counters on the card in the text display, like whereit shows assigned damage and such.

[DennisBergkamp]

It compiles fine now (using 1.5). I do remember him saying though he never tried it with 1.5 (he was using 1.3 or 1.4 I think).

Hmm anyway, I'm fine with either implementation (just using Strings, or using enumeration), let's ask Forge which way he prefers (since it's HIS project after all). I really don't see any clear disadvantages of using enum, nor Strings (spelling stuff correctly is easy).

In either case, we should specify and agree on the names of some of these types of counters. In most cases, they'll be straightforward (Loyalty, Age, Fade) but in some cases not so clear, what do we call +1/+1 and -1/-1 counters? PTCounter / NegPTCounter? PlusOnePlusOne / MinusOneMinusOne? Or maybe POPO / MOMO ? Haha, the latter just looks ridiculous

As for showing the counters on the card, currently it looks like "Loyalty counters 4" just gets put at the bottom of the text field. We could probably do something similar: "<Countertype> counters: <amount>". Coolest way would be to have it show on top of the card image as well, with some transparent gifs/pngs or whatever, with different counter icons for different types of counters (Shandalar, and I'm sure MTGOnline do this).

[Orpheu]

I think enumeration is a REAL need not a discussion issue. What other way can you ensure that everyone uses the same name to the same counter? String is a handicap option by nature ( you can always have person that preferes "loyality counter" to "Loyality Counter" ). If you use the enumeration option the eclipse api will pop up all the possibilities to counters ordered alphabetic. And if you don't use eclipse to encode java, you can always go directly to the enumeration declaration and check if the counter already exist or not. No one should be forced to run all the code and check if the counter already exist or not.

Even newcomers will easilly spot the right counter to use, don't you think?

I don't like the idea of enumeration of counter types. There are a lot of obscure types, and while many of them might never need to be implemented, spelling the counter type consistently shouldn't be difficult.

Oh by the way. The enumeration will only contain the counters that the project need at some moment in time. It don't really need that many counters.

[jpb]

In most cases, they'll be straightforward (Loyalty, Age, Fade) but in some cases not so clear, what do we call +1/+1 and -1/-1 counters? PTCounter / NegPTCounter? PlusOnePlusOne / MinusOneMinusOne? Or maybe POPO / MOMO ? Haha, the latter just looks ridiculous

The solution incantus suggested would be the best to take care of this. For example have a PTCounter class which you set the power and toughness on then apply this counter to a creature. The logic in the PTCounter class, in a helper class, or in cards themselves will take care of what the counter does depending on the situation.

[Orpheu]

Maybe you are right, but I really don't see the need to create lots of new classes just to represent this information... The enumeration and the hashtable could just as easily do the same....

[Incantus]

That's why I have a separate counter class (which only has one string attribute, but that's an implementation detail). The problem is that some counters have behavior associated with them (namely the +n/+m counters), which makes it hard to use enumerations (are you going to check the hashtable for all counters of the form +N/+M when calculating the power/toughness of a card? - although the rules are a bit simplified now, since modern sets only use +1/+1 counters). You might be tempted to treat them separately, but remember, some cards look at +N/+M counters identically to other counters (for example, Doubling Season).

If you can read python, this is what I do:

Code: Select all

class Counter(object):
    def __init__(self, ctype):
        self.ctype = ctype
    def __eq__(self, val):
        return self.ctype == val
    def __ne__(self, val):
        return not self == val
    def __str__(self):
        return "%s"%self.ctype
    def copy(self):
        return Counter(self.ctype)

class PowerToughnessCounter(Counter):
    def __init__(self, power, toughness):
        super(PowerToughnessCounter,self).__init__("%+d%+d"%(power,toughness))
        self.power = power
        self.toughness = toughness
    def __str__(self):
        return "%+d/%+d"%(self.power, self.toughness)
    def copy(self):
        return PowerToughnessCounter(self.power, self.toughness)