Collectible Card Game Headquarters

I basically wanted to get the input of Dennis and Rob (and anyone else who actually looked at the source code) about what are the major weaknesses of MTG Forge that version 2 should, could address?

1. Divide up CardFactory - which you guys seem to be doing now which is good
2. Add phase stops for all phases
3. Simplify state effects - I'm not sure how but just something cleaner
4. Simplify "comes into play" and "leaves play" abilties
5. No global, static variables
6. Letting the computer start the game
7. Sideboarding - this isn't really a coding issue but I think it would really help
8. Reuse card input and resolve code but not by cutting-and-pasting
9. Simplify damage and combat damage effects like Hypnotic Specter - you guys have added Hypnotic Specter and I'm very impressed

Right now I see version 2 as version 1 that cleans up the code. The gui and the AI are basically the same although I hope to improve them later. I have written everything up until the actually card code for version 2 and I didn't use any global, static variables (yeah, go me!).

There's probably a lot of things, but I think the two main improvements along with the phases would be an actual mana pool, and a much more event-driven architecture.

As for the #3 simplifying the way state effects work, I would code it like this (ties in with the event-driven part) :
Instead of a Glorious Anthem continuously keeping track of the cards it has effect on, checks should be made whenever a permanent comes into play or when it leaves play. For instance, a Glorious Anthem comes into play. As this is happening, effected (affected?) cards (controlled creatures) should get updated, and also vice versa, a check should be made if there are any cards in play that would influence the Glorious Anthem in any way.

This way, you can also keep track of game state, which is another important point, (ideally) it should be possible to save a game of MTGForge at any point, or save a replay of the game and play it back.

I'll use any code that you write for state effects. Maybe you read this, I did write briefly about "converting" static abilities like triggered ones, my post. Cards like Glorious Anthem would just listen to the "when a creature comes into play" event and "when another creature leaves play" event.

There's probably a lot of things, but I think the two main improvements along with the phases would be an actual mana pool, and a much more event-driven architecture.

Having more events would be good. I forgot but I already have the mana pool working. (It isn't really that hard but you just have to plan for it.) I've mention it elsewhere but I also have all the phase stops working and the computer and start first.

This way, you can also keep track of game state, which is another important point, (ideally) it should be possible to save a game of MTGForge at any point, or save a replay of the game and play it back.

This is a harder. Basically (as I see it) methods like GameAction.destroy() would generate a Command object that also has undo and the object would be added to the "master list" of Command objects. Simple in theory but tricky in the actual code. Tracking the game state would make tests easy to write and errors could be easily reported by sending a dump file of Command objects.

I'm also thinking of a "global clock" would would tick when something in the game has changed. Basically it would increment everytime the state effects are checked but other parts of the program could check to see if they should run or not by checking what getTick() : int returned. This idea is very similar to videogames that tell the program when to refresh the screen.

I've been making version 2 too hard so just cleaning up version 1's code doesn't seem very hard. (And adding phase stops, mana pools, and undo.)

And showing errors to the user instead of just sitting there.

My experience with Wagic has led me to a mixed model for Events/state effects.
In my early code, I update state effects every time a frame is drawn on the screen (so that's something like 30 to 60 times par second on the psp).
This has lots of drawbacks that I think I mentioned in a thread in the "Programs with AI or Rules Enforcement" forum.

I introduced a WEvent class (Wagic Event). All Events are child classes of this abstract class. When an event occurs, It is sent to the list of abilities that are active in the game. Those that want to react to the event do so, the other ones just do nothing.

I now have this mixed system which allows me to have "old school" abilities that depend on the screen update, and new abilities with the new event system.

Source code (note that it is a bit dirty because I don't use dynamic casting, but I know that in Java you can retrieve the class of an object with getClass() so it can be cleaner)
http://code.google.com/p/wagic/source/b ... ement.h#46
http://code.google.com/p/wagic/source/b ... WEvent.cpp (right now very few events so they are all in the same file. I believe in java you would need one file per event class)

example code with the lifelink ability:

Code: Select all

class MTGLifelinkRule:public MTGAbility{
[...]

  int receiveEvent(WEvent * event){
    if (event->type == WEvent::DAMAGE){
      WEventDamage * e = (WEventDamage *) event;
      Damage * d = e->damage;
      MTGCardInstance * card = d->source;
      if (d->damage>0 && card && card->basicAbilities[Constants::LIFELINK]){
        card->controller()->life+= d->damage;
        return 1;
      }
    }
    return 0;
  }


Note that the lifelink is not attached to any card, but is coded the way you would code a global enchantment. it just receives all the "damage" events, and if the source of the damage has lifelink, adds that much life to the source controller.

My point here being that you can probably smoothly migrate the code of MTGForge1, keeping your existing card base, yet adding new cards with a new system. Which would prevent you from losing your existing card base.

Events do seem to be a good way to go. MTG Forge version 1 doesn't have many, just a "zone change event" and a bunch of observers. Zones observe the cards that they hold, the gui observers zones and the life points.

My point here being that you can probably smoothly migrate the code of MTGForge1, keeping your existing card base, yet adding new cards with a new system. Which would prevent you from losing your existing card base.

MTG Forge version 1 code is really just a big prototype. I'm glad it works but updating it is pretty crazy. Very fragile would be putting it nicely. Updating the code is like because you know how the code should work but doesn't.

MTG Forge version 1 has too many fundamental errors like it calls the phases too many times, some phases are called twice, or the computer can't play first because the phases are messed up. No phase stops and MTG Forge doesn't even have all of the phases in the first place.

I wish I had some more time to really read through all the details..... On monday, I did what I told myself and everyone around me, something I'd never do - join facebook. Talk about a time-stealer!

One quick point is that the model in place already for the comes into play effect, is actually a good model for a lot of other effects. I guess it boils down to the event-driven model you're talking about. The Card object simply needs to contain a bunch of Command lists, one for each event or action. Cards that care about particular events, either add the command object themselves, or a command object is added by other cards that cause cards to care.... I've proposed in the past that this could even be hacked into v1. Somewhere in the code we run the state-based effects routine... well, instead, we just iterate through all cards, and execute its state effects commands. Simple. Done. The code for the commands reside in CardFactory, not in GameActionUtil....

Mana pool is also something I've thought we could hack in, as is. Simply a string formatted like the mana cost itself. We use a keywrod-script parser that creates an ability for the tap: add _ keyword. The ability simply concats the mana type on the mana pool string. When the pay mana cost routine executes, it first reads the mana pool and pays costs from the string first. Any remaining mana requirements are handled by the rest of the existing routine. We would just need to have a few lines added in between the phases to clear the string, and if the string length is non-zero, to subtract the appropriate life... unless M2010 rules do not include mana burn, as rumored... yuck.

We had to clear up a lot of warnings for serialiazable classes. If the game state was saveable, nearly every class would need to become serializable.. and make sure that all instances get unique ID's.

I already gave much of my over-all opinion on v2 on the blog, but basically as long a we have a stable foundation for the text-only cards, advanced AI algorithms and GUI, then we can help to integrate the currently supported cards plus the basic ones that we can't do now (mana pool stuff, Auras and equipment, etc).

Heh you too? My friend got me to sign up a month or two ago and yeah it is a time waster if you let it be. I just log in check messages and leave.

Not include manaburn? Seriously? I am sure some people would be delighted but I am also equally certain that the pool will still drain between steps even if it doesn't lead to damage.

It's still new.. I'm still building my friends list... finding family and stuff. I'm sure it'll get to that point for me too.... My wife will sit there for hours playing the games.... I've got real games to waste my time on.... I'm looking for you after posting this...

Yeah, the discussion on salvation is that the mana has to empty at some point.... But the burn is not intuitive for new players, and would leave a negative impression for them. Still just a rumor of course, and there are a few cards that specifically mention "this doesn't cause mana burn" which would need errata; and there are entire strategies that would be nullified, using Spectral Searchlight to ping people at EOT. Lots of people claim this would be the death of Magic... just like any other change they make... like the card frames....

edit - found ya! Good thing your website has a link to myspace.... Seeing as how we both live in NYC, we really should meet sometime, grab a beverage and flip some cardboard.

Wow, Facebook. I think I'm the only one on this planet that hasn't joined it yet
And peer pressure still hasn't pushed me over the edge. Which is a good thing, I doubt I would have time to do any updates on MTGForge...

I'm not on it either. I got onto MySpace because it was the only way to contact a friend in Costa Rica, but I never use it. I think they're both evil.

Do I have anything to hide? Not really, but I value my privacy too. Those things are too much like a soap opera for me, everything's out in the open.

Rob I have no cards to speak of but I'll be glad to school you with your own :p I kid (about the schooling). I would be happy to meet you somewhere to play. Unfortunately I am ever penurious so finding a place that is free or cheap is tricky. Around my area are a couple places we could try (LES) that aren't too pricey.

Re the junk on facebook. there is nothing about it that requires any time at all. It is just that people start doing the quizs and playing the games and suddenly a whole day is shot.

I never used Facebook or MySpace and somehow I keep on living, lol.

I'm trying to just get version 2 working. I have abstract classes for Cost, Target, and Effect. Currently SpellAbility does the work of all 3 of these classes. The version 2 SpellAbility will do less work and will be composed of Cost, Target, and Effect objects. The idea is to reuse the targeting and resolve (Effect) code as much as possible for multiple cards.

The AI will be the same but can hopefully use somthing like alpha-beta in the future (getting alpha-beta to just work with creature combat is hard enough). To facilitate a computerized search like alpha-beta, Target has getLegalTargets() which returns all legal targets, if the card was Shock, it would return all creatures. Also Target has ai_getGoodTargets() which returns good, possible targets for the AI, if the card was Shock it could return a 2/2 flyer or 4/1 creature.

Code: Select all

public interface Resolve
{
  public void execute();
  public void undo();
}

public interface Cost
{
  public boolean canPlay();

  //Input is just a guess, may change it later
  public Input  getExtraCost();
  public String getManaCost();

  public boolean hasManaCost();
  public boolean hasExtraCost();

  public boolean hasTapCost();
  public boolean hasSacrificeCost();

  public void doTapCost();
  public void doSacrificeCost();
}

public interface Target
{
  public Input getInput();

  public boolean needMoreTargets();
  public boolean isLegalTarget(Object o);

  public void addTarget(Object o);
  public String getTargetMessage();

  public Object[] getLegalTargets();
  public Object[] ai_getGoodTargets();
  public Object[] getTargets();//returns all the objects from addTarget()
}

/*
//this is an example of how to use Target

    if(t.needMoreTargets()) //do we need any targets?
    {
      while(t.needMoreTargets())
      {
        //let user choose X from getLegalTargets()
        //then addTarget(X)
        t.addTarget(t.getLegalTargets()[0]);
      }//while
    }//if

    //sample resolve()
    Object o[] = t.getTargets();
    if(t.isLegalTarget(o[0]))
      ;//do something
*/

We had to clear up a lot of warnings for serialiazable classes. If the game state was saveable, nearly every class would need to become serializable.. and make sure that all instances get unique ID's.

The idea is that only the Command objects have to be serialiazable, I think it is similar to your Tie Fighter game (if I have the right person). Only the actions are recorded and everything else works how it should.

(The Command Pattern usually uses a very simple object named Command that has one abstract (virtual) method named execute(), so if you want a Command object to do something you have to create a new one and override execute(). The classic example of Command objects is a user menu. The menu wants to let the user execute some action but we don't know what specific action that will be. And hopefully this makes sense and isn't redundant, if it is, sorry )

I already gave much of my over-all opinion on v2 on the blog, but basically as long a we have a stable foundation for the text-only cards, advanced AI algorithms and GUI, then we can help to integrate the currently supported cards plus the basic ones that we can't do now (mana pool stuff, Auras and equipment, etc).

Hopefully version 2 will be a better foundation than version 1, but you and dennis have added some great things like Hypnotic Specter and protection to version 1.

mtgrares wrote:The idea is that only the Command objects have to be serialiazable, I think it is similar to your Tie Fighter game (if I have the right person). Only the actions are recorded and everything else works how it should.

This doesn't make sense. The game state would have to include primarily Card Objects and CardList Objects, and probably a few others. TIE Fighter and X-Wing save an initial set of data for each object in the game (Cards and CardLists) and then every action that occurs to each object (Commands). Unless you were to save a game while there were effects on the stack, which would mean that the Ability objects currently on the stack would need to be saved too. And what if you were to save the game in the middle of the computer analyzing the board position... now you have to save AI objects... or something. See where this is going?