Card Game Discussion - Virtualization and Concept Building?

[trancehime]

Hi folks.

I know that there are some people here who are interested in game design, as well as game development. As well, there are many card game enthusiasts here - people who enjoy Pokemon TCG, Yu-Gi-Oh! and of course, who can forget MTG? And then there are those who even play the non-CCG/TCG things such as Monopoly Deal, and other kinds of games. I am curious to see if there are any people here who would like to talk strictly theory on a way to virtualize or codify many of the concepts found in such card games, in order to assist in making a reality our own ideas if ever, since paper prototyping is a PITA.

My first concern is discussion of the static and dynamic models of cards and other similar objects. For example, while there are static cards such as those that don't have effects - character cards with no effects for example (Yu-Gi-Oh!'s Dark Elf) there usually tend to be very many kinds of dynamic cards such as Monopoly Deal's "Just Say No" card, which requires a real-time input from users to actually play the card before somebody else's Action card ("Pay the Rent," "It's My Birthday," and others).

The second concern is tackling conditionals - both within cards themselves and within the overarching game. For example, the card game Eleminis revolves around making a specific set of 5 cards in a player's row - one of each of the following cards: Fire, Plant, Air, Rock and Water, with a Star card that serves as a wild card. Similarly, you may already know Monopoly Deal's goal is to create 3 full sets of Property cards of various colors. Wild cards also exist. How can we provide a unified codification of these conditionals, that also fall under the static and dynamic model that I was thinking of previous? Actually, this is a huge part of the problem that I want to solve.

Lastly, is working on a representation of these virtualized concepts - something that can be easily understood while at the same time robust and flexible. I realize compromises need to be made, and I would greatly appreciate it if people who were not versed in programming share their insights on the matter here, as their input is just as valued if not more valued than those who know their coding lingo.

Thanks!

EDIT: Guess I should be more clear on this, but here is what I mentioned in IRC when Chireifriend asked me about it

22:50:25 (Chirei) Are you trying to find out how a card game would work as a game?
22:50:26 (trancehime) It just occurres to me the lots of the Pokemon names in PKMN Crystal VIetnamese is... transliterated Chinese which in turn is transliterated Japanese
22:50:31 (Chirei) Er... video game?
22:50:34 (trancehime) digital game
22:50:42 (trancehime) how a card game would be represented
22:50:43 (trancehime) as a digital game
22:50:51 (Chirei) Actually... YGO already has several versions of itself as a card game
22:50:55 (Chirei) in a video game
22:50:56 (trancehime) yeah but
22:50:59 (trancehime) what is the code
22:51:02 (trancehime) or how is it represented
22:51:04 (trancehime) rather
22:51:06 (Chirei) Ahh.
22:51:10 (trancehime) and how can I extend it so people cna make their own versions
22:51:36 (Chirei) Well I can probably tell you what triggers a prompt but not in a code form
22:51:52 (trancehime) doesn't need to be in code form
22:52:01 (trancehime) i just need the concept

[Jq1790]

As far as I understand it, card games are built around a core set of rules, and the cards themselves are designed to either enhance the usage of said rules, or to directly disobey them.
Ex(Enhance):  Gain power when in certain parts of a turn, etc.

Ex(Disobey):  Choosing a YGO! example.  Solomon's Lawbook, a Trap, causes the pleyer of it to skip a phase of their turn they'd otherwise encounter as a normal part of gameplay.

Also there are ones that introduce new rules, such as counters, alternate win conditions, and the like.

I'm not sure if I'm answering the question properly, but I figured I'd try.

[trancehime]

Well I suppose it is important to establish an important set of baseline definitions, but I'm looking more indepth into mechanical, virtual representations of the rules you just mentioned. For example, can we model these rules in the form of "if <antecedent> then <consequent>" statements? Would that be cumbersome, or is there a more effective way of representing them?

How would "counters," "alternate win conditions," and the like be modeled under such a computational form?

[theshirn]

Several of my friends and roommates are crazy MtG players and a couple are actually judges.  The average player has absolutely no idea of the depth of the ruleset and the evolution it's undergone.  Try explaining what a replacement effect is, for example, or why it matters.

I don't think static vs. conditional is a very good way of attempting to split the approach because so very few cards are still static.  Virtually every single card that's come out in the past few years for MtG has additional effects or abilities.  I remember when I first played MtG and there were cards like Knight Errant (2/2 for 3 mana).  But flow of the game is all about card advantage and combos, and creatures with no abilities are virtually never worth playing.

In terms of a computational model, the extreme density of rules in MtG would require very specific orders and checks for effects, whereas something simpler like Monopoly Deal would only require the time available for players to react with a Just Say No, as it's the only major reactive card.  Passing priority in MtG can be extremely important and requires the direct input of each player, in contrast.

Things like counters and alternate win conditions are also interesting.  Counters, I suppose, would be another element of the card class (though it would get irritating/wasteful tracking things like charge counters across a game when only one card uses them, while +1/+1 counters or poison counters would require a bit more thought, and hello there proliferate).  Alternate win conditions are also interesting, not really sure how to model the game around them.  Hmmmm...

The major things to model to me really seem to be objects (the cards themselves), effects (what the cards do), and phases (when things happen).

[OverlordChirei]

How would "counters," "alternate win conditions," and the like be modeled under such a computational form?

From what I know playing some of the few YGO games, this has gone through some change (for the better).

If by counters you mean like, little bits you place on a card to indicate something, the most recent one I played actually sets the counters on the affected cards when the effect(s) that place counters fully resolve, and they even have different sprite art for each kind of counter. Most of the effects in YGO are almost worded like if/then statements already, and most of this stuff comes out when these statements fully execute without interruption.

Alternate win conditions are another one. Normally one wins when Opponent LP <= 0, but from what I can tell, each new game seems to incorporate each of the new "instant win" conditions alongside the regular condition for the duel to end, like Exodia, Destiny Board, Etc. When one of these alternate statements gets fulfilled, not only does it give the player the win, but it begins playing a special animation or cinematic related to it before doing so, which I assume would be another part of that separate condition.

...I hope that made any sense.

[Momijibot]

Non-programmer here, but the way I'd split it up a little like this:

-Write the rules for play, ignoring cards with special effects which allow them to break the rules. Split them into subsets - let's say "summon", "win", " draw", etc.
-For each card in the database, note under which conditions it can be played, as well as it's effects - for cards without special rules, using a tag like "summon" could refer back to the ways it could be played within the rules. If a card cannot be played standardly, then don't apply the tag - instead, write it's rules within the special section.
-If you're building a program to play the game, offer oppurtunities to react after certain cards have been played - maybe make a check to see if any player can react based on the cards in their hands/the rules, and if they can react provide a prompt for them to react.
-After all the cards that can be played in reaction to he first card have been played, check conditions, such as "win" conditions and such. Maybe also program win condition checks for each phase, so drawing exodia would be checked as soon as it's drawn. For alternative conditions, maybe include them in the card's programming?

A good example of programmed card games would be the tag force series for the psp, or the GX games on the DS.

[Stuffman]

Unless you are looking forward to hardcoding every unique card effect, cards will need to contain some very sophisticated data.

Imagine trying to code a card like Necropotence. I'm not even sure how to approach programming that. One way is to have the code check if you have Necropotence in play during the draw step, but with the number of cards in the game that will quickly become maddening. Basically, I think the draw step would need to have lists of all the cards in play affecting it.

So basically, when Necropotence comes into play, it adds itself to your draw step list. Then when your draw step comes up it sees Necropotence in the list, looks up the card and in the rules field it looks for the header "Draw Step" and finds the script "SkipStep" or whatever under it.

In other words there will need to be a universal scripting system for the cards, where each card has its own code on it.

[trancehime]

The major things to model to me really seem to be objects (the cards themselves), effects (what the cards do), and phases (when things happen).

Sounds about right and probably the most important thing that I garnered from your post.

In any case, while I did list MTG as an example, I'm well aware that trying to deal with the depth that it provides is probably going to be a huge headache, considering Stuffman presented the example of Necropotence. Even cards with very simple effects like Time Stretch may be troublesome to model as they are very dependent on how the concept of "turns" and other fundamental card game concepts are modeled in and of themselves. I'm not also trying to consider building a system that even comes close to matching the depth of MTG, that's a bit too much at the moment.

Personally, I've tried to spend some time considering the intricacies, but simulations have always gone awry as I have not yet found a way to properly deal with the dynamic nature of cards without shooting myself in the foot.

[theshirn]

Sounds about right and probably the most important thing that I garnered from your post.

In any case, while I did list MTG as an example, I'm well aware that trying to deal with the depth that it provides is probably going to be a huge headache, considering Stuffman presented the example of Necropotence. Even cards with very simple effects like Time Stretch may be troublesome to model as they are very dependent on how the concept of "turns" and other fundamental card game concepts are modeled in and of themselves. I'm not also trying to consider building a system that even comes close to matching the depth of MTG, that's a bit too much at the moment.

Personally, I've tried to spend some time considering the intricacies, but simulations have always gone awry as I have not yet found a way to properly deal with the dynamic nature of cards without shooting myself in the foot.

Oh, don't get me wrong - I'm not saying you should code or model MtG, that's an insane amount of interactions and exceptions and uggghhhh.  I brought it up as a pertinent example of the way things can and perhaps should interact and the different areas you might want to look at.  To simplify things, your best bet is to reduce the number of cards/effects that directly interact with each other.  Monopoly Deal, again, just has the Forced Deal/Deal Breaker/Whatever the other one is/Just Say No; cards will need a number of flags (action cards played as money, for example) but the interaction is much simpler there.

[trancehime]

Just want to clarify that I'm looking up ideas for a way to unify these concepts so that I can provide a system that allows people to create their own kinds of card games, however simple.

To simplify things, your best bet is to reduce the number of cards/effects that directly interact with each other.  Monopoly Deal, again, just has the Forced Deal/Deal Breaker/Whatever the other one is/Just Say No; cards will need a number of flags (action cards played as money, for example) but the interaction is much simpler there.

Just highlighting this, most importantly the point on flags. But yeah I'm trying to think of ways that people could actually emulate or copy these effects in digital form, but in a more generic manner that isn't basically carbon copy implementation.

[theshirn]

Just want to clarify that I'm looking up ideas for a way to unify these concepts so that I can provide a system that allows people to create their own kinds of card games, however simple.

Just highlighting this, most importantly the point on flags. But yeah I'm trying to think of ways that people could actually emulate or copy these effects in digital form, but in a more generic manner that isn't basically carbon copy implementation.

Ah.

Okay, this seems to be a bit more ambitious than I had thought.  Even allowing for simpler games.

Hmmm...things to include would then be, as said, classes for cards, events, and phases. 

-Cards would have to be very open-ended and would probably be where most of the coding went, as you'd have to have dozens if not hundreds of available flags and values able to be set to allow people any real amount of freedom to create with.  Something like MtG probably has several thousand, but the hell with that.  On the other hand, it's interesting to note that something as simple as a deck of playing cards only needs a couple values to be tracked for each card...

-Events would be interactions between cards and would probably consist of an extended series of checks when abilities are played, making sure they're legal and allowing for reactions if applicable.  The Stack, effectively.  Perhaps something along the lines of whenever a card or ability is played, it's treated as an Event.  The advantage to Monopoly Deal's model, for example, is that you only need to track one player's actions at all times except during Events where they play an action card, as that's when other players can play Just Say No, rather than having instant-speed abilities always available.  Perhaps this might fall more under the Phases, though.

-Phases...to be honest I am really uncertain how one would code phases!  I guess states that either cause (draw step) or allow for (main phase) Events to go down and that iterate either automatically or requiring input from the player.  Things that change phases - like "Skip your draw step" could be effects added at the top priority to the phase that the game checks first - honestly those don't seem too crazy by themselves.

...huh.  Now I'm tossing around the idea of coding a playable Bridge program in my head.

[hyorinryu]

In my experience with play yugioh online (dueling network, genesis,yugioh network), what they did was just have the cards there and rely on the players to know what to do.

To elaborate, you would have the cards and you could pretty much do what you wanted with them. Like while they may have sections to sort between what goes in what zone, you could" activate" the cards any time you wanted even though doing so was not a legal move.

To prevent abuse or games not going the way they should, moderators were hired to ensure that rules weren't being broken. Like, if I activated mirror force doing my turn and I didn't relent when called out on it, he/she would call a moderator, and the moderator would make me take it back or deal me a penalty in some way.

There are a few flaws with this approach, yeah. Due to understaffing, mods could take 15 minutes to come, and god help you if someone didn't know the rules and made you need to call the mods more than once, but overall, I found it effective enough to play.

It's also worth mentioning that the aforementioned sites were free to use.

I don't know if that's what your looking for, but those are the applications I used to play yugioh and the approach they took. They were fairly popular too.

[trancehime]

-Cards would have to be very open-ended and would probably be where most of the coding went, as you'd have to have dozens if not hundreds of available flags and values able to be set to allow people any real amount of freedom to create with.  Something like MtG probably has several thousand, but the hell with that.  On the other hand, it's interesting to note that something as simple as a deck of playing cards only needs a couple values to be tracked for each card...

True, while my main concern here is a basic framework on how this and other related things, like what would be discussed eventually - effects/actions of cards, would also be represented. Stuffman mentioned the idea of scripting, I am considering that. Problem is it needs to be simple enough for non-programmer to be able to learn and understand. That's quite difficult.

-Events would be interactions between cards and would probably consist of an extended series of checks when abilities are played, making sure they're legal and allowing for reactions if applicable.  The Stack, effectively.  Perhaps something along the lines of whenever a card or ability is played, it's treated as an Event.  The advantage to Monopoly Deal's model, for example, is that you only need to track one player's actions at all times except during Events where they play an action card, as that's when other players can play Just Say No, rather than having instant-speed abilities always available.  Perhaps this might fall more under the Phases, though.

Stack would be used, to represent many things. A deck of cards could be represented as a stack too. Stack queue for event checking may be a potential way to get through it actually. Main issue being a seamless way to actually handle reactions.

-Phases...to be honest I am really uncertain how one would code phases!  I guess states that either cause (draw step) or allow for (main phase) Events to go down and that iterate either automatically or requiring input from the player.  Things that change phases - like "Skip your draw step" could be effects added at the top priority to the phase that the game checks first - honestly those don't seem too crazy by themselves.

Still need some time to mull over this one.

I don't know if that's what your looking for, but those are the applications I used to play yugioh and the approach they took. They were fairly popular too.

As much as possible I am looking for an optimum amount of automation, while "players should already know how to play" systems already exist, my main focus here is a system that can blend the prototyping with the design/creation process.