It's been almost two months since Black Prophecy Technical Director Cyrus Preuss published his second Game Physics diary entry, but he has returned today to discuss how players will interact with the physics engine.

"Amongst other things, he explains the difficulties of having a good balance between realism and fun and how the player ship is moved around the game world with regards to physics aspects."

You can read Preuss' third diary entry after the jump. His fourth and final entry will discuss networking and debugging physics, so keep an eye on the Black Prophecy site for the conclusion of the series.

Welcome to part three of my developer diary. In the previous part I have outlined some important functions of the physics engine and will now show how the interaction with the physics engine happens.

Have a good read!

Interaction with the physics engine

The previously outlined physics update loop allows interventions within the procedure, especially before, respectively after a single physics tick. Simulation objects, which are also updated within a physics update loop, can be assigned to single dynamic objects. External forces, respectively torques are calculated within the scope of the simulation object update after the analysis of external parameters such as:

• Maximal linear, respectively angular velocity
• Maximal force, respectively torque
• Player input

Space ship physics

It is easy to divine that there is a special implementation of a simulation object for space ships. Next to the specialized space ship physics implementation this includes a so-called controlling agent.

The controlling agent is being used by the AI for NPCs to generate input parameters for the simulation. On the other hand it serves to override player input if the player decides to execute a tactic. Tactics are preprogrammed movements, respectively trajectories that a player can trigger to confuse enemies, escape from them or simply to have fun.  During the execution of a tactic, the player has no influence on the form of the tactic. The controlling agent completely takes control. I will go into detail about the input methodology at a later point when covering the network physics.

In the end the simulation processes three input variables each for intended linear, respectively angular target velocities. In principle this means that forces are available for forward, backward, sideward, up and downward flight.

The player cannot control the upward and downward flight. Possible forces there are rather being used for trajectory corrections, e.g. during a looping.  Rotation torques are generally possible on all three axes.

Realism

Of course a game like Black Prophecy, with action-oriented dogfights, does not claim to implement realistic velocities like they would be possible in space or with future technologies. Dogfights between single space ships that move with a velocity of e.g. 50.000 km/h are simply unthinkable. In this case you would have to deal with relative velocities of 100.000 km/h. The probability to hit your enemy under such conditions is relatively low. Classic dog fights are impossible even at velocities of modern jet planes. Therefore the ship velocities are heavily reduced, rather catering to the intended game fun instead of realism.

Aerodynamic drag? Loosely speaking there is nothing in space (at least nothing remarkable) that would put a drag to an object with relatively low velocities. As a result a space ship constantly propelled with a specific force would accelerate indefinitely. As previously mentioned, this would make little sense for a game. Therefore the linear, as well as the angular related velocities are limited upwards. So there is an artificial drag.

Furthermore it is being assumed that available technology is used to make the pilot's work easier. This means that the propulsion technology is monitored by computer programs that allow the pilot to concentrate on his flight destination. This is quite much comparable to active driving support technologies like they are utilized for automobiles.  A pilot who takes a turn at full thrust for example, does not have to worry that his ship will break out sideways. The controlling programs try to keep the ship on the intended trajectory as closely as possible by triggering a counter-reaction.

Space

Space, the final frontier ...

For a game it would be nice to technically picture the infinity of space. Unfortunately there are technical restrictions, especially for a MMO. Those prevent the presentation of the overall scenario within an unlimited game scene. Instead, so called sectors, which create a relatively large cubic space, are used. Technically, such sectors offer the possibility to implement mechanisms which efficiently examine the sector for its content. This makes it possible to quickly and easily create subsectors to identify their content based on defined criteria. Examples would be visibility quantities, trigger systems, the generation of radial damages or AI neighborhood queries. Generally this process is called close range look up.

Stations

Stations are represented by static collision geometries. As a special feature, shield geometries and weak points can be supported.

Capital ships

The physical representation of capital ships is similar to stations with the exception that they can be animated on pre-defined trajectories to always have them in the best cinematic and gameplay-relevant position.

Weapon physics

Two basic models are utilized for the weapon system implementation. These are projectiles on the one hand and raycasts on the other hand.

Projectiles are separated in unguided and guided projectiles. All projectiles have in common that they are generated with a specific start velocity at the weapon's muzzle. Target-seeking projectiles have the characteristic feature that they use a controlling agent that guides the projectiles towards the target's direction. All weapon systems can have variable impact in terms of damage generation. Those are parameters that are defined by the game designers. Examples would be weapons that only have impact on shields or generate area of effect damage.

To comply with the differentiation of the weapon systems, so called collision groups are used that can be assigned to the collision geometries. Based on this identifiability it is possible to react accordingly with damage generation or shield penetration during the collision detection. To receive corresponding results for guided projectiles within a client-server simulation to some extent, minimal network synchronization is triggered. All other projectiles, respectively raycasts have consistent starting conditions disregarding network latency. This makes it possible to generate them on the client and the server in the same way. Incidentally I'd like to mention that the damage generation is completely handled on the server.

That's it for part three of my developer diary. In the fourth and last part of my diary series I will talk about the networking physics and debugging physics.

Stay tuned!