I recently started working on a collectable card game for iOS and feel like I have coders block (is that a thing). Before I get into where exactly I'm at, let me quickly explain the rules.

Games are 1v1 where you each have a deck of about 30 cards. 1 of those will be a hero card that you start with (don't have to draw it from the deck). The objective is to play your other cards to kill the opponents hero card. Your other cards will have special effects / abilities that could affect almost anything else about the game. (this is where I'm stuck).

I have a working version that cycles through the turns and you can play cards, attack the opponents cards / hero, but thats about it. I'm having trouble implementing the special abilities of the cards. Just to name a few here is what I'll need:

These would be on play abilities that occur while the card is on the board

- buff your other cards' health and damage

- replace lost health on cards (heal)

- prevent opponent from attacking certain cards

- grant you an extra card draw each turn

- immediately give you an extra card

- freeze an opponents card from attacking for a turn

Some are simpler than others. It would be easy to say when a 'buff' card is played, + 1 to all your cards health and damage, but what about when the buff card is killed? is it as simple as - 1, possibly. However, it can be much more complicated than that so I'm not sure that would be the cleanest solution.

I think it would help if someone could explain out what they would do with maybe some pseudo examples. Hopefully that isn't too much to ask?

Thank you

Assuming you are using paper prototypes for playtesting, how do you represent game state? Go ahead and translate your tokens, counters, etc. and the residue the players keep in their head to appropriate data structures. It is a fundamentally easy programming task, so I guess you are in trouble because the rules of your game are vague and in flux and you don't know if you are doing the right thing: playtesting should be very useful to find interesting cases and gain confidence in the rules.

Agreed. Write it down. Having a concrete rule structure on how the game is played and how to step through each phase is critical to programming the game logic. As for examples of comprehensive TCG/CCG rules: how about the biggest one out there? Your rules don't have to be that complicated of course, but it's a good place to start.

The history of Magic:the Gathering rules and card wording should teach some humility: very loose at the beginning, then progressively improved and normalized but ending in excessive complexity (do you remember the "Mana Source" card type?), then redesigned in a more principled way (the stack, the great creature type standardization), then constrained to a sustainable complexity level (abandoned legacy features like graveyard ordering, a very limited number of keyword and actual new rules per card set); all the while with occasional big rule changes (combat damage on the stack or as a special action, unconstrained and then constrained combat damage assignment, most recently legendary and planeswalker uniqueness rules changing from only one on the battlefield to only one per player) and countless rounds of card text standardization.

If this is how good a large team of competent and experienced designers performs on a mature game, you should be scared of designing a new game by yourself: make use of your only advantage, which is starting from a blank slate rather than being constrained by a messy and very complex game to fix. You can be rigorous and add features in small steps, never creating excessive unexplored complexity.

You should also try to apply the current, rather good, principles of Magic: the Gathering rule design: define everything and describe the normal course of the game, which means defining the ontology of what cards can potentially do (even if your game isn't particularly about bending the rules like M:tG); cover, more or less implicitly, all possible interactions and situations; introduce abstractions (e.g. layers and permanents attached to other permanents) to treat large numbers of special cases systematically and uniformly; don't be afraid of really exotic special case rules (e.g. the lengthy ones about "subgames" and "restarting the game", each currently used by one card); standardize aggressively card text and behaviour to make the game easier to play.

Thank you for the replies, I've taken a step back and come up with a list of possible abilities cards will have. With that in mind I figured that a simple State Machine would work. Part of the reasoning behind using States is because every card in play might need to know every other card in play to be able to apply affects. Most cards will either affect the health, damage, fatigue (summoning sickness), or whether or not a player can attack certain cards (protection). The basic stats are just components that I can add/remove from a card and the total is just the sum of all its components. For example, I would play a card and add a component with 10 health, then if it takes damage I would add a component with -3 health, then I have a method to get the current health of a card which sums all the health components it has. That way, if I have a buff card enter play it can add +5 health but if the buff card is killed it just cycles through the other cards and removes it's +5 component from any card that had it.

So far I like this implementation because if I ever want to make a game altering card with an ability: 'time travel' - reset the game back one turn, it should be very possible with saving states. Although I'm not 100% sure how it would be implemented, I don't think it would require a complete re-write.

I agree with Lorenzo that paper prototyping is essential in working out the rules of your card game. I like the time travel idea - I had a feature like that in my Shanghai games, but it's difficult to paper prototype it (easy to do on the computer, though).

I have been toying with a pretty complex card game design for a while now. Moving it to the digital world has certainly been a challenge.

The one thing I didn't want to do was keep things incredibly simple. I wanted card abilities that were interesting and could be expanded on. I created this a while back which can most definitely be improved upon, but acts as a good example:

in the event that we make the actual program at some time ... here are some of the subroutine ideas we could use variables -> deal damage destroy increase atk action description action example decrease atk tribute remove from game attack creature - 400 damage - 1 target deal damage / face up / 1 card - select face up face down all grave yard to what type 1 card - select > 1 card select all cards to how many kill all face up monsters destroy/faceup/allcards time over X turns certain phase (command/summon) (draw etc) x factor damage calc end calculation record atk record type record etc

In the first example the ability on the card would say:

Deals 400 damage to target creature.

breaking that down into code, you see, 'deal damage' 'faceup creature' '1 card' and 'select' This tells the program everything it needs to know to initiate player options and action. The player is allowed to choose any faceup creature card to deal damage. Each card would be made up from 1 selection of each color in the above table. So if you wanted to make up a card, you just choose one: 'Destroy' 'face down' '3 card select' <- powerful card!

'record type' would be used for things like, "doppleganger' or type changes, attacks.

Building a stack is the most important thing you can do. Set up a priority system for actions. If youre going to allow interrupts by the opponent, thats even more important.

I posted the card game idea somewhere on here i think a few years ago if youre interested in pulling up my history.