Sim:Network
As of May, 2012, I have a single-player simulation running on Java and JME3.
I'd like to bring up multiplayer along the following architecture, which is staked out at the moment. The most unusual aspect of the design is that the game is effectively two games running atop each other: a game of ship clients steaming in a world managed by the server, and a game of player clients walking around and using equipment on the ship managed by the server. The interesting part is the client in the first game (the ShipServer) is the server in the second game. This double-tier design helps ease the load on the servers managing each aspect of gameplay and to create a topology that reduces bandwidth usage.
The overall game architecture relies on four different applications, three of which run on virtualized cloud computing platforms and one of which is the PlayerClient which runs on customer hardware.
AuthServer
A single AuthServer runs on a well-known IP address and processes logins from PlayerClients. It also manages a list of WorldServers that are online or at least defined, as these will provide players who log in a list of worlds that are online. The interaction of the AuthServer and PlayerClients is akin to the first phase of a World of Warcraft play session where a user logs in and is shown a list of shards (worlds) to choose from. After selecting a game world, the Player's PlayerClient would be directed to drop its connection to the AuthServer and be told how to securely connect to the selected WorldServer.
WorldServers that are online may also be connected to the AuthServer so they can report status and possibly to support a means of allowing newly logged-in players a means of seeing where their friends are.
WorldServer
A WorldServer manages an entire, persistent and always-running naval combat campaign game. There may be more than one running at any time, and the various worlds they manage are distinct and separate play environments. They may have different preferences for realism and play style, and they will quite likely have different time/date settings in the simulated world.
Client relationship to AuthServer
A running WorldServer connects to the AuthServer as a client.
Server relationship to ShipServers
The WorldServer simulates a world of naval battles. The "players" in this level of the simulation are essentially Ships and Ports (which are handled much like non-moving ships). Each active Ship or Port has a ShipServer running and connected to the WorldServer. The WorldServer simulates the movement and interactions of ships, port structures, torpedoes, mines and shells and sends updates to each of its client ShipServers.
Server relationship to PlayerClients
Thought its primary clients are ShipServers, players who are joining a game world may briefly be connected to the WorldServer in order to see what Ships and Ports are currently available to them. Upon selecting a world, the AuthServer will generate a random "Joe Sent Me" number and send it to the PlayerClient along with an IP address and port number of the WorldServer, and it will give the WorldServer a packet with the same number and the name of the player who will present it. This hand-off method preserves the relationship between a give player and his connection without requiring servers other than the AuthServer to check the password database. This same hand-off method is used when a player connected to the WorldServer selects a ship: the WorldServer creates a "Joe Sent Me" number and sends it to the ShipServer, telling it to expect the given player to present it momentarily. The trust relationship is thus handed down the last tier.
Simulation
The WorldServer has to simulate the essential movement of every ship, shell, and torpedo and send updates to the connected ShipServers so that they, in turn, can inform the connected PlayerClients what is happening so game events can be rendered for the player to experience.
Precision
It may be necessary for the WorldServer to run with double precision for their 3D coordinate system. It may, however, be possible for it to run largely in single precision, employing double precision only when converting events from one ShipServer's origin to another's (see "Frames of Reference").
ShipServer
The ShipServers act as clients to their WorldServer and as servers to the PlayerClients of customers playing sailors on board the ship being simulated. They essentially manage a game of sailors on a single ship.
Client relationship to WorldServer
When the WorldServer determines that a ship should be spawned into the world, a ShipServer to manage that ship is started up on a virtualized cloud server and it immediately connects to the WorldServer. The WorldServer tells it what ship it will be and it tells the WorldServer what IP address and port number it can accept PlayerClient connections on. The ShipServer loads up the assets and data it needs to portray the ship experience to players, reading from assets from storage and reading data packets from the WorldServer so it can depict other nearby Ships and Ports.
Server relationship to PlayerClients
When a Player selects a given ship at the WorldServer and is given an IP address, port and "Joe Sent Me" number to authenticate his arrival, the PlayerClient will drop its connection to the WorldServer and connect to the ShipServer to introduce itself. The ShipServer, when satisfied with the newcomer's identity, will then pass information to the new PlayerClient so it can render the local ship, the sea and weather state, the external ships, ports and shells and torpedoes, and the local sailors on the local ship.
Role in AI
The AI for sailors on the ship will be executed on the ShipServer.
Simulation
The ShipServer will run a single-precision simulation of the world in close proximity to itself: the origin of its world will be the center of the local ship model. This provides sufficient precision to depict the world out to 30,000m or so. It will simulate the wiring and state of repair and function of the instruments on the local ship so that actions taken at a data transmitter (say) will only cause the proper behavior of the associated receiver(s) if the model of the wiring is intact and functional. This prevents PlayerClients from having to fully grok the behavior of the ship-wide system and certainly spares them from being trustworthy in simulating its possibly impaired state.
[TO BE CONTINUED - TONE]
