New Engines and Ship Dynamics

To find the best design for each purpose is what makes every challenge unique in the game. It is a need to understand the context, understand the mechanics, and allow for efficiency at every opportunity. When it comes to ship design in Dual Universe, this couldn’t be a more true statement!  We don’t want a one-size-fits-all ship design that encompasses all atmosphere conditions, high or low altitudes, space, etc. That would be incredibly boring on the short term!  We want ships that require specializations in order to bring a different perspective and fresh experience depending of the environment you travel in.

With the feedback we received from the current Pre-Alpha, we believe it was time to work on the next generation of engines.
We aimed to improve the current designs, but also add cool new concepts that we’ve had in mind since the very beginning.
Check it Out!

There are three different needs in terms of vertical thrust in the atmosphere:

A. Slightly lifting the ship to  to emulate gears. This will prevent players from scratching the ground when thrusting forward. There are actually two subcases:

  1. Lifting for long periods; the emulation of wheeled vehicles which leads to the design of hovercrafts.
  2. Lifting for short periods; enough to enable take off, but then the ship would quickly engage other means to sustain itself in the air. (See point B below.)

B. Compensating for gravity while in flight.
C. Escaping the planet’s gravity well and jumping into space.

Right now, Vertical Boosters cover all of the cases. These are too powerful and does not allow for ship specialization.
What we needed to do was separate those use cases into different types of engines and here is the solution we come up with:

Vertical Booster Mechanics Revamp (Coming in r0.10)

Currently, use case A1 is partly covered by Hovercraft Engines. They are designed to consume low amounts of fuel and sustain a medium-sized ship above the ground for long periods. As they cannot lift upward for more than a few meters, they are limited in thrust power.

We have redesigned the current Vertical Boosters to replace hover engines on very large ships for short periods of time. They are more appropriate for ships that need transitory lifting capability versus the permanent lifting given by hover engines.
They are meant as a helper for taking off, which is use case A2. They will work only on a very limited altitude and cannot be used in B or C.

They should also work without atmosphere, making it possible to use them on a moon or any planet without one. Additionally, they will now require space fuel and they will need to be rewired. Unlike hover engines, they will consume immense amounts of fuel, but give more punch, due to them being part of a transitory phase. Please note that this means players will likely need to reconsider the design of their current ship should they be actively playing the Pre-Alpha.

New Interactive Element: Wings! (Coming in r0.10)

For use case B, we introduce wings! Simply put, these work as regular wings, transforming speed into lift. To be more precise, wings generate an upward thrust in proportion to their size and the projected squared speed of the ship onto their forward direction. They will also generate a drag force in proportion to their size and the squared front speed, so there is a tradeoff with which size of wings you should consider in proportion to the overall size of your ship. The good news is that they don’t require fuel; only a dense enough atmosphere (beware that atmosphere density decreases with altitude, as does the lift power of wings, the thrust power of atmospheric engines, etc). Wings will be a relatively cheap option to fly around planets like Alioth at the beginning of the game with the possibility to build gliders with very low fuel consumption.

New Interactive Element: Stabilizers (Coming in r0.10)

We also have introduced a convenient “passive” wing that can be mounted in any way you want. They create a force perpendicular to their surface and proportional to the square of the speed projected along this perpendicular axis. This is not technically an engine as its effect cannot be modulated and the force it generates is constant. The benefit of these stabilizers is that they will realign your ship in the direction of the movement and attenuate any drift that you might have, especially with hovercrafts or fast airplanes.

New Interactive Element: Rocket Boosters! (Beyond r0.10)

To cover use case C, we’re introducing a brand new type of engine and fuel: Rocket Booster Engines and Rocket Fuel! These engines can be manually turned on or off as needed. When activated, they will produce an incredibly powerful thrust that is capable of lifting a Dynamic Construct either into space or the local atmosphere. You’ve seen them in action already in our “Dual X” video! Keep in mind that these engines consume insane amounts of fuel, so they can’t remain active for very long. They are really meant to get you out in space, nothing more. It may be possible to use them as a booster to escape a dangerous encounter, but keep in mind that their autonomy in fuel will limit the amount of times you can use them before going back to a refueling station.

New Dynamics for Atmospheric Engines (Coming in r0.10)

Don’t forget about the Atmospheric Engines that will be tuned to fit the new engine spectrum. They are meant to initiate forward thrust to an airplane-like type of ship. They could potentially be used to lift you up, such as in scenario A2, or even to implement helicopter-like dynamics, but it would be extremely costly in terms of fuel to accomplish this.

The new property of Atmospheric Engines is that their fuel consumption is high at low speed when the engine first sets the ship into motion, but is reduced at high speed for a more realistic behavior.  In addition,their max thrust is slightly higher. They are intended to be used in flight mode at high speed. If you use them for the purpose of lift, they will be considerably less efficient than Hovercraft Engines or Vertical Boosters.

New Interactive Elements: Antigrav Generators (Beyond r0.10)

There is one final use case that has yet been covered and one that we would like to discuss. Suppose that you would like to build a sizable space ship that would have to hover in the atmosphere; floating around for logistic or strategic support. It’s too large to reach high speed or be sustained by wings . It’s too heavy to be lifted by Atmospheric Engines and it would be too costly to use Rocket Boosters. What can we do? Welcome the new Antigrav Generators!

The principle is that these Antigrav Generators will create a distortion in the gravity field to allow a very large ship to stabilize around a zero-g altitude. This altitude can be set by the player, but cannot go below 1000m. So, you can still land with a large ship, but you need some rocket boosters to lift it up at least over 1000m to be able to then activate the Antigrav Generator.

Because of the way the anti-gravity field works, the construct is attracted and ultimately stabilized to the stabilization altitude. Note that if your speed downward is too high, you might break past the stabilization point and keep falling, so the Antigrav Generator has to be operated gently.

Antigrav Generators come in three flavors: small, medium, and large. Each flavor is usable only with a dedicated construct size. Small generators work with 64m core units, medium with 128m cores, and large on the future 256m core. You cannot deploy an anti-g on a 32m or below ship; this is strictly for large structures.

The Antigrav Generator by itself does nothing. It produces anti-graviton particles that need to be channeled into what we call “Pulsors” in order to be effective. You will need to link the Antigrav Generator with Antigrav Pulsors to increase its power. Small Antigrav Generators need at least 4 Pulsors to function and can connect upward of 6 Pulsors. Medium Antigrav Generators can use 12 Pulsors, and large ones, 24 Pulsors. Losing pulsors will lower the intensity of the anti-gravity field distortion. Should the number of active pulsors drop below the max number divided by two (so, 3 for small, 6 for medium and 12 for large), then your ship is going to slowly descend. Once the combat gameplay is implemented, we suspect that anti-g pulsors will become serious targets of choice!

Note that Antigravity Generators are not engines and can be used to keep any payload airborne.

The Antigrav Generator is automatically plugged into your control unit by the autoconf system. You will see it as a new widget and can activate/deactivate it using Ctrl-G or link it to a switch to activate it manually in-game. The widget will show you the anti-g power you currently have (up to 120% if you have all the pulsors linked), the local gravity, and the stabilization altitude. When you press Ctrl-G, the stab altitude is automatically reset to the current altitude. You will notice however that it does not change instantly, but with a maximum rate of 4m/s. So if you need a faster climb, just activate your boosters!

For the time being in Pre-Alpha, Antigrav Generators will not consume anything, so they are free to use. In the final game they will consume electricity. It should be reasonably affordable so that you can stay in anti-gravity fields for a few hours at a time, but not so inexpensive that having a permanently flying fortress is something you’ll see on a daily basis.

Currently in Pre-Alpha, when you quit the game while piloting a ship, it freezes that ship in the air. When you log back in, the ship is immobile because it has not been loaded properly). This will change in the final game and there won’t be an easy way to maintain a construct in the air. Antigrav Generators will be absolutely necessary.


Additional Improvements: Bumpers and New Damage Model

Up until now, damage was proportional to the kinetic energy of a construct just before impact. It is spread directly around the point of impact, being absorbed by elements one by one. When an amount of damage energy reached an element, this element absorbed it entirely. We are now introducing a buffer that will absorb part of this energy and inflict damage only on parts beyond the buffer.

One application of this new model is the possibility to create bumpers: simple elements that have a small amount of hit points, but a significant damage buffer. Bumpers will be useful to create landing points of contact in a heavy constructs. Landing gears will also act like bumpers, being able to absorb reasonable amounts of shock.


Clarification About Auto-Tagging: What is it used for?

Let me make a small digression regarding an important mechanism which was recently introduced, but not properly explained until now: engine tagging. This part is totally optional and geared more toward programming-oriented players who like to create variations of standard behaviors.

If you were one of the brave ones who took a gander at the Lua script that is auto generated for your ship, you noticed that there is a setEngineCommand function used in the flush event. This command is a powerful way to indirectly assign thrust power values to a set of engines via parameters so that the resulting effect will be equal to a given total thrust and torque. This function also takes a series of tags as parameters to define the set of engines it will operate on. This is the reason why your engines are tagged with things like “vertical”, “horizontal”, “brake”, etc.

Each tag corresponds to a group of engines that are treated as a whole by the script. “vertical” corresponds to engines that will be involved in generating vertical thrust, “horizontal” is used to handle the forward thrust command, “brake” is for braking, “torque” is for rotating, etc. You can change the auto-tagging of the engines to re-assign them to other functions, otherwise this is default based on their type and/or orientation on the ship.

It’s important to note that some engines are capable of generating force, while others are capable of generating torque, but not necessarily both at the same time. This is done to make your life simpler, as it’s much more difficult to control a ship that has thrusters generating force and torque at the same time (in most of our early testing, this was considered as too problematic by most people). We might introduce a way for players to reactivate the force+torque capability of all engines for added complexity, if you so choose. Let us know what you think about this! The bottom line is that if you have engines that are capable of generating only force (like atmo or space engines) and you tag them with a “torque” tag, this will do nothing.


Realistic Accelerations and Speed Control

In a future update we are considering several important changes that we think will help balance the ship building game and bring about interesting challenges:

Currently, there is no limit to the acceleration you can withstand in a ship. Make a super light ship, add a huge rocket, and you can be catapulted at an insane speed with no consequences. Our goal will be to limit how much g you can sustain in proportion to the amount of voxels you have in your ship. Below a certain amount, your ship might simply dislocate itself. If you want to sustain high accelerations, you need structure, which in turn will add mass and limit the acceleration. If you manage somehow to accelerate at 100g, the likely result will be, well… that you explode and die! Don’t worry though!  You’ll have plenty of warnings so you have time to react.

The atmosphere re-entry is currently handled by only a nice visual effect. We are considering to induce damage to your ship if the amount of dissipated energy reaches a certain level, such as vaporizing your ship should you hit the atmosphere at 20.000 km/h with no special gear to handle the shock.

We currently have artificial speed limits set in the atmosphere (up to 500 km/h at the surface) or near the surface of moons. This is due to the absence of the above mechanisms. We plan to remove this in the future, so hitting a planet or a moon at full speed from space will almost always end badly!



The table below aims at summarizing the discussion above.
As usual, your feedback is most welcome and we are excited to hear what you think about these coming changes!

Best Regards,
The Novaquark Team