This project implements a general multi-player board game, providing a flexible platform where between 2 and 4 players will be able to play turn-based grid-board games. This rules out (for now) games like Risk, but will allow a wide variation of games that can be played on an orthogonal grid (not necessarily rectangular, it could have areas that are masked as unavailable). It will be flexible enough to support variations of:

• Chess
• Go
• Checkers
• Five in a row
• Stratego-like variations, including 2 player and 4 player, where each player sees only his/her pieces

This project will initially include the following components:

• a web service based (initially ASMX) property bag store ***
• a Winforms client for grid board games ****
• broker functionality *** for the property bag store that enforces players playing only when their turn comes and with correct moves, and eventually may allow for AI players

With proper decoupling and interfaces, these components can be used independently, e.g. the property bag interface can be implemented via REST APIs, or a SilverLight or TypeScript browser app can be used instead of a thick client.

This is a work in progress, so the interfaces may change with time, but feel free to fork it.

Last edited Sep 23 at 12:24 PM by radurusu, version 1



Documentation --- property bag store
Proposed API's, using strings as generic types for any data as well as possible exceptions returns. The semantics will be up to the caller.

IMultiValuePropertyBag with the following methods
- SetState(string key, Dictionary<string, List<string>> state) returns string with exception reason
- Dictionary<string, List<string>> GetState(string key)
- MergeState(string key, Dictionary<string key, List<string>> state) returns string with exception reason

Last edited Sep 23 at 12:28 PM by radurusu, version 1

Documentation Go broker functionality
The broker functionality for the property bag store is an optional feature that will do the following:

1. enforces players playing only when their turn comes
2. enforce players playing correct moves
3. eventually may allow for AI players

While this functionality could also be done on the client, there is a strong case that it should at least be an option on the server. The client code might be more targeted toward UI and/or in loosely typed languages, and in those cases one may want to have a hook on the server.

The hook will be in the calls to save and append/merge state. If any of the keys have the form Broker:xyz, they will be intercepted and dispatched according to the xyz. Depending on the diagnostic level, the Broker may append a key of the form, each time it handles a message:
<e><k>Broker_message</k><v>timestamp: message</v><e>

It might be a verbose message if handled successfully, a warning message on failure to dispatch, or an error message if the handler code denies a state change (e.g. out of turn, or incorrect move). Further, in cases where an AI player is needed, and event that signifies the turn of an AI player might result in the AI player being invoked directly. Hooks into game engines such as GnuGo or GnuChess may be left as exercices to the reader.

In case of failure, it also returns to the caller an exception message