ClientServerArchitecture

FrEee's client/server architecture works similarly to that of Space Empires, with a few additional files. Currently there is no support for direct client/server connections; rather file sharing is required using PBW/PBEM/etc.

Main Files

FrEee uses three main sets of files to store and transmit data between the client and server:

The host GAM file (e.g. mygame_1.gam, with the digit being the turn number) stores the entire state of the game and is used only on the server side.

The player GAM files (e.g. mygame_1_1.gam, with the digits being the turn and player numbers) store the state of the game that is visible to a particular player. These are generated by taking the main game state (as saved in the host GAM file) and calling Redact on everything in the game, to filter out anything the player's not supposed to know about. This is especially important to prevent cheating, as the game is open source and thus anyone could easily read the master file were it available to them. It also has the benefit of eliminating the need for player passwords. But it does require the extra files to be created for each player.

The PLR files (e.g. mygame_1_1.plr, same naming convention as the player GAM file) store commands issued by a player, and use the IDs of the server side objects to reference them, so that players can't cheat by editing existing objects in the game, not to mention prevent bloating the file itself.

Game Setup Files

Additionally, there are files used only for game setup:

The EMP files are used by each player to configure their empire.

The RAC files are used to configure only a race and not an entire empire in game setup.

The GSU file is used to store settings involved in game setup.

References

There are certain classes that exist on both the server and the client, and need to be referred to by the client in the PLR files without actually serializing the whole object and sending it in the PLR files, which would allow for players to cheat by spawning invalid objects, and also bloat the PLR files unnecessarily. So these classes implement an IReferrable interface, which basically just specifies an ID through a Reference class that can be used commonly by the client and the server to refer to the server side object in PLR files. The objects are serialized in the GAM files for each player, so the client can see them, of course; it's just on the round trip that they're referred to by IDs.

There are conversions between the references and the physical objects so they can be looked up (in a referrables dictionary in the Galaxy class; this should probably be split apart at some point), or have their IDs extracted, using an extension method and a cast operator.

Mod references, as opposed to galaxy references, behave similarly, except they use string IDs instead of longs, and are looked up in the current mod. This is used for things such as component templates and hulls, things that are defined in the text files in the Data folder.

Things such as strings and numbers, on the other hand, won't be directly referenced by the client; they'll be part of other objects, so they don't need IDs.