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:

Lifting for long periods; the emulation of wheeled vehicles which leads to the design of hovercrafts.

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!

Conclusion

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!

This is why we’ve created The Dual Universe Community Spotlight. With it, we hope to interview some of our most interesting and influential community members to showcase those contributions to the Dual Universe Community. We hope that you look forward to hearing their stories as much as we do!

This time, we have a chat with Kurock.

Novaquark: To start things off, could you briefly introduce yourself?Kurock: Hi guys. This is Kurock from South Africa. I'm 36 and a father of two. A long long time ago, Baldur’s Gate kicked off my love for RPGs. Besides a player of pen and paper RPGs (where I GM'd for Pathfinder Society), and an avid board game collector (The Battlestar Galactica board game is well worth a look), I played a fair number of PC games. Most notably, I played and later GM'd for a local Ultima Online shard. From there I went from game to game, never really finding a place to stay for too long. Until now...

Novaquark: How and when did you discover Dual Universe? What was it that brought you into the community?Kurock: Dual Universe first appeared on my radar in early 2016 when I happened to come across the E3 2016 trailer on YouTube around about the time when I was a little fed up with Space Engineers lack of stable multiplayer. My final pinch of skepticism was dispelled when JC explained the server architecture in a later video.

During the Kickstarter I was a bit worried about the connection quality from South Africa but backed anyway. (Happily my worries proved to be ill founded.) It was during the Kickstarter that I joined the community on the forums and discord. And the rest, as they say, is history.

Novaquark: What is it you find so enticing about Dual Universe?Kurock: Am I allowed to say "everything"? No? Ok, let's get stuck in then.

The server architecture (no loading screens between planets) and the sheer amount of planned mechanics in Dual Universe (building, scanning, RDMS, etc.) are certainly appealing. The idea that all aspects of the game are easy to get into but also has depth for those that want to delve deeper is a design decision I enjoy.

But most of all, in Dual Universe the designs not only come to life, but they persist. They matter because they affect other players. There are many single player and multiplayer games where I could create as you wish but the world itself doesn't really change. Also, by "designs" I don't mean only building a construct but also social interactions, ranging from hovercraft races to memes like "Just DU it".

Novaquark: Everyone has goals they want to achieve when it comes to in-game content. What are you planning to accomplish in the future?Kurock: The short answer is add content to DU for other players to enjoy, and have tons of fun while doing so. I wish for Dual Universe to be inclusive rather than exclusive: A sandbox where all players have a chance to play as they wish to play, be that solo, in a small group or part of a nation.

The longer answer is how I intend to go about that. Firstly there is the organization known as DICE. DICE is an in-game gaming events organizer and games distributor. The games encompass everything from hovercraft races to arena sports, from maze and puzzle games to arcade style games. You can find more about DICE in Novean Dreamers Almanac issue 2.

Novaquark: You’re a busy man, indeed! Among all that, you have also found time to write short stories about the game. You entered the first two NovaWrimo contests and even won the Community Vote twice for “Experiment Alpha” and “Bastille”. What inspired you to write these?Kurock: Experiment Alpha takes inspiration from JC. His flying around in godmode in early DU videos, to be exact. In Dual Universe lore, the alpha testing phase is a simulation and I thought that would be a great setting for a story since it seems real but there is still plenty of room for glitches in the matrix. Like space whales. Throwing in a few topics that shall not be named, a dash of my special brand of humor and wrapped in a Scheherazade story structure, I had a short story that was aimed squarely to gain the community's approval.

For Bastille, I went with a nameless protagonist on a heroes journey with prison themes. Again peppered with my humor (which some say is a little strange), many covert references to other SciFi works, and a twist at the end. The prototype inventions of DU play a large role in Bastille, with a touch more world building that's the first story with the introduction of the Centauri.

Novaquark: Do you have any specific hopes from Dual Universe in terms of its lore and storyline?Kurock: The core story of DU, the neutron star causing humanity to evacuate earth in Arkships, is a solid one. I enjoy the lore explanations for the technology, though some do find the resurrection node lore to be a bit of a stretch. I think less multiple universes and more quantum sampling and entanglement would go down a bit better.

The four political factions of the UEF, the Alphas, Luminous, Ethereals, and Emporium seem a bit one dimensional. They seem more like generic game factions than parts of an organization that want to save humanity. Their domains are fine but they are missing character.

Finally, I hope the storyline for after landing on Alioth is formed by the players. Oh and space whales.

Novaquark: Well, we can assume players with some imagination could design spaceships with that kind of shape, right?
Kurock: Whale shaped ships? Challenge accepted

Novaquark: You mentioned that you were one of the moderators on the community Discord. How did you end up with that position and what does it imply on a daily basis?
Kurock: I joined the community discord in September 2016. In May 2017 I was asked by Comrademoco on behalf of the discord admins to become a moderator. I accepted.

Daily duties involve answering discord and Dual Universe related questions, helping people to their correct discord roles and very occasionally hosing down offenders when tempers flare.

The community, in general, is friendly and will quickly help newcomers with their questions. If we were handing out the title of "most friendly and helpful soul" it would go to msoul.

Novaquark: We’ve been really curious about the answer to this last question. Since the “Let’s DU it” thing that you mentioned earlier came from you, could you tell us how it started? Was it just a pun? We know where it ended, but where did the idea initially come from?
Kurock: It started as a pun on discord. Code24 made the "Just DU it" image which was set up on the discord to appear whenever anyone said "Just DU it". Yamamushi created the Back Dual Universe Today! which further solidified the meme. There are many more DU memes but they have not made it onto JCs wall (yet).

__

Thanks to Kurock for taking the time to answer our questions! We hope that you enjoyed our conversation as much as we did. In the future, we’ll be reaching out to more community members on a host of topics, introducing you to them, and sharing their achievements to our incredible community. If there is someone you feel should be in the spotlight, please let us know!

As you might have already realized, our old DevBlog is currently unavailable: we are currently migrating all the DevBlog articles prior to 2018 on our website. As there was a lot of articles, this will be done progressively. We will redirect all the old links towards the new ones once this will be done!

Our aim is to gather all the official news on our website and to make it easier to read with a new theme. In the future, you will also be able to use a filter feature to find specific categories for the DevBlog posts you are the most interested in!