Hard limit on speed

[Verbatos]

I saw a post that was made a month or so ago, that was decrying hard limits in video games, and that got me thinking a bit.
I have come up with an idea to restrict the speed that spacecraft can go in the game without making a hard 150m/s limit. In my head, this idea will allow for more creativity in shipbuilding and allow ingenious engineers to come up with ways to push the speed limit... to it's limit.
My idea is actually pretty simple, remove the hard 150m/s limit, and implement a more gradual system. Basically, the faster you go, the exponentially more stress will be put onto your craft.
See what I mean with this scientific graph I have produced:



As you can see with this high-quality graph, you could still set a hard-ish limit at say like, 200m/s or something, where it would be theoretically impossible to ever reach such a speed, but it would still allow sturdily built ships to start approaching higher and higher speeds.

Again, this is only a concept, but if you have any ideas around mine I would like to see them!

 

[XenoCow]

I agree that this could be a solution to many people's concern. I think the speed limit is mostly a perceptual problem, and by making more effort = more speed with diminishing returns, people will feel in control still since they know they could forfeit something on their ship to go faster, even if it's only by a little bit.

The practical limit (speed limit for a ship that can do useful things like turn, have a pilot, and have some devices or cargo), could still be something around what we have now, but people wouldn't feel cheated if they couldn't reach that since they know they could push for faster speeds forever.

 

[five]

I really like this because you don't have this blunt in-your-face "You can't go faster then x". Through this the games physics would regulate how fast you are travelling, since you have weight on your ship in relation to the thrust you produce (Which is the only limit in other games like SE), though in Starbase you also have the level of stability corelating to your weight, as more stability (more beams) equals more weight. Though I think that the current limit of 150 m/s is much to low. Like 150ms isnt even half of the speed of sound, I would greatly appreciate, if thrusters produced more power and you could travel faster, this way it wouldn't take ages to fly from the stations to the asteroid ring and fast flying would be an actual challenge with a small vehicle.

 

[Nivrak]

They didn't put the 150 m/s on random, the physics engine currently starts doing some funky stuff after this number, it might change in the future but you can't just replace the whole engine with a speed:stress system

 

[BTDubsy]

maybe having power consumption tied to speed would do the trick, imagine replacing the stress axis on the graph with power consumption.

 

[sketch424]

I like the OP's idea, imagine chasing a junker looking ship down, reaching your max and seeing it disappear beyond your gun range.
or flip it on it's head, you're chasing down a ship and he just can't get away, you're closing in more and more, which will result in additional maneuvering from the target.
Instead of just reaching 150m/s and going, alright, not gonna catch him, off I go to do something else.

 

[ChaosRifle]

interesting idea, though generally, speed limits are VERY important in games because of physics engine limitations. Physics engines operate in ticks, so things can clip (phase) through eachouther. if we have a theoretical physics engine running at 60hz (60 ticks per second) and we have a ship fly towards it at 100m/s, to the physics engine, its only calculating every 1.66m. This means that its possilbe to clip 1.6m through an object before the physics engine catches it. in reality, that example of a static grid and 100m/s will often end up somewhere around 1m, because 1.6 would mean the previous phsics step was just before impact, but I hope that makes it clear why its needed. at 150m/s that raises to 2.5m (@60hz) possilbe, which really starts getting into the territory of lobbing a steel plate at something and exploding that somethings internal systems, because most of the time it clips past their armour.


With that said, I have no idea what physics engine the game is using, or if its using a middleware engine at all. Which means that they could do fancy checks to 'unwrap' the ship and see if the surface is intact, and if so, not allow the things below its surface to be damaged yet. (only seen this done once, but it is possilbe)

Dedicated racing/exploration ships reaching 200m/s is probably isnt a bad thing, but having everything able to go 3.3m (@60hz) through eachother seems a recipe for disaster. Speed limits are put in after much testing usually. I do really like the idea of a ship literally shaking apart from the stresses of going so fast, so only some ships can hit the limit, while most others are at a more sustainable, but varied, ~125-150m/s. Conceptually very cool.

 

[five]

I understand your opinion and I agree, that not every ship should be able to go the real life equivalent of mach 1. Though I think it should be possible. And to the problem you just tried to explain. Every object has a current position. Your problem could be solved by a short amount of code: Check if something is between the current position and last position (last tick), if Yes then it crashes with the object it SHOULD have hit.

 

[ChaosRifle]

I'm not sure you quite followed, or may not know how physics engines generally work (i have no knowlege of how Frozenbyte handles things, but based on past experience I will try to share an understanding) so I will try to reiterate, the issue isnt that it doesnt detect the hit at all, its that its late (in most cases, I'll touch on this later). Doublechecks like what you suggested are very time consuming, its faster to just increase the tickrate, both solutions requires better performance on the machine running the psysics anyways though. Its just how things are, it is the limit of where were at technically.

The problem with a faster speed is that things can get up to a set distance past what they should be able to, relative to the max speed divided by physics engine tickrate, through another thing before it is detected at all. Its possible to fire a plate at another plate, face to face, and they can, depending when the 'impact' (lack thereof) happens relative to the physics ticks making them completely go past eachother(as mentioned above in some cases). The Issue I was meaning though, is where you can go through a small section of a ship, bypassing armour. If you fire a missile that goes 150m/s, at a ship flying towards you at 100m/s, thats a bit over 4.1m of play there. this means that the missile, if its lucky (for the one firing it..) can travel happily past your armour quite easilly, and detect the collision on the inside of the ship, meaning all your armour was useless against that missile, if you got unlucky and had thin armour. This issue becomes more common the faster you go.

Now, generally projectiles are calculated with raycasts (think draw a line and check for a thing in the way of that line) to check and avoid this issue, but they are very resource intense compared to conventional methods(and thus are not used for ship-ship collisions in most games), and a point source, not 3D like a ship model. For a small missile, nobody cares if you hit the side of the missile nose cap 2cm off the middle. its a missle, nobody sees that, and equally should it hit by grazing the side but not detect it, its fine grand scheme of a firefight, it looked mostly like a miss anyways, visually speaking.

In the case of a player made weapon that does use the standard ship-ship collisions, things can get weird fast.. with a reactor set to go critical, you could fire it and have it explode inside the enemy ship most of the time if it only has one layer of armour at 150m/s. Remember, if they are flying towards you when you fire, it only makes this issue worse, by allowing an even further margine of error to exist(it adds the numbers together). even if they had armour capable of surviving the blast (which doesnt exist right now, but may later.. and say it does for arguments sake), now that blast is on the inside of their ship, and the armour is thus not protecting the ship, and depending on how they do the explosions, explosives in the real world get more powerful when you try to compress them (in an encolesed space... like a space ship with a very distinct lack of a hole in the side of it... yet!).


As you can understand, the issue is a limitation of what our hardware can do with current physics techniques, Doing a hybid raycast sytem for the ship collisions could help, but where would you raycast from? center of mass? what about really long ships, now how far ahead of the ship are you checking? or ships that are a donut, where the center of mass actually has no ship there at all? things get weird fast with custom ships. Its no simple answer and its why other games usually cap at around 100m/s for a reason.

Sorry if you do understand and its me that missed something and just subjected you to this wall of text If you do have experience in the industry and know of better ways of doing things, by all means, talk shop, I, and I am sure many others, would love to hear it.

 

[five]

You were right: I am not that experienced in the industry, but somewhere you have to bite into a sour apple. Either you double check if something was inbetween your last and current position or you have to increase the tickrate. You either have option A or option B. Its up to the devs to decide, what to implement maybe even a mixture of both, atleast something that prevents situations like these. I really dont like a hard cap, in SE one of the first mods I got was a mod that eliminated the speed cap, though I am not against preventing it PHYSICALLY to go beyond light speed.