Getting ready for the release of the initial version of the Sunflower Virtual Gaming Table, here’s a little description of how the engine works. It’s built to be very modular and modifiable, and most importantly – to allow as much game creation and modding as possible be done without having to get into the actual project code. So here’s a basic description of the components of a game in the engine, with more detailed descriptions coming in the near future. All the terminology is currently based on card games, but the engine will also support other kinds of board games.
A Sunflower game requires the following – a ruleset, a table, a card set, (optionally) a deck, (optionally) a scenario, and an AI player.
The ruleset is the basic definition of a game in the engine. It fully defines the rules of the game, using a special-made markup language and scripting language. Since both are still under heavy construction, I’m not yet releasing an API, but it will come soon, and then you’ll be able to create all the games you want without having to mess with the engine code.
The table is the visual part, the appearence of the game on the computer screen. Each table is built to handle one or more rulesets, but is not necessarily bound to it – many tables can be used for a single ruleset, so artists are free to design tables that look however they want for any game. The tables are also defined with a custom-made markup language, so of course tables can be designed by artists, without any programming knowledge and without any need for messing with the internals of the project.
The card set is the pool of possible cards to use in a game. Each card has a set of properties, depending on the game – a classic card set will have properties “Suit” and “Value”, WTactics cards will have things like “Gold Cost” and “Attack Value”, and so on. Just like tables, card sets are made for one or more rulesets, so you can easily use a single ruleset to play with different cards.
A deck is a set of cards. Note that unlike a card set which defines possible cards, the deck has actual cards that can appear on the table – each card in the deck is an instance of the “prototype” card from the card set. Thus a deck is specific to both a ruleset and card set. Decks are expected to change with players in many games (such as WTactics), so a deck building mechanism will definitely come in the future.
A scenario is a snapshot of an ongoing game at a certain point. It allows creating games with several modes, identical in rules but different in starting conditions. This is the only basic element completely unimplemented yet.
An AI player is a piece of (compiled) code that knows how to play a certain game. They are loaded dynamically at runtime, so everyone can write new AI players without having to get into the engine code. This will probably be the first thing I’ll write an official API and tutorial for, so if you’re interested in AI, you might be interested in following it.
More is coming soon, stay tuned!