Developing a card game framework

Question

What sort of design patterns and ideas might one use to build a somewhat general purpose card game framework?

This stems from I made an attempt to build a clone of the popular Steve Jackson game "Munchkin". Because of the nature of that game I ended having to hard code so many card functionalities that the development became chaotic and over-bearing. I had wanted to build something general but ended up with just to many classes with to many overridden functions and switch statements to determine behavior.

I was curious what someone with more experience in design would handle such a task of building a general purpose card game framework, or at least something that could be extended. Or is it best that if I want to make a simulation of a card game like Munchkin, i'm stuck making a specific framework.

I would like to use C#.

EDIT

I would like to clarify somewhat of what i'd eventually like to achieve. I'd like a framework where I can basically implement phases with custom functionality (phase 1: draw cards, phase 2: apply upkeep rules, phase 3: play cards, phase 4: resolve, etc).

I think then defining a ruleset would be wise which would be coupled with both the cards and the phases.

Then, the cards would be defined and I suppose tied to the rules so for instance a rule might be "During upkeep phase, lose 1 token". However, a card that the player has might provide "Don't lose any tokens during the upkeep phase". So it would be nice to be able to tie this together but within the guts of the framework.

I suppose this might be way out of my league as well.

Answer 1

I would have used some kind of script language as LUA or Python to define each special behaviors or card.

• http://www.lua.org/
• http://www.python.org/

This way you can define a "generic" engine, and keep the cards particularities away from the main code, into some small and easily editable scripts.

The main advantage of script languages over XML or some other "static" data is that script languages can "create" their own behaviors using the public methods offered by the engine.

Example: suppose your engine offer the methods "setDommage(target,dmg)" and "setVisualEffect(nameOfFxLuaScript)" etc. You can have a cards doing something like this peuso-code

------Card1 -- A simple fireball-----
// Fire ball
setDommage(target, 37);
setVisualEffect("fireBall.lua");

------Card2 -- A multitype ball (outch it hurts!)-----
// Fire ball
setDommage(target, 37);
setVisualEffect("fireBall.lua");

// Ice ball
if( player.protectionAgainstIce == false )
{
    setDommage(target, 102);
    setVisualEffect("iceBall.lua");
}

// thunderbolt
while( player.Alive )
{
    setDommage(target, 1005);
    setVisualEffect("thunderBolt.lua");
}

The both cards use the same engine methods, but they don't do the same things. The behaviors can also use data gathered from the engine (like the player list to loop over them) and for, if etc. statements.

The second but not the least advantage, is that it doesn't need to be compiled. You can modify you LUA script and reload it directly without recompiling your game. It's very nice for testing and iterating until you find the good settings.

The third advantage is that, anyone that can learn script language can create new cards/behaviors as long as you provide a list of the public methods shared by the engine (and as long as you don't encode the LUAs). And as anyone knows, the community is incredible when you give them nice tools ;)

---

Here is a LUA wrapper for C#: http://luaforge.net/projects/luainterface/