Input processing in Cabo Trafalgar

If you haven't read multiplayer-modes-in-cabotrafalgar, you should do it now, as "mode 0 - 3" are explained there, otherwise you won't fully understand this article.

This should be the first of a series of articles to explain how to extend Cabo Trafalgar with more and different controls, modules and ships (these are, not by chance, the three dimensions Cabo Trafalgar relies on).

The aim of this article today is explaining why it's not a good idea to rely in the Jme3 Input Manager directly if you're planning to have several multiplayer modes like Cabo Trafalgar does.

In little words, we need to cover the following cases:


Player's input to local game
Player -> Keyboard Input -> Ship calculations locally -> Render locally


Ghost representing past game by same (local file) or (recordserver online service) another player
Downloaded game -> Ship position is set externally -> Render locally


Remote input to local game (multiplayer mode 1)
Remote player -> Remote input -> Ship calculations locally -> Render locally


Multiplayer (multiplayer mode 2 and 3)
Player -> Keyboard Input -> Transmitted to server
and
Server position calculations for all ships -> Ship position is set externally -> Render locally


Player's game is stored in local file or remote server for future ghost/reference
Player -> Keyboard Input -> Ship calculations locally -> Store to file / server


As you can see, if you want to cover at least two of these modes, you need to detach the following elements and combine them according to your needs:

Renderization (AShipModelZ): What we render is a representation of a ship (and other elements), whose position, rotation and scale is known to us, but not how or where they have been calculated. They can come from:

1. Remotely calculated ship (ShipModelZGhost): This element takes a stream of data from a server (mode 2 and 3) or a file (mode 0) to know what's the position of the ship every frame.
2. Locally calculated ship (ShipModelZPlayer): This element calculates following position, rotation and scale from previous + input. Input can be:
1. Local input (keyboard, wiifit, joystick...) (InputManager -> KeyboardGenerator -> ShipModelZControlProxy)
2. Remote input (mode 1) (RemoteInputCommandGenerator ->ShipModelZControlProxy)

Also, in mode2 and mode3, there's a need for transmitting user's input. It hasn't been implemented yet, but it would take InputManager -> KeyboardGenerator -> ShipModelZControlProxy -> ShipModelZTransmitter (inexistent yet).

Input will deserve another post itself, as it can be more complicated than it seems :)

In the diagram below, green classes belongs to the api, no real meaningful functionality on them, in yellow, ShipModelZ implementation of them: