card.card versus card.card.card

So, at the bottom is the Card structure, which contains all the invariant data about a card type. Then a particular CardInstance is created for each individual card, which tracks an actual instance of that card (where it is, where it came from, etc). Finally, at the client display level there's a CardDisplay object which has the graphical information, like the bitmap we use to draw the card, etc.

That's all pretty logical. What is bad is that those objects contain each other and we lazily referred to each encapsulated "member" of those objects as "card".

So CardDisplay is an class that has a member called "card" which is a CardInstance. CardInstance is also an class with member called "card" which is a Card object. Thus, if you are writing display code like this:

var card:CardDisplay;

you can end up with horrible stuff like:

if (card.card.card == null)

which is referring to the Card object inside the CardInstance inside the CardDisplay object.

 

Just a guard check to make sure that we don't have any null pointer dereferencing. In pretty much every case a card display object should point at an actual card instance and a card instance should always have a card data structure pointer but there are exceptions. For example, a card that is in an opponent's hand has a card display object but a null card instance (since you don't know what that card is yet).

 

Jon you've left yourself logged in as the administrator

 

I have not.

- The Administrator.