3 Easy Changes Keen Can Make to Address Space Engineers' Gameplay Balance Issue
Submitted
Hey, this is coming from someone who does play / stream official multiplayer vanilla survival a lot (3000+ hours on SE), just pointing that out so you guys know it's a suggestion from someone who's intimately familiar with the game's mechanics c=
I think these changes I'm suggesting won't be too hard to implement, won't break anything, and will make the survival gameplay much more balanced and enjoyable for everyone (and make people play longer and more people play!)
I also made a video of it: https://youtu.be/tiar7t_s3xc
So here's the suggestions;
- Jetpack acceleration should be significantly reduced
- People shouldn't spawn with a grinder
- There should be a block that makes voxel within an area undrillable other than safezone block
And here's the explanations of why;
- As of right now, the Risk VS Reward balance of the gameplay is pretty imbalanced - if anyone really wants to they can destroy anyone's build without investing in anything, and just using the jetpack + grinder combination they can easily avoid turrets altogether or circle around them until they run out of ammo. By making the jetpack accelerates much slower, it would be much harder to do these cheese methods, and it will give small grid combat vessels more purpose previously occupied by this jetpack method, all without breaking the jetpack's other purposes (building, etc)
- As of right now, it's very easy to respawn over and over again either through the respawn menu close to someone's base / build, or by parking your ship / survival kit next to someone's base or build, and keep coming with a jetpack + grinder, if people spawn without a grinder they will have at least to make it first or bring in a supply of grinders, which I think is a more balanced approach
- Now, this is more of a feature request than a change, but there's already safezone and that can be easily modified to make this block - basically this block will give voxel stations more practical purpose, as of right now there's 0 practical purpose of having a voxel station (asteroid or planetary / moon-based), with this block, it will make voxel stations much more useful and it will opens up a lot of fun gameplay possibilities. Or as I wrote it in the video;
tl;dr: It will be like a safezone block but only prevents voxel
within its area from being drilled, consumes much less power and
doesn't require zone chip (200m range limit @ 1MW, for example)
This would give stationary asteroid or planetary bases an
actual, practical purpose as a much more defensible
location or structure, or a place to store your ship, or ships,
and force any attacker to actually attack with a ship
or tank, or besiege the base
It will open up many and much more fun gameplay
possibilities, where the defenders can actually holdout
their cave for example, as the attackers are forced to go
on-foot or on small vehicle to get in and attack
As of right now, even with the safezone block, it is more
practical to put the safezone block on your ship anyway,
the new "particle modulator" block will specifically make
voxel stations much more purposeful
And coupled with the other suggested changes, they
will give small grid combat rovers or ships more reason
to exist as cheap ways of attacking (instead of jetpack)
I wish you guys would consider implementing these changes + feature I'm suggesting! Cheers! c=
Your first point largely nullifies the second. If your base has adequate coverage, lower acceleration prevents a suit from getting within grinding range. Also, it would be really annoying to need to make a grinder for each respawn.
The voxel protector completely destroys realism, but otherwise it's pretty much perfect for adding depth to PvP without needing extra complexity. Bonus points for using only preexisting mechanics and minimizing complexity. I'd add something like a power penalty for having another protector within the radius though, so you can't just spam them around your base and completely prevent sabotage during a siege.
Your first point largely nullifies the second. If your base has adequate coverage, lower acceleration prevents a suit from getting within grinding range. Also, it would be really annoying to need to make a grinder for each respawn.
The voxel protector completely destroys realism, but otherwise it's pretty much perfect for adding depth to PvP without needing extra complexity. Bonus points for using only preexisting mechanics and minimizing complexity. I'd add something like a power penalty for having another protector within the radius though, so you can't just spam them around your base and completely prevent sabotage during a siege.
I suppose, but I still think it would still be more balanced that way, because having a grinder at every spawn allows anyone to just keep going. But I see your point, and there might be an issue too if a group of people in their base is cornered for example and they don't have grinders at hand.
It would yeah, but SE already has jump drive and safezone so realism was already slightly out the window anyway. And I was thinking more in the line of the voxel protector block being limited in number and them not being able to overlap each other (maybe 1? But if that's too harsh maybe 7 so people can potentially make 1 for every planet, but I guess that would be a server-configurable setting anyway if implemented)
I suppose, but I still think it would still be more balanced that way, because having a grinder at every spawn allows anyone to just keep going. But I see your point, and there might be an issue too if a group of people in their base is cornered for example and they don't have grinders at hand.
It would yeah, but SE already has jump drive and safezone so realism was already slightly out the window anyway. And I was thinking more in the line of the voxel protector block being limited in number and them not being able to overlap each other (maybe 1? But if that's too harsh maybe 7 so people can potentially make 1 for every planet, but I guess that would be a server-configurable setting anyway if implemented)
Replies have been locked on this page!