Core Engine Design Document

Introduction

This is just a quick design of how the glob2 core Engine code should look like. Some of the abstractions, such as in Team and Player, may have to wait for other ones to take place.

Team and Player

• Team represents a team in glob2.
• Team is purely engine code. It does not involve interaction in anyway.
• Player is the opposite, it is purely interaction code
• Teams are static for a map and do not ever change
• Players are changeable, sometimes AI's, sometimes humans, sometimes networked players
• Networked players, by the way, will be completely hidden behind player, as opposed to our current design, where orders are pumped through the Net engine rather than being abstracted behind a Player.
• It might not be a bad idea to have different classes inherit player, each one implementing the same interface for AI, the local player, and networked players
• Player is no longer a placeholder.
• Player may return orders like WaitingOnPlayer. When the game engine recieves this, it must hold the game.
• Player net code may hide latency issues by delaying the time between an order is taken from the user and when its executed. However, any order Player gives to Engine is final for that tick, unless Engine chooses to hold when a player is unreachable

Core Header Classes

• There are going to be two classes, MapHeader and GameHeader
• MapHeader is completely static information of the map. In it goes any information that doesn't fit elsewhere in the code, such as the number of teams in the map. There is no game related information in the map.
• GameHeader is all dynamic information of the game. It includes Player information, winning conditions, alliances, and any other information.
• It is *very* important to note that a GameHaeder will have to be distributed with the map file in cases such as Campaigns, but is completely overwritable and not nesseccarry.
• When referencing a map over the net, a map header may be passed. MapHeader contains entirely static information, including, perhaps, a checksum. If two maps are the same, they should have the same header. The client will look for a map with a matching header as the MapHeader it recieved.
• GameHeader will often be generated, as in the case of CustomGames.
• GameHeader may also be read in, as in the case of Campaign files, where game information needs to be set by the creator.
• BaseTeam is to be eliminated. It doesn't serve a purpose in this system.
• BasePlayer just contains a condensed version of Player to be stored in GameHeaders. Player can be created from a BasePlayer, but not inherit from it.
• BasePlayer will definitly need to be renamed.

File Format

• Map file format will be a gzip of several files read in by the Glob2 virtual filesystem.
• The map headers are stored as a sort of meta file in the zip.
• For the time being, the two headers can just be integrated into Game. A Game must have both headers to operate, GameHeader can be generated on the fly as in CustomGames, net games, or read in as in Campaign games.

Extensibility Concerns

• The new system is fairly flexible, despite being simple, there is a clear seperation of data, and new features can be put in easily.