Games Prototyping – The Story So Far (Part 1)

I’ve spent the last five or so weeks prototyping game ideas for the final project portion of my Adv. Diploma’s final year. The first few weeks were more of an ‘R&D’ period as myself and my artist (Eric Fear) adjusted to using Unreal Engine 4. As a result, we possess two prototypes.

The first – and more advanced – project was that of a multiplayer space shooter, similar in control scheme to Space Engineers and inspired by the X3 series by Egosoft. This has been a wonderful test bed for networking, Blueprints (UE4’s visual scripting language), exposing C++ functions and properties to Blueprints, the various in-editor tools, and so on. As this is the prototype with which we’re going forwards into our major production, it will be the focus of this post as well as of those to come.

The first programming hurdle was the flight model and control mechanics. Some games allow the player to maneuver through space like a jet fighter, with no explanation as to how, or the ability to switch to a less ‘hampered’ style of flight. We decided we would like a toggle-able inertial dampening system (IDS), which would, as the name suggests, cancel or dampen the craft’s inertia.

Whilst this doesn’t sound significant, imagine this – your craft is thrusting forwards, then pitches up while continuing to accelerate forwards in the new direction. Because your inertia from the original direction still exists, you will perform a very large ‘fish-tailing’ curve, where the craft drifts out and around in a wide arc until the new direction’s thrust and various adjustments cancel out the original direction. This is made worse by the fact that every ‘moment’ of the pitching maneuver is a new direction of thrust, all of which must be cancelled out a later stage if the craft is to fly ‘straight up’ (in terms of the world, not its own relative ‘up’).

Using the IDS, however, will make the guidance system counter-thrust against any inertia in a direction into which the pilot is not directing the craft to thrust. I.e. in the above scenario, relative to the craft, you will still have a ‘downwards’ inertia (the original ‘forwards’) at each moment of pitching. Because you’re not pressing the relevant key to thrust downwards, the IDS will cancel out that thrust by pushing you in your relative ‘upwards’, and thus into the curve, allowing for more complex maneuvers typical of modern day aircraft, such as banking turns and loops.
 

 

Due to the ease by which blueprints communicate with and inherit from C++ classes (a subject I will examine in a later post), rapid iteration on pre-existing ships is made simple – change the mesh and the flight variables (i.e. maximum thrust values, mass), and the ship will look and feel different. The base class, Ship, contains functionality needed by all spacecraft, such as thrusting, and the IDS, and uses the variables exposed to Blueprints as a way to control how these operate, such as the maximum thrust values being used to clamp the amount of force actually being applied to the craft. This technique is not just useful for the creation of new objects, but also as a way to quickly tweak pre-existing ones. The following video represents the most recent take on flight mechanics for the APEX Interceptor.

 

 

In the posts to come I will discuss other technical issues that I faced, such as the general C++ to Blueprint pipeline, shooting, and the woes of networking.