The configuration class

Introduction

In Colored Trails the game logic is separated from the rest of the system. This provides the researcher (game designer) with the necessary flexibility to implement different types of games. Also, it lets him/her concentrate on the game logic, rather than infrastructure issues such as networking and communicating state changes.

To design a game, one must basically create a game configuration class. Such a class is what defines the logic of the game; this class will communicate with the server through an established API that will allow control over nearly all aspects of the game. Indeed, the design philosophy of the CT system is to allow the game configuration class to customize as much of the game as possible. For examples and illustrations on how to use the API in the configuration class, please refer to the Configuration class How-To.

A CT configuration should extend coloredtrails.shared.types.GameConigDetailsRunnable. The source file should not belong to any package and should be saved in the gameconfigs/ subdirectory. At runtime, the game configuration file will be dynamically loaded by the Colored Trails server via the "add configuration" command. The game configuration class is then executed on the server's JVM.