sanderman.org  

Home

dave news

Game programming

[NYI] Stuff

Solitaire Spec

I would like to produce a simple, scriptable solitaire game capable of playing games like Klondike, Freecell, and Pyramid. I would like to have a construction-set mode to make it easy for people to create their own games.

There are three major components to the game. The first is overall application state management. This is the code that keeps track of what state the game is in and what happens when you go from one state to another. For example, let's suppose the game will have a little "yay" animation after you win a game; the animation plays for a few seconds and then the game takes you back to the choose-a-game menu. The state management system is responsible for making those actions happen. Every game needs a system like this.

The second main component to the game is a UI system to allow clicking and dragging cards and card piles and such around. Chances are, we could get away without it for this game; we could just use Windows Forms and write some UserControl-derived classes and keep it nice and simple. However, that's not really a good option once we get to more complicated games which have 3-d graphics and which run in full-screen mode. If we go through the effort now of building a control/dialog system that we control completely, it'll be one less thing we have to do when we get to doing a more complicated game. There's a second benefit to doing things this way: if we build a control system which includes an edit mode for our solitaire "construction set" capability, we can use it ourselves to build our dialogs and menus.

The third main component is a scripting system. I would like it to be easy to create simple variations on the common solitaire games, and I would also like it to be easy to create whole new kinds of solitaire games. Providing a simple in-game scripting system is a cheap and easy way to do that.


The game's app state system is responsible for managing all of the application state transitions. Here are the app states that I've identified:

  • Idle: Waiting for the user to start a game. From here the user can go to Construction or Playing.
  • Construction: The user is in the construction set. Depending on how this works, the user might be able to switch back and forth between this mode and Playing, but in general their only way out is back to Idle.
  • Playing: The user is playing a game. Possible next states are Winner, Loser, and Idle (if the user quits the current game).
  • Winner: The user won. Plays an animation then goes to Idle.
  • Loser: The user lost. Plays an animation then goes to Idle. Note that if we implement an "undo" function, the user should be able to undo out of this state.

These are all of the major application states. It's worth mentioning that there are going to be sub-"states" during the run of the app that don't fit into this list. For example, if we have a UI model where the user moves a card by clicking on a card then clicking on the pile where the card should go, the app will sometimes be in a state where the user is clicking on a card and sometimes be in a state where the user has clicked on a card and is clicking on a pile (whew). Why don't those states belong in this list? Well, I think it's a matter of scale; I think the application state manager should handle state changes that affect the whole operation of the game. Changing minor UI states seems too "lightweight" for this system.

TODO: Okay, now that I've got the states specified, what are the behaviors of each state? And how do I implement the states and state transitions?


//$ ui system has two modes: use and edit need to support popup-type dialogs basic use-mode is pretty standard (OnClick, OnKey, etc) think about integration between UI and game -- in solitaire it's hardcoded, in puzzle game and rpg it's probably script-targeting -- be nice if there were an easy way to data-bind for checkboxes and edit items and whatever 'pile' object has min height == card size; larger heights cause face-up cards to fan out 'pile' object itself has to do its own hit-testing etc -- this should probably be all native code so i don't have to expose all this random crap to the script engine todo for ui system:

  • design ui experience
  • design ui system


todo for scripting system:

  • design basics of language
  • design basics of execution
  • write a parser generator
  • write a lexer
  • write a code generator
  • write the execution engine


Game links:

GameProgBlog

File Manager

Resource Manager

Scripting


Solitaire spec