Variable maximum speeds for ships

Jack Menzies shared this feedback 3 years ago
Submitted

After clocking well over a thousand hours on space engineers, one thing I've always wanted has been a way for ships to go faster.


One idea I have thought of to implement this is a thrust to weight/block count ratio. The more thrust a ship has, not only can it accelerate faster, it would also increase the maximum speed of a ship. The maximum speed would also be capped depending on the block count of the grid. This would prevent players who've built titanic vessels creating klang's version of the eye of terror, and destroying every CPU in a 10 km radius. Of course, this limit would also take subgrids into account when calculating the speed cap. Smaller grids would then naturally be able to surpass speeds of larger grids. This means that players will also need to consider if they want their ship to be a small and fast scout ship, or a large but slow tanky ship.


One way to make this more versatile would to be to also be able to tweak the ratio in the experimental settings, so those who have a computer powerful enough to cope with Spaceball 1 going at ludicrous speed can enjoy said speeds.


Before even posting this, I can already hear people asking "What about planets? What about other grids?" Well then, my fine sirs, let me explain my idea on that field too. I'll first cover other grids. When a grid which is going at an excessive speed approaches a grid, the players close to said grid will be given an alert that they are approaching another grid and should slow down. The game will also decelerate the ship. The closer to the grid that they get, the greater the deceleration. This also prevents super op plz nerf torpedoes that annihilate any grid with a single boop. I believe that 100 m/s relative to other grids is a safe top speed within close proximity, say 1~5 km away.


For asteroids, and moons, and planets, this would work in a similar way. The maximum speed would be limited to 100 m/s if they are close to then surface, once again around 1~5 km. This would allow for faster atmospheric craft, but would require them to fly at higher altitudes to gain access to the better speeds. To add a bit of a risk factor to planets, it could be that if the game is forcing the grid to decelerate when entering atmosphere, the grid will also take damage. Literally reentry damage. If a player has already heeded the warning that was provided telling the player that they were approaching a planet (they're kinda hard to miss though), they will not take any damage.


Adding onto this idea, for unpowered grids in atmosphere that are free falling, they will take reentry damage, regardless of their speed. This would make the grid smaller, or perhaps destroy it completely before it impacts the surface. This would lessen the CPU strain when an unpowered grid impacts upon the surface.

Replies (3)

photo
1

This sounds awfully complicated. SE is a jury-rigged mess, it's probably a good idea to keep it simple.

Suppose we just add a bonus to max propulsion speed based on acceleration. For example, if a ship is accelerating at 20 m/s2 when it hits 100, it can go to 120. This allows high-speed pursuit to actually be meaningful, hopefully without allowing ridiculous speeds for any really large grids, and also allows large grids to build up momentum without a ton of thrust.

photo
1

It does not seems really logical to have a relation between thrust and max speed in space, where there is no friction restraining the speed. And yes, a max speed limitation also does not make sense, but it's clearly a collision detection issue of the 3D engine here. And it will still be an issue to detect distance from other grid / asteroid/ planets in time if the speed is unlimited or too high. It could mitigate errors, but will not remove them.

photo
1

It's not great to have variable max speeds in relation to thrust, but having a flat max speed causes chasing an enemy ship to be pointless. A system that allowed ships with more thrust to move faster retains as much qualitative realism as possible while minimizing the processing power required.

photo
1

That's true, I see your point. Perhaps something like a temporary boost or afterburner ? Limited in time, or consuming resources (Uranium or something like that) could do the trick.

photo
1

Or maybe we can have a minor variable boost scaled to thrust/weight ratio when a force is actively pushing a grid. That would always scale effectively, approximate realism fairly well, and consume resources, without requiring new blocks.

photo
1

I can accept that the concept is not 100% realistic, however I am more concerned about the gameplay side. As someone who has studied game development, I can say that gameplay is often more important that realisim. Take GTA V for example, being able to rotate cars in mid air is not realistic, but it improves the gameplay to make it more interesting.

My mindset for the thrust to weight ratio is to give people the opportunity to put a lot more attention to the design of their thrust and power design. You want more speed? add more thrusters. You have more thrusters? You need more power/fuel (depending on thruster type). I can easily foresee people making raiding ships with large engine sections to have higher speeds.

Regarding the slowdown stuff, yes, not realistic, but I must ask you, have you used a speed mod and slammed a large grid into a planet to see what would happen. As you know, large grids already cause a large strain on the system as the damage physics calculate the damage on the grid and the voxel, however, at high speeds with the mod it is possible for the grid to phase through the voxel, becoming permanently stuck below the surface.

Of course, it would be amazing if it were realistic like KSP, but the scope of this game is vastly different from that. With the block deformation and damage it takes a lot more power. A key factor to remember in game development is that not everyone has super powerful computers. Some people are running budget builds.

I am aware I have written this as a bit of a mess, but that is just how my brain works. I tend to write things as a mess. Tis just the fun of Autism. So, apologies if this seems complicated, but after having experience writing Game Design Documents in college, I am used to writing a feature covering everything, even the smallest detail,

photo
1

Not a mess at all, an you are perfectly right, game play first !

I was just pointing the "realism" stuff since I am now only using SE as a coding sandbox, and so, my head right now is just in code and physics equations, it was just a note.


I do not fly any of my ships any more and just use scripts for this. This kind of changes will not impact me more than this and I can perfectly deal with them. And since my case is surely not the vast majority of usage, It should not be taken into account.


Yes, I played with a speed mod, up to 400 ms/s, but only in solo, and I understand why this can lead to issues, I have been warned.

So yes, the best solution will be the one that fit the needs of the majority of players, and one that the (nice) devs can add without too much pain or work.

And sorry for my poor English, it's not my mother tongue.

photo
1

i think it should also account for how fast the ship can stop within a certain time frame from its max speed

photo
photo
1

However this would work, your space suit still needs to be able to move at 10m/s more than the grid you're in, otherwise you can only walk towards the rear of your vessel while it's moving at speed.

photo
1

That indicates that passenger velocities are not relative to the grid.

photo
1

That is 100% correct. As soon as you leave your seat, you are a separate body.

photo
Leave a Comment
 
Attach a file