M:TG deck evolution II

Well a couple days have come and gone since I got started on the M:TG engine and so far things are looking up. The signal based system I outlined last time makes a huge ammount of sense and works a treat to boot. As of right now I have a Signal class and about two dozen subclasses thereof which are more event specific. I have a Client class which will serve as a superclass of everything which recieves signals, and a GameInstance class which actually does the work to track turns, pass signals an generally keep things ticking along.

Today I started moving in the direction of adding cards and decks. There are two real issues with this next step. The first issue is that all the cards have different static data. There are two solutions to this as evidenced by the other M:TG implimentations. The first and obvious one is to actually impliment a class for every last card. I think that all told there are 23k M:TG cards? Clearly that makes no sense. The best alternative thereto is to build a markup language which can draw as much information as possible from the data which my crawler can pull from the Gatherer’s database.4

Fortunately, Python allows the following:

+----------------------------------+
| class C(object):                 |
|     def __init__(self, d):       |
|         self.__dict__.update(d)  |
+----------------------------------+

as an idiomatic way to set a whole lot of member variables. By doing this with some dictionary d={‘foo’:bar}, C.foo = bar. Get the picture? The original web crawler I wrote creates a database of dictionaries… can you see where I am going with this?

However, this leaves the problem of handle(self, sig). handle is is the method defined by the Client interface which actually deals with all the signals which a signal-sensitive object may be forced to deal with. Somehow the card saving/loading structure needs to provide for packaging an implimentation of this function. The easy solution is to thrown another string in the card dictionary, but I would prefer a more elligant solution.

There also still remains the structural issue that technically spells generate creatures when the resolve. The spell then is NOT added to the Graveyard, but is instead discarded and becomes a token for the actual critter. As providing a creature class which can be canceled from the stack is stupid when spells have to be canceled too, there is this extra layer of creature generation to be dealt with because some effects take place ONLY on cast and cannot be triggered during play. That indicates that the resolved creature needs to LACK some behavior, and FEATURE other behavior.