Advertisement

Card Game 'Engine' - Feedback appreciated

Started by July 12, 2006 06:35 PM
6 comments, last by scratchimus rex 18 years, 6 months ago
Hey, For my high-school Visual Basic project (Some 4 years ago), we had to create a game of blackjack, well, I made a very buggy version, and was happy with it. I looked at the project the other day, and decided to re-do it, I am now alot more able and experienced, and didn't want to limit myself to JUST blackjack, so I've been working on an idea for a possible card game 'engine' - Appropriately named "sEngine". Now, I've got the very basic requirements of the 'engine' done (i.e. Cards, Decks and Hands), but I'm having trouble visualizing how to design some dynamics, so the engine would work equally well for a game of gin-rumie as it would for a game of blackjack... Rather then creating the engine at the moment, I am just making a game of blackjack, using what I have already created for the engine... I'm looking for some input from outsiders, as I feel I have stared at the same work for the past few hours and got nothing (I keep adding something, only to find it was pointless... (Or just blackjack dependant, which is not what I'm after)). The basics I have is a fair bit of code, so if anyone wants to see it, I'll post a UML Diagram-esque format of the code I have, rather then the whole lot. I don't actually know what I want, just that what I'm currently doing is not right, and almost making me want to just give up.
I can't really comment till I've seen what you've done already :P

What you want is a single engine that will play any card game given a set of rules (in a seperate text file for instance). Thus really you need only program the common operations shared in all card games: order of play, possible decisions by the player (put down a card, pick up a card, make a bet etc). There really aren't that many different operations in the standard card games. Bear in mind that some games use more than one deck.
Advertisement
Don't stop at gin-rummy. Some decks have a different set of cards.

Decks: Decks can be drawn from face-up and face-down. Cards can be put on top or on bottom. Decks can be shuffled. Decks can be searched.

Decks contain some set of cards.

Decks are a specialization of a Pile of cards.

Piles: Piles can contain some set of face-up and face-down cards. You can do anything to a Pile that you can do to a Deck.

CardState: cards can be face-up or face-down. Cards can be in various "card pools", be they global or local to a player. Some players can have the right to "peek at" or "look at" some cards in some pools (like your hand) that are nominally face-down.

Cards themselves:
A card can have various properties.
Sometimes cards are strongly sortable.
Sometimes cards are weakly sortable.
In traditional card games, cards have a suit and a rank. (4 suits, 13 ranks)
Cards sometimes have a "class" -- face vs number card, for example.
In some other card games, there are more/fewer ranks/suits.
In some other card games, there are no suits whatsoever.
Cards typically have a face-image.
Cards typically have a back-image that is shared with other cards (some card games have multiple different coloured back-images).

Game state:
There is room for extra game state. For example, in crazy eights, when someone plays a 2 on you, you start your turn with a "you must pick up two" rule in effect. If you play another 2, the next player starts his turn with a "you must pick up 4" rule in effect.

I'm assuming your goal is to build a card toolbox that makes making card games easy -- not a fully scriptable engine that can implement any card game.

If you want help with the game-flow, you can go further:
Rules:
Rules happen when various Events happen.

Events:
Events are things that happen. Like a card is drawn, etc. Events carry with them a description of what happened (who drew the card from where, what the state of the card was after it was drawn, etc)

Actions:
These are options for players to do. Rules say what players are allowed (or required) to do what actions.

Phases:
Phases are when things happen. In a simple card game, a phase might be "player X's turn". Various players can have various actions they can do, and doing some actions may end the phase.

Rules observe Events.
Rules create Phases and expose Actions to players.
Rules end Phases.
Actions are "buttons" that the player can push. Pushing a button causes code to execute (which can cause Events, end Phases, or modify game state).

But that is getting more complex. :)

In describing the above, I tried to keep everything from blackjack, to poker, to gin, to euchre, to bridge, to wizard, to a hybrid card-board game, to magic: the gathering, in mind.
Picked up a lot, thank you very much.

I worked on something like that. I thought what I had in the end came together nicely, but I stopped development and kept putting it off.

Empty Egg

I kept everything pretty much up to the players to govern. The program only worries about allowing the players to manipulate objects and not whether or not the players are following the rules of the game. That's left upto the other players. There are 3 different types of objects and you can set a background image. Combining those elements you can play a wide variety of games beyond just cards. I have an editor that goes with the program to customize game sets, but it's fairly buggy and not all that user friendly.

Giving the player the ability to comfortably manipulate the objects was tricky. I've grown accustomed to using the controls, but I haven't had anyone do playtesting so I don't know what the learning curve is.
I think NotAYakk's post gave some great ideas about how to program this engine. I would really decide where you want to limit your design. If you want it to be broad enough to encompass any and all card games ever made, you're going to run into a much more complicated system than you might by sticking to a conventional rank/suit combination (which could still allow non-traditional games such as Wizard, Cripple Mr. Onion, Skat, etc. but wouldn't allow something as complicated as Magic). You would then have to decide how you want to design the description format, and build an interpreter for that.

Once all that is said and done, you can construct a nice-looking front-end for it, perhaps something that incorporates 1 or 2 standard deck styles and a couple non-standard designs.
Advertisement
If the rules of the game change from game to game, then you need to create their logic using either DLLs or Scripts.

Using those scripts you should be able to configure the game, number of decks, forbidden cards, number of players, stacks, etc...

This means that the game script has to visually control the playing area, so that card stacks get placed on the correct areas.

Also, are you going to add a money element? Like, for Poker? How about Poker Chips too?

[Edited by - Prozak on July 25, 2006 12:25:43 PM]
Have you seen Thoth? It's a card-game engine, might give you some ideas.


http://digilander.libero.it/zak965/thoth/main.htm

This topic is closed to new replies.

Advertisement