The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

card game engine?

Any one have references to how card games are built (data structures, algorithms)?  The following website has some code in Javascript I'll be checking out, if any one has more references, please post them here:
http://www.howtocreate.co.uk/tutorials/jsexamples/solitaire.html

If possible, I would love to have any material that explains how to implement a card game using logic programmnig or constraint solving systems (academic computer science papers will be perfect).

Thanks.
falcon Send private email
Thursday, July 06, 2006
 
 
Err...

In general, you want to look at "game theory" as a mathematics field or as an economics field. The best known example is Prisoner's Dilemma.

http://en.wikipedia.org/wiki/Prisoner%27s_Dilemma

http://en.wikipedia.org/wiki/Game_theory

For card games, you'll also want to take a quick glance at the field of statistical theory as it relates to game theory. (The latter is interested in all of the possible "actions" that can be taken as well as the "rewards" whereas the former is also concerned with the probability that those "actions" will occur. Naturally, there's some overlap.)

That said, keep in mind that these topics are arguably more suited to developing games like Magic: the Gathering or Texas Hold-em, including the decision whether to bluff or call. If you're looking to make games on the level of War, Speed or Blackjack, I seriously recommend that you just get out a deck of cards, a piece of paper, a pencil and experiment.
TheDavid
Thursday, July 06, 2006
 
 
Separately...  most collegate level textbooks on data structures will usually have sections on how to sort a deck of cards and other such tricks. I'm reluctant to recommend a specific edition because the editions change so frequently yet the material pretty much stays the same.

So just head over to a local college or university bookstore with a decent computer science department, look for a textbook on data structures and/or algorithms and peek at the table of contents to see if they use card games for any of their examples.  :)
TheDavid
Thursday, July 06, 2006
 
 
>>That said, keep in mind that these topics are arguably more suited to developing games like Magic: the Gathering or Texas Hold-em, including the decision whether to bluff or call.<<

I just have to step in here.

With a typical face card game, there are only 52 card possibilities, (54 with jokers).  The attributes of each card are simple - a rank and a suit.  The rules of the game remain static (the hands are always the same, the winner always gets the pot). 

Collectible card games (such as M:TG and Yu-Gi-Oh) are completely different.  Yes, each card has attributes (magic cards have casting costs, colors, power/toughness, etc), but card mechanics are described in natural language.  The cards in play literally change the rules of the game.  Not only that, but you can sometimes have cards that change the text of other cards.  You need a far more robust software architecture just to represent how the game functions.

If you're implementing the latter, study up on software architecture - particularly implicit invocation.  I can tell you it's no easy task.
delete this
Thursday, July 06, 2006
 
 
I can do the sorting and the shuffling, I was trying to understand how to extract a single engine for a number of similar card games, how to organize the deck vs locations where cards can (and can't be placed), how to encofrce rules about which cards can be on top or under other cards, etc.
falcon Send private email
Friday, July 07, 2006
 
 
heh...I missed the part about taking out paper and pencil :)    I just bought a book which lays out the rules for more games than I knew existed.  I was hoping to extract out the rules and try building a little DSL which could, in a few lines describe a whole game.  It isn't often that you get something like a card game, so well understood by the general public, yet is based on a set of fairly strict rules with fairly limited set of 'objects' to manipulate.  Seems like an interesting problem.
falcon Send private email
Friday, July 07, 2006
 
 
I was doing this a few months ago. It isn't trivial, certainly not if you want an elegant solution (and that was what I wanted, more than building the solution itself, as I was using it to learn something). Interesting though, I'll give you that :)

Friday, July 07, 2006
 
 
When it comes to games like Solitare, it should be trivial to definite a set of general purpose rules that handle the vast majority of variations; most commercial offerings these days do advertise anywhere from 20 to 100 versions of Solitare such as Klondike, Spider and... hurm... well, I don't know of any more off hand.

I guess I was being flippant at the time, but designing a game of that complexity is best done with a pencil and a paper - the more variants you play, the more you become aware of the common rules.

As "delete this" points out, it's dealing with the games that change the rules that are problematic. I'd also suggest that the games that require some artificial intelligence on the part of "computer players" are equally problematic. For example, should you bluff on a weak hand, or should you go all-in on a strong hand?
TheDavid
Friday, July 07, 2006
 
 
way back at my first real job, a bunch of us used to re-live our college days by playing the classic drinking game, asshole, after work on fridays. during one of our longer games, we had the idea to build an asshole engine and each one of us would build an asshole client to play against each other. we even imagined holding a world asshole tournament! as you would expect, this idea never got off the ground.

developers and beer. what a combination.
starving coder
Friday, July 07, 2006
 
 
http://en.wikipedia.org/wiki/Implicit_invocation

Why implicit invocation for the Magic card game?
Lenny
Friday, July 07, 2006
 
 
Implicit invocation is used mostly to handle triggered effects.  Consider some simple cases (and these are taken from real magic cards):

Soul Warden - Whenever a creature comes into play, gain 1 life.
Instead of checking for whether or not Soul Warden is in play every time a creature comes into play, it is better to simply add a listener to the duel saying that whenever a creature comes into play, you gain 1 life.  When Soul Warden leaves play, remove the listener.

Implicit invocation can also be used to handle "prevention" effects:

Circle of Protection: Black - <cost>:the next time a black source would deal damage to you, prevent that damage.
Add a listener when you activate COP:Black to prevent the damage that would have been received from a black source.

Implicit invocation can be used to handle "static" effects such as these:

Maro - Maro has power and toughness equal to the number of cards in your hand.
This card is updated every time a card enters your hand and every time a card leaves your hand.  Again, listeners are handy to model this.

I've demonstrated just 3 cards out of over 7000 cards that are currently available for Magic.  When you're dealing with that many cards and that many interactions, it is far better to abstract what is happening rather than check for every single card possible.  I'd say Magic would be impossible without some form of implicit invocation.
delete this
Friday, July 07, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz