[IDEA] Dynamic top speed

I am of two minds on this one... On one hand it would be nice if small fighters could actually out-pace a larger and slower ship... on the other, the line for fast/slow in mods that do this tends to feel extremely arbitrary, often dropping all but the most agile ships to well below the un-moded cap if not strait in to the mod's minimum cap...

Assuming we were to go with the idea, mods that make use of a "burn-speed" are often quite obnoxious, I'd much rather you hit top-speed and be aloud to coast at that speed. If you want to run in a strait line from an attacker without without wasting speed to engage in evasive maneuvers while they shoot at you, then I see no reason that can't be its own dramatic moment :)

As for top speed based on thrust... I'd think it best if it was based on the thrust in the direction of acceleration, with any loss to that amount of thrust not applying a breaking-force, but preventing you from reaching that speed again once you decelerate until you regain the thrust.

@Star_Kindler

I like both approaches—maybe they can be combined into one system.

Below a certain speed, say 150 m/s, you accelerate normally based on your available thrust.

Above that, acceleration gradually decreases, so you need to burn significantly more fuel as it gradually takes more time to reach higher speeds.

A “normal” top speed could be around 280 m/s. Ships with a poor thrust-to-mass ratio would struggle to reach it, but once they do, they can stop accelerating and just coast without burning fuel. If you keep holding the throttle, you might push up to 300 m/s, but as soon as you release it, the ship would quickly drop back to around 280. So technically any ship can reach those higher speeds, but fuel cost becomes the limiting factor. Ships designed with a better thrust-to-mass ratio would naturally perform much better at high speeds.

Scenarios:

1. Simple early-game hydrogen ship for space travel
   Not very massive. With a couple of medium thrusters on the back, you can reach 280 relatively quickly. This makes it easy to travel between stations, asteroid rings, and other points of interest. Fuel consumption will vary depending on how loaded you are, but it remains manageable.
2. Hydro scout for space
   Here efficiency really matters. Fuel consumption is no longer linear, so heavier ships pay a much higher price when going above 150 m/s. If you’re making frequent stops, fuel becomes the main concern. A lightweight scout with a good thrust-to-mass ratio becomes extremely valuable.
3. Big cargo ship for space
   You want as many rear thrusters as possible to offset fuel consumption. Acceleration to 280 m/s will be very slow when fully loaded. This is where space transport economy comes into play—movement itself is simple, but fuel usage becomes the key factor. Planning your stops is important. Advanced flight computers could help calculate optimal burn and flip maneuvers, since doing it manually often leads to wasted fuel. You can also choose to cruise at lower speeds. Reaching 200 m/s is much cheaper than pushing to 250—the extra 50 m/s can cost more than double the fuel.
4. Small fighter for space
   Similar to a scout: low concern for fuel, high speeds, excellent acceleration. Can intercept targets easily and evade threats by rapidly changing direction and speed.
5. Heavy fighter / bomber
   Less agile due to a lower thrust-to-mass ratio, so it can be intercepted by lighter fighters. Still capable of reaching 280 m/s, and occasionally 300 if needed.
6. Larger warships
   Designs can vary a lot depending on their role. Interceptor-type warships (including pirate ships) benefit from higher thrust-to-mass ratios, but this comes at the cost of armor, weapon systems, or lots of fuel tanks—making them more vulnerable. In fleet battles, these differences can create interesting tactical dynamics. In duels, however, diversity is harder to maintain since speed can be more important than anything.

Acceleration rules should apply in all directions. A ship might have strong forward thrust but weaker lateral or reverse thrust, which affects maneuverability. This also ties into combat design—likely favoring closer engagement ranges

Hydrogen thrusters could also have a delay before reaching full thrust, making dodging less trivial. Combat mechanics are a whole topic on their own, but in terms of speed: larger ships are naturally disadvantaged. To compensate, they could have advantages like better heat dissipation (if a thermal system exists), allowing them to mount more weapons or use heavier guns more effectively.

They won’t be able to catch a fleeing ship easily—but they also won’t be able to escape quickly themselves. And those last 20 m/s of top speed would be extremely difficult for massive ships to achieve.

For atmospheric flight, the rules above can be even harder, with the base speed reduced or even more steep acceleration degradation. On the other hand, the ship shape can determine those parameters and even help for lifting if you have certain shape. Reaching the top 300 would be generally harder I guess.

this thread has me wanting to build a multi stage top speed rocket. if i could hit 1000m/s i reckon i could start trying to work towards low planetary orbit.

and what happens if you rotate your ship?

you could achieve the same result with a much smaller change and smaller fallout:

just make it so ships can accelerate beyond the limit, lets say up to 400 m/s, at an exponentially increasing fuel cost. while flying faster than 300 m/s, drag is applied to the ship until it is back to 300 m/s.

that will allow accelerating ships to catch up to drifting ships, at greatly increased fuel cost, and without messing with every ships top speed.

That's what I recommended many months ago, Zed. If it comes down to balancing, where we want maximum creativity and PvP balance, the cost easily falls onto fuel. Something like a small fighter craft would have to routinely dock to a mothership, or be built for longer-range combat, reducing its overall speed. An unmanned missile launched is super lightweight, and super fast, but only gets so much fuel; It better be fired in a good targetting envelope, or else it won't have fuel to stay on target. Huge carrier ships or freighters go slow, but likewise don't use much fuel, not unless they are trying to set some kind of speed record and blow through half their reserve getting up to max speed.

I find for the areas of balancing, realism is the best route. It is simply the most efficient way to balance a problem such as this.

Thank you, this is great to see. I really don't want this type of thing added to SE

Too many arbitrary suggestions from the people here. Oh my Lord. The only 'causal' idea that is coherent is: WWII airplane speed relationships in space....and modern military jet afterburners with different fuel burn in space...

You should just say that. With a speed limit in place, we get:

1. WWII Pacific Theater - different plane types have different speeds and accelerations. Different boats have different top speeds and maneuverability based on their mass.

2.. Cold War Jet Combat - turbojet engines with afterburners give different speeds and fuel burns. Missles are short range, and can exceed that.

There. I have not seen an attempt at a logical causal relation or reasoning to the 'top speed' question, one that is deductive in nature that everyone can correctly infer flight characteristics from.

Too much arbitrary ideas (based on how you feel it should 'work')...by the inherent nature of arbitrary reasoning, everyone will have a different feeling on how you should change physics. Why not? One suggestion alone has six(!) ideas that change all the laws of physics!

What do we do?

Try to find an objective based reasoning, and infer from there.

I can think of 3 right now. Two of those could work. One already is in place. If you can answer that, why there are speed limits in space, then all the other ideas can follow based off that.

I will challenge -anyone- here to at least attempt some non-arbitrary ideas.

Woops, almost forget, to give a non-arbitrary reason:

"Shields - an energy shield, and a kinetic shield (inertia dampening field for bullets, essentially). Can use the usage of the field as a limitation for speed in another SOI's gravity-well, i.e. the speed limitation. Sun SOI, planet SOI, moon SOI."

The other causal reason is the actual game engine limitations (...obvious, I know!)

With a system that relies on the workings of your inertia dampeners (yes...magic, but in the gravity generators) to be affected by a gravity well's SOI (sphere of influence), you get:

1. faster top speed away from the center of the SOI

2. Slower speed towards the center of the SOI

And as a corollary:

1. Less things to render the farther you are away from an SOI

2. More things to render the closer you are to an SOI

The other reasons weren't really adequate, although causal. (ATC/G-Forces/etc)

This reasoning would give a baseline for other ideas to causally anchor to. Escape from combat? Go away from the planet, increases top speed, but all alone, no support. Go towards the planet? Speed slows down, but maybe can use terrain to advantage.

Just an idea ;)

It’s probably worth noting the likely reason why the speed limit was introduced and continues to exist.

The “game universe” is not “continuous” in either time or space. The smallest unit of time is one cycle of evaluating the spatial relationships between objects in the game environment and one cycle of rendering the scene.

The reason is simple—objects in a computer game do not move continuously, but jump through space; within a single calculation cycle, they are “static,” and between two calculation cycles, they move “infinitely fast” to a new position.

Imagine the following situation: we have a flat plate 0.25 meters thick. We have a cube, a 0.25-meter block, representing a projectile and moving at a speed of 300 m/s perpendicular to the surface of the plate. The question is: what is the smallest time step required to reliably evaluate the collision of these two objects?

I admit I don’t know the correct answer, but I believe it must be at least 1,200 times per second, or even up to 2,400 times per second. At a lower update rate for the projectile’s position and the plate’s position, there is a risk that in one calculation cycle the projectile’s position will be “in front of” the plate and the collision evaluation result will be “no collision occurred” and in the next calculation cycle, the projectile’s position will be “behind” the plate, and the collision evaluation result will again be “no collision occurred.” A literal "tunnel effect," known from quantum physics, occurs...

Hundreds of similar calculations can take place simultaneously during intense combat. Yet this is only a small fraction of all the calculations the game engine must perform simultaneously.

Another similar set of calculations involves the application of forces (primarily one-time impulses) to grids consisting of individual blocks with their own collision models.

Concept: The engine generates a force with which the engine block acts on another block as a compressive force. The joints in the row of blocks (and the blocks themselves) are subjected to compressive stress. However, the joints with the blocks on the sides of the block are subjected to transverse stress, shear stress, and, due to inertia, bending stress as well.

In the game itself, you can perform experiments that demonstrate this nicely. For example, a engine placed in the middle of a long row of blocks arranged transversely.

Translated with DeepL.com (free version)

I have heard a streamer mention that the reason for the speed limit, from a developmental standpoint, was not necessarily for rendering ability, but for -accurate- collision mechanics. I think you explained why. Too fast, too much warping, to many positional updates along with their associated physics.

Solutions?

First things first...I am no coder or dev. I have no experience, I merely listen to ideas that float around from people with more expertise than I, and try to stay big picture for that very reason. Keep things simple.

1. Physics on impact (either collision or weapon damage) - I was thinking of introducing the idea of a 'vaporization' speed limit for things, to see if the community would allow that. Essentially, above a certain speed, a collision just 'vaporizes' the blocks. Clouds of dust, unusable debris. We already have that, just make it more...agressive on lower speed limits, to improve rendering speed at higher 'in-game' speed limits? The idea being if two planes collided head-on, there would be no 'calculating physics'...it would be a big ball of fire and smoke. Or a large enough bullet hits at a fast enough speed, there is no 'physics calculations', just a ray-cast is generated and any low mass block touching it gets turned into dust haha Not sure how to implement that in-game in a way that doesn't break everything, though.

2. Move positional info to GPU - This was an idea I saw the team of Wayward Realms was discussing, to use a texture map with it's RBG color scheme for each pixel as the XYZ coordinates for gameworld objects positioning. Renderes fast, on GPU, in parallel, for millions of objects (how many pixels does a single texture map have...? a bunch) Frees up the CPU, and probably some other GPU stuff could be used to make it even better?

The thrust-to-mass ratio for a spacecraft directly determines the achievable acceleration of the spacecraft. That is,

TWR = a

For the maximum achievable speed, the acceleration due to engine thrust is equal to the negative acceleration due to the drag of space-time.

if "spacetime drag" is

a = ((v - 200) / 200)^3

then maximum achievable speed is

v = ( 200 * ( cuberoot a ) ) + 200

Speed should be understood as the "threshold" speed at which "spacetime drag" equals the acceleration provided by the engines thrust. The real achievable speed (at the finite time) will be significantly lower.

if a=0.1 m/s² (heavy cargo ship with weak propulsion) v= ~293 m/s

if a=1 m/s² (cargo ship with weak propulsion) v= 400 m/s

if a = 5 m/s² (cargo ship with adequate propulsion) v = ~543 m/s

if a = 10 m/s² (~1G) (normal civilian ship) v = ~630 m/s

if a = 30 m/s² (~3G) (civilian yacht) v = ~820 m/s

if a = 50 m/s² (~5G) (heavy warship) v = ~937 m/s

if a=100 m/s^2 (~10G) (frigate-class warship?) v= ~1128 m/s

if a=200 m/s^2 (~20G) (corvette-class warship?) v= ~1370 m/s

if a=500 m/s² (~50G) (interceptor?) v= ~1787 m/s

if a=1000 m/s² (~100G) (guided missile?) v= ~2200 m/s

When considering such issues, the capabilities of the game engine must also be taken into account. Will it be able to render an object moving at such speeds in a meaningful way?

a = ((v - 300) / 300)^3

v = ( 300 * ( cuberoot a ) ) + 300

if a=0.1 m/s² (heavy cargo ship with weak propulsion) v= ~439 m/s

if a=1 m/s² (cargo ship with weak propulsion) v= 600 m/s

if a = 5 m/s² (cargo ship with adequate propulsion) v = ~812 m/s

if a = 10 m/s² (~1G) (normal civilian ship) v = ~946 m/s

if a = 30 m/s² (~3G) (civilian yacht) v = ~1232 m/s

if a = 50 m/s² (~5G) (heavy warship) v = ~1405 m/s

if a=100 m/s^2 (~10G) (frigate-class warship?) v= ~1692 m/s

if a=200 m/s^2 (~20G) (corvette-class warship?) v= ~2054 m/s

if a=500 m/s² (~50G) (interceptor?) v= ~2681 m/s

if a=1000 m/s² (~100G) (guided missile?) v= ~3300 m/s

I think for technical reasons, devs would still put a hard cap on max speed for the grids (300m/s).

So the formula for max speed can ensure the following:

0.1G -> 150-200m/s

10G -> 300M/s

Faster than 10G and you start taking damage.

Building anything with more than 100G would be probably impractical.

A small guided missile would probably be able to achieve slightly higher speed. Say 100G and 350m/s. Enough to catch on any ship but not too fast so you can try to evade or use countermeasures.

It would also be useful to have gimballed thrusters or add smaller gyros and ensure AI can effectively control the missile with just 1 thruster. This way, custom guided missiles can be much simpler, smaller, low PCU and lightweight. You can afford to have more of them, potentially overwhelming enemy defences, and the bigger, more powerful torpedoes might follow.

Extremely high accelerations shouldn't be a problem—the guided missile has enough fuel for 3–5 seconds.

But in that time, it could travel as far as five - ten kilometers.

I would envision a rocket capable of extreme acceleration and high speed as a design with “five” or “six” engines and two fuel tanks—one very powerful engine would serve as a “booster,” possibly detachable along with its fuel tank, and four or five smaller engines would be used for maneuvering and course correction.

Another option would be time-controlled engine power—two to three seconds at maximum power, then reduced to 10% for the remainder of the flight to the target.

On the other hand, such a missile would certainly be interesting in PvP combat. It allows you to initiate combat at a distance many times greater than the typical range of weapons—and to attack the target quickly, in a short time, and from a great distance.

Translated with DeepL.com (free version)

I think that's a bit dumb to limit the speed by arbitrary values. I mean that any non-physical approach would be very confusing and not realistic. SE is a simulation game after all, so the more accurate simulation is, the more fun can be from building stuff. Of course the are computational limits which can be forgiven, but making stuff up is bad decision in this type of game I think.

However if we separate this idea into space and planetary enviroment it can make sense in planetary enviroment. I mean if there are no aerodynamics physics implemented, limiting speed by mass can be greatly simplified terminal velocity..., but that's propably still a bad idea...

I think there shouldn't be any speed limit in space, OR atleast make it togglable. I always used 10 000m/s speed limit in SE1, because default 100m/s was very restricting and boring. Of course I took into account that after crashing something big at high speed I risked game crash, but that's my computers issue not mine guh. I also understand that devs cannot blow up my computer with their code, but maaaybe give a huge disclaimer that disabling speed limit can cause **instability**?

I am not proposing to limit the speed of ships based on their mass. (Not directly and not openly...)

I propose limiting speed based on the thrust-to-mass ratio and by introducing “spacetime drag” similar to aerodynamic drag (i.e., increasing with flight speed).

“Equal rules for all.”

And I am fully aware that a law of motion formulated in this way favors light ships, because they more easily achieve a high thrust-to-weight ratio. However, I am convinced that this is an advantage based on real physical principles, not on favoring either side of the "dispute."

---

As for the speed limit in the game—it irritates me just as much as it does you. But maybe I understand the reasons behind this decision.

On your home computer, you can fly at any speed without having to worry about the wrath of the almighty Klang. Or rather—you’re fully aware that such flying could lead to the greatest punishment from the magnificent Klang: the destruction of your creation.

But what you can do at home in private is not allowed in public, on public game servers. Above all, it is not allowed to cause game servers to crash by exceeding the game engine’s limits.

Keep in mind that game servers often run in parallel, with several servers on a single physical machine. So computing power is distributed across several servers, and moreover, unlike a home computer, a server must serve multiple players in different areas of the game world (a home machine always serves only one or a some few areas—the one the player is currently in, or possibly another where they have some activities).

So when a game crashes on your home computer, you can curse—even loudly—but you know it’s your own fault. But when crashes a game server, many players curse, mostly without understanding the cause—and they blame the unstable game and the lazy developers. So the speed limit is a form of "holy images" against the wrath of the noble Klang and the many players.

XIX Commandment:

Thou shalt not fly faster than allow the physical model, the computational power of thy computer, and the speed and ping of thy internet connection.

So, experienced, Klang-fearing players do not violate Klang’s commandments too blatantly or publicly. But Klang is also merciful and often looks the other way, so he occasionally condescends to overlook minor violations of the commandments by his faithful followers.

---

I believe and hope that in the future—hopefully soon—Keen will allow users to configure various game and game engine settings using a well-documented XML file. The more comprehensive and in-depth the settings, the better. I believe this would benefit both players and Keen.

---

As for flight in the atmosphere, the proposed model and formula could be used quite effectively with a minor adjustment.

Let the "aerodynamic drag" in the troposphere be

a = ((v - 80) / 80)^3

then the maximum achievable speed in the troposphere is

v = ( 80 * ( cuberoot a ) ) + 80

let the "aerodynamic drag" in the stratosphere be

a = ((v - 120) / 120)^3

then the maximum achievable speed in the stratosphere is

v = ( 120 * ( cuberoot a ) ) + 120

Maximum achievable speed should be understood as the "threshold" speed at which "aerodynamic drag" equals the acceleration provided by the engines thrust. The real achievable speed (at the finite time) will be significantly lower.