Let me get this straight.
You think the right way to code this is to build a basic abstract class which represents a basic card, and all other cards are then derivative classes of this base class. The basecard class would have virtual functions, most important being the Do_Action (or whatever) function which is called every time a card is played.
That is fair enough. But this means building (i don''t know how many cards there are in Magic) a derived class for EACH card. Which means hundreds of different classes. Wouldn''t this eat up an awful lot of resources for what should a small program with relatively small demands on the system running it?
Making A Magic: The Gathering Game = Suicide
Author
I just found a complete list of rules errata for all the older card sets.
www.crystalkeep.com
www.crystalkeep.com
Not a sub class for each card. A sub class for each TYPE of card. You can then use a function pointer, or an object to encapsulate a function to perform the action of the card.
Z.
Z.
what about spells that turn land into creatures? Or enchantments that have an ability to become creatures? Also how do you deal with cards in different states, for example those in the hand or graveyard? What about token creatures? They aren''t cards but you would want to derive themn from whatever creatures are derived from. Things get very complex, OOP isn''t going to be the silver bullet you are looking for. It is only going to be a small part of your strategy. You''re also going to need functional and generic programming plus a lot of hard work. I consider myself a good programmer but I''m going to wait at least another year before I start my own magic game.
Again, States are easily handled by objects.
Just Derive a Token from your base class (maybe we could change the name to "BaseObject" =), and then derive Token_Creature from Token, along with any other token objects that WoTC may or may not add in the future. Almost built in extensibility!
Since Everything is derived from a base class, all of the really important info can be in the base class, and functions could take in (as in the case of enchantments that become creatures), an enchantment, and spit out a creature, except that this creature has a pointer to the original enchantment card so that it can change back. The Base class now includes a "Type", and an "Oringinal_Type", as well as an extra pointer to "Original_Card". You case then use Original_Type to figure out what to case the extra "Card*" to.
Z.
Just Derive a Token from your base class (maybe we could change the name to "BaseObject" =), and then derive Token_Creature from Token, along with any other token objects that WoTC may or may not add in the future. Almost built in extensibility!
Since Everything is derived from a base class, all of the really important info can be in the base class, and functions could take in (as in the case of enchantments that become creatures), an enchantment, and spit out a creature, except that this creature has a pointer to the original enchantment card so that it can change back. The Base class now includes a "Type", and an "Oringinal_Type", as well as an extra pointer to "Original_Card". You case then use Original_Type to figure out what to case the extra "Card*" to.
Z.
Author
Argh. This turned out to be more complicated than i thought. I''m still in the planning stages. Haven''t written a single line of code yet.
Zaei,
I almost forgot about the token creatures... And those annoying licids (enchantment creatures) makes it so much harder to solve.
Zaei,
I almost forgot about the token creatures... And those annoying licids (enchantment creatures) makes it so much harder to solve.
I''m doing a card game myself and the hardest thing I think I would encounter would be AI, You probably dont even want to think about this yet but AI is going to be a killer. Am I missing something or would it be really really REALLY hard to make an inteligent opponent that utilizes all the different cards at its disposal.
I hope any of this helps cause I think I''ve put 6 hours of thought into it since I saw this thread, but tery this.
The ''Card'' class should consist of only 2 methods and 3 members. The methods being, enterplay() and leaveplay(). Those will be where you will keep counters of how many cards are in play. The members will be a bool card_is_in_play, an enumerated value for whether the card is In_Hand, In_Play, In_Graveyard or In_Deck. The last member will store the player who controlls the card at the time. I believe those are the only things that ALL cards have in common.
Then you would break them into creatures, atrifacts, land, enchantments, instants, interrupts, and sorceries. That would be when it will get difficult.
The creatures would need methods for when its cast, when its put into the graveyard, when its owner is changed, when it becomes tapped, when it becomes untapped, when it attacks, when it defends, when it takes damage, when it does damage, when it has another spell cast on it (such as flying), and probably many more if you want to think about it for a while.
The creature would probably need a lot of members also, the casting cost in each of the 6 different types of mana (including colorless), its attack value, its defend value, its modified attack and defend values (after calculating for spells such as giant strength), an array of pointers to cards affecting it such as giant strength or flight and any other cards that would affect it in any way by raising its abilities or giving it new ones. It would require a color which may be colorless, and probably many more if enough thought was put into it.
Also you would probably want to make a ''Deck'' class which would simply have a counter and a large array of pointers to cards. You would want a ''Graveyard'' class that would generally work the same way, and you would probably also want to make use of a ''Hand'' class and a ''Play_Area'' class.
Hope I helped in some way,
~Vendayan
The ''Card'' class should consist of only 2 methods and 3 members. The methods being, enterplay() and leaveplay(). Those will be where you will keep counters of how many cards are in play. The members will be a bool card_is_in_play, an enumerated value for whether the card is In_Hand, In_Play, In_Graveyard or In_Deck. The last member will store the player who controlls the card at the time. I believe those are the only things that ALL cards have in common.
Then you would break them into creatures, atrifacts, land, enchantments, instants, interrupts, and sorceries. That would be when it will get difficult.
The creatures would need methods for when its cast, when its put into the graveyard, when its owner is changed, when it becomes tapped, when it becomes untapped, when it attacks, when it defends, when it takes damage, when it does damage, when it has another spell cast on it (such as flying), and probably many more if you want to think about it for a while.
The creature would probably need a lot of members also, the casting cost in each of the 6 different types of mana (including colorless), its attack value, its defend value, its modified attack and defend values (after calculating for spells such as giant strength), an array of pointers to cards affecting it such as giant strength or flight and any other cards that would affect it in any way by raising its abilities or giving it new ones. It would require a color which may be colorless, and probably many more if enough thought was put into it.
Also you would probably want to make a ''Deck'' class which would simply have a counter and a large array of pointers to cards. You would want a ''Graveyard'' class that would generally work the same way, and you would probably also want to make use of a ''Hand'' class and a ''Play_Area'' class.
Hope I helped in some way,
~Vendayan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
