The card class and the player class

[Sloth]

My plan was to give keywords to players via continuous static abilities (Shroud, Hexproof, ?). This seems to be rather simple, since most of the structure is there already.

When I was working on this, I wondered if it would be helpful to get the card class and the player class in line as much as possible, mainly by adding isValid and hasProperty to the player class with the same syntax.

Is there any benefit in adding an ancestor class for both of them and overwrite functions like isValid, hasKeyword, canTarget, addDamage, ...?

[friarsol]

Yea I think there's a bunch of benefit in adding a parent class for Cards and Players. I'd call these "GameObjects" but that's not really a great name.

[Sloth]

Yea I think there's a bunch of benefit in adding a parent class for Cards and Players. I'd call these "GameObjects" but that's not really a great name.

I think "GameObjects" is not so bad.

[Rob Cashwalker]

GameEntity?

Might also help to make Planeswalkers operate closer to the rules.

[Sloth]

GameEntity?

Might also help to make Planeswalkers operate closer to the rules.

GameEntity might be better, because object actually has a meaning in the comprehensive rules.

[Sloth]

I've added the GameEntity class as parent of Card and Player class. There's a lot of room to expand and use it. I guess the targeting code can be done a little more elegant with this (I haven't looked that much at targeting though).