Strategic Game Engine
There are plenty of games involving strategy. Tabletop, computer, miniatures, and so on, are used vastly to somehow reproduce conflicts.
A large number of wargames are made of tabletop miniatures games. Warhammer and Confrontatiòn are two of the probably most played games all over the world, in their respective categories. Note that they each have something in common: building an army is expensive. It can be fun to paint and try new units, but budget is often limited. Here comes Strategic. It's intended to be a customizable engine, able to reproduce the behaviour of any strategic game, from chess to Warhammer 40K. It should be something like a framework, more than a game itself.
Initially, the idea was to create an implementation of the rules of Warhammer 40K, allowing me to play-test armies without buying useless miniatures. Then, I thought that I would probably violate some trademark and/or copyright. So I decided to think big, aiming to develop a configurable engine, able to load and run a game described in an external package, independent from my software.
We can see four main components: the Strategic Engine, the Command and Control interface, the Rule Engine, and an Artifacts Engine.
Strategic Engine: The core of the system.
Command and Control: The user interface, used to control the engines.
Rule Engine: Able to read and apply a set of rules described for a certain game.
Artifacts Engine: Manages every item needed by a game, like units, buildings, pieces, scenery, bullets, and so on.
The strategic engine has features to manage game sessions, load game packages, save games, validate game packages, manage user accounts, and so on. It's the core of the system, and other modules will rely on it.
Command and Control
The idea is to have a generic control interface, upon which we can plug any kind of interface, like a web-based front-end, a client GUI, a remote shell, plain text files or mails, everything based on a single interface. In this way we can choose the best interface for a given game, or even multiple interfaces for the same game. We also need to manage user privileges to distinguish simple gamers from admins and developers.
Based on a rule engine like Drools, the rule engine manages game rules. It can load them from a game package at runtime. A rule engine is a device which allows users to develop complex business logic using a human language, and then apply it in the software.
Generates any kind of objects needed by a given game set, and manages persistence, ownership, state, and so on. System will load a game package, then ask this engine to generate entities described in it.
The strategic engine is the core of the system; its functions include game session management, game package validation and loading, and user account privileges. It provides basic services which can be used by other modules.
Game Session Management
The system exposes interfaces to core features, allowing an administrator to manage the server, and users to play games. Configuration should be performed using files as a basic way, or using one or more of the interface implementations provided by the Command and Control module. A good idea would be to implement a command-line interface as a basic choice. Permission management should be implemented at the interface level, providing a single point of access for all configurations. As an example, see FreeCIV server, where all admin operations can be performed using a built-in CLI, and clients are separated from the server. It also manages game turns as described in the game package, and determines which, or whose, pieces can take action.
Game Packages Validation and Loading
Another function of the core engine is to validate and load game packages, which will be described later. The system will load a package, verify its correctness and compatibility, and if it passes validation will deploy it in the server.
There should be a standard package definition, just like there is one for WAR, which will define mandatory and optional components, as well as package structure, configuration files, and so on.
User Accounts and Permission Management
Different games can require different user management behaviour. It can be an anonymous system requiring simply a nick-name, or a complex role system allowing different privileges for multiple users and groups, requiring one or more different kinds of authentication (certificates, passwords, etc.).
Server should also provide services related to data persistence. File storage, user information, game saves, statistics, and other saved data should be independent from the game definition. The engine will provide an abstraction of the data source/storage system, allowing a more standardized way to implement modules. It should support both DBMS (perhaps using JDBC) and file-system storage.
Every game involves in some way various kind of calculations. This module will provide implementations of various algorithms and data structures which can be used by game modules. This includes path-finding algorithms, two- and three-dimensional geometric calculations, collision detection, line-of-sight calculation, Z-order, trajectory projection, and so on.
Command and Control
The command and control module is the interface between the core and the user interface; that is, it comprises an interface which exposes services to the plugins. Services work using either plain text or XML messages. The interfaces would be simple, and allow developers to build complex plugins upon them. Possible plugins include a command line interface, web front-end, client applications, electronic mail, and plain text files.
The command-line interface is the basic user interface, like the admin console present in FreeCIV. This allows the game to be used over Secure Shell, with authentication and support for remote connection.
A full-screen text-mode interface would also be useful, using a character library such as curses or s-lang.
A dynamic web application like OGame, with the difference that it's not part of the strategic server itself, but interfaces with it using web-services. There is no restriction about language used, or location of the web-app, but it should rely on centralized authentication.
Any kind of client application, with no restriction about programming language used or Operating System.
Commonly known as PBEM, it's a very common way to play turn based strategic games. Reports are sent to players as plain text mail (or e-mails); the players send back orders to the server or game master in the same way. This is of course an asynchronous system, where turns can take hours, or even days.
PBEM wikipedia page.
Plain text files
Very similar to the PBEM concept, commands could be given by uploading a plain text file to the server. This is similar to the system used by VGA Planets, for example.
This category includes every module related to computer-controlled opponents, bots, artificial intelligences, and every piece of code devoted to an automated control of the server.
A rules engine is a piece of software which allows you to describe the logic of an application using a human-readable language. It's separate from class implementation, and can be written by non-technical people.
Given a set of rules, the engine can take an object, test it against defined rules, and take the appropriate actions. The skeleton of a rule is:
if <condition> then <action>
Game Life Cycle
Rules engine will be heavily involved in the life cycle of a game. It can be used for game setup, moves validation, events management, change of status in entities, and so on.
A game session would involve a sequence of actions related to the rules engine which can resemble this:
- Setup of game session
- Validation of user pieces selection, if needed
- Validation of user pieces placing, if needed
- Validation of user moves
- Elaboration of events
- Update of game status
Games Using Armies
Rules Loading and Persistence
Whenever a game package involves the use of some kind of object, this engine will carry on the job to generate, maintain, cache, update and save it. Game packages will come with files describing application objects they need, which will be read by the engine. Then it will expose them to the core so that it can use them. It will also provide built-in artifacts that any game package will be able to use without defining them (for example, tiles, pieces, teams, units, and so on).
Conceptually it is similar to the Factory Method Pattern, since it provides objects at run-time. It provides some basic built-in entities, plus those defined inside the game packages. For example, it can provide a generic built-in "tile" object, or the package-defined "infantry unit".