SkyGames.NETJustin Nordin
Status DocumentCreated on: 7-12-2006
Introduction
As of this time (July 12, 2006) I am working on the design and implementation of the new SykGames.NET. We currently have two SkyGames solutions and folders in the source control. The first is simply called SkyGames. This folder contains the stable version of SkyGames I created a week ago or so that implements the Entity-Behavior-Rules paradigm and directly uses Irrlicht as its rendering engine. The second folder is titled SkyGames-branch. This folder contains the continual redesign of the SkyGames system that will periodically be copied into the main SkyGames folder. The “stable” SkyGames solution allows development of the Telecom Game parallel to the redesign of the SkyGames core.
My current task, along with Tim, is to work out the interfaces and abstract classes for a client-server model in SkyGames. As soon as the client-server design is locked down, I will rewrite the ExampleGame project to use the new system. We will then begin merging code from the SkyGames-branch folder into the main SkyGames folder and ensure that Khadir’s code is transferred as painlessly as possible. (Currently Khadir is using the stable SkyGames code to write entities, behaviors, and rules for the telecom game).
Current Design
The design for the current SkyGames that Khadir is using is described online in the document “SkyGames Class Overview”. In that PNG file I detail the relationship between the interfaces and implementations as well as providing information on what the programmer is responsible for when creating a working project.
As for SkyGames-branch, we are redesigning the core elements of SkyGames to fit into a flexible client-server model. These pieces are intended to be as separate as possible so that they can be later split up and run on different systems. In the future it should also be possible to write new clients in different technologies to connect to a SkyGames server. The following diagram depicts the broad design overview of the SkyGames-branch.
In bold are the concepts (client, network, and server) and in regular text are the actual interfaces in SkyGames. Italicized text represents data that is being passed, though not necessarily through a specific interface. (“Request actions”, for example, represents data being sent to the server through the network, most likely through a function in the network interface).
Server Design
The ServerModel is responsible for the game or simulation logic. All entities, behaviors, and rules are programmed on the server side and the ServerModel is responsible for keeping a list of all of the entities, behaviors, and rules associated with a given simulation. For now this is an array or List> type object inside the ServerModel class itself, later these can be stored in a database.
The ServerModel is responsible for four main things. The first is to keep track of all the entities, behaviors, and rules (see above). Secondly, the ServerModel supplies to the client a ClientContext, a representation of the current state of the simulation as the client sees it. Finally, the ServerModel receives action requests from the client and must execute the proper behaviors on the server side. Each behavior that is executed receives from the ServerModel a ModelContext that describes the current state of the simulation as the behavior sees it. The server is also responsible for communicating errors to the client.
Client Design
The ClientModel is responsible for displaying the current state of the game or simulation to the player and relaying the player’s actions to the server. The ClientModel receives a ClientContext from the server that describes everything that needs to be displayed on the screen as well as a list of available actions. Actions get mapped to behaviors on the server side, but the client only sees a subset of the total behavior set and does not directly deal with behaviors to allow as little coupling between the client and server as possible.
The Device interface on the client is responsible for the actual rendering of the graphical elements to the screen (or eventually web browser) and for mapping input (keys, mouse clicks, etc.) to the ClientModel’s actions. In this way physical input is abstracted from the actions they perform, which is abstracted from the concrete behaviors they perform. These levels of separation allow enough flexibility for SkyGames to run on many different types of systems, in theory.
Network Design
The network provides a simple interface that allows data to be sent to and from the client and server. Right now the network is a dummy network whose only task is to pass data between the ClientModel and the ServerModel. Later, the network will handle networking protocols as well as synchronization. The purpose of the network in the current SkyGames-branch is to allow for a future separation of the client and server. For now they are only concepts residing on the same system.