A lot has changed since the last post – the flight system has been nailed down and work has begun on physics networking, with content creation supported by our rapid-iteration process. Because these systems have been discussed in detail in technical documentation, some of the following information will be quoted in the interest of accuracy and time.

In order to quickly produce and test in-game objects such as ships, guns, and bullets, a pipeline has been created that allows for simple derivations that result in divergent behaviours. The following diagram is a quick look at our current project structure (click for a better view).

Core C++ functions are exposed to blueprints via the UCLASS, UPROPERTY, and UFUNCTION macros, which act as a kind of access specifier (see https://docs.unrealengine.com/latest/INT/Programming/UnrealArchitecture/Reference/Functions/index.html). It is this system that has allowed for such flexibility – the custom classes listed in the above diagram consist of core functionality needed for all deriving objects – the AShip class, for example, contains the methods that control the application of thrust and torques to actually fly the craft.

The base blueprint layer allows for core functions to be called easily whilst still defining base behaviour – all spaceships will call the functions to thrust forward when the forward key is pressed, for example, so the base level of blueprints handles this reaction. The deriving blueprints simply alter the UPROPERTY variables, such as the ship’s maximum thrust values (MaximumForwardThrust and so on), which define the ship’s flight characteristics. The mesh is also chosen at this level, and cameras re-positioned to match.

Player input is primarily handled inside the BP_PlayerController object, where messages received from the input manager are processed, and turned into events that the player’s ship utilizes. This is done through a variety of Blueprint-based interfaces, such as BPI_FlightControl, which features events pertinent to flight management such as thrusting and rotation control. These events specify the functions that any implementing object has to define.

BPI_FlightControl’s PitchEvent.

Note the ‘Dummy’ parameter. As of v4.3, this is required to have the implementing function appear in the Pawn’s blueprint.

When the controller despatches an interface message, a Pawn object is required as a parameter (separate to those defined in the interface’s own blueprint fields). As this specifies the pawn that will receive the message, the controlled Pawn should be used (GetControlledPawn node).

For brevity’s sake (particularly when doing server-based physics, and thus with ships transmitting their own physics information to the server), if an input is received with a value of 0, it is discarded. This is necessary due to the functionality of AxisEvent messages, which are received every frame regardless of their contained value. Overall event traffic is reduced, as is the number of packets transmitted over the network.

Physics for the client’s locally-controlled Pawn is computed on the local machine, with its location, rotation, and linear and angular velocities transmitted to the server on a regular basis. This information, upon being altered on the server, will replicate to all non-owning clients, and thus other players will see each others’ movements.

In the above setup, the server still needs to preside over all collision checks in order to maintain consistency. As a result, all clients have Ship collision disabled, and the server will, upon detecting a collision, transmit the impact location and normal to the offending client, which will use this information to modify the local Pawn’s physics information.

The above solution is not without its issues, though, as integrating an externally-calculated physics collision with a local simulation is quite a task, let alone one done smoothly and without the player noticing. At this point, full server-side physics computation, even with the client-side prediction needed to make it possible, could well be less arduous, and far more practical. This decision will have to occur at a later date when the nuances of other in-game elements, and how they interact in a networked situation, become apparent.

This could be said for the entirety of the project, however. There is a significant investment in the R&D area of production, but it seems to be paying off – we can rapidly iterate on existing ideas, network multiple clients together, see synchronized shooting effects across the network, and so on. These developments will only continue to improve.