Movement refactor

[metalgearsloth]

Currently our movement has a fixed velocity when most games have some form of acceleration which makes it feel significantly better. Currently our mover code can't support this without the server constantly correcting the client because we update the client's velocity every frame so you'll get compounding issues.

From the reading I've done in an ideal world we would:

1. Save the inputs every frame alongside the timestamp on the client (we already have the inputs but not the timestamp afaik)
2. Send these to the server every tick + our final position
3. Server re-runs those inputs and determines its own position
4. If significantly different adjusts the client

Source treats player movement separately to physics and essentially does a raycast every time a mob moves to validate it won't be stuck in anything. We can more-or-less support this already as currently mobs fake pushing by applying an impulse to colliding objects.

You'll also need to somehow add in support for stuff like atmos pushing + conveyors. Some games like Barotrauma just turn off kinematic movement and make the player a rigid body for stuff like this which is what we do already which should be okay for now.

This is gonna be torture to code but is something that probably should be done.

[ShiftyRail]

I would like to comment that if the movement code implements a way for entities, or to borrow from BYOND, "atoms", to be locked to the grid whenever they're not moving. BYOND itself already let you mix and match both systems.

I am a firm believer of tile movement as it makes the flow of people more predicable and results in a game that is a lot nicer to "read" visually. It automatically gives a sense of composition and structure to the screenshots you take as well.

Take this few screenshots:

Regardless of your taste of the sprites used, would these images look the same if the characters weren't perfectly lined up with one another?

Without renouncing to the freedom of pixel movement for most entities, adding a way for mobs to remain fixed to the grid would be a good thing to implement and I believe would go a long way towards convincing the majority of existing ss13 players to make the shift - as of now, most if not all SS13 servers use tile movement.

On a technical level, it could be feasible that when an object decellerates its movement is extended to "snap" the nearest tile. I just want to stress how important I feel this issue is.

Thank you.

[metalgearsloth]

Issues with grid movement barring the obvious:

• Shuttle rotation isn't really viable anymore without making the movement feel really bad when going on / off grid because the grid may not necessarily be aligned compared to the map. This also includes when going over space tiles.
• The code has to get a lot uglier adding hacks unless you completely drop one movement method; assuming you don't use the physics engine you need to manually move thrown things (the old controller method which was awful to use) and assuming you do you now need to special case a bunch of stuff (stuns, slips, atmos, etc). This also includes any VV things like if a player takes control of a pie this must now be gridlocked.
• Prediction feels worse because instead of potentially just going back a few ticks you need to re-predict the entire tile movement.
• Code's open source, you're free to fork it.

[ShiftyRail]

Of course I am free to fork it. As I am to post a suggestion here. Which you are also free to ignore or implement. The general idea was more to allow the two systems to exist in parallel, much like BYOND itself does it, actually. Some entities would be moving freely, like shuttles or projectiles. Other would be better sticking off the grid.

I am willing to try to scratch my head a bit and attempt to contribute to that goal. I do think it's useful to see how it could be done, on a technical level. I prefer github issues I can refer to later on over an instant chat over discord.

Le jeu. 25 nov. 2021 à 13:04, metalgearsloth @.***> a écrit :

Issues with grid movement barring the obvious:

• Shuttle rotation isn't really viable anymore without making the movement feel really bad when going on / off grid because the grid may not necessarily be aligned compared to the map. This also includes when going over space tiles.
• The code has to get a lot uglier adding hacks unless you completely drop one movement method; assuming you don't use the physics engine you need to manually move thrown things (the old controller method which was awful to use) and assuming you do you now need to special case a bunch of stuff (stuns, slips, atmos, etc). This also includes any VV things like if a player takes control of a pie this must now be gridlocked.
• Prediction feels worse because instead of potentially just going back a few ticks you need to re-predict the entire tile movement.
• Code's open source, you're free to fork it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/space-wizards/space-station-14/issues/4542#issuecomment-979196502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPWLGWMMQRGI34UZS3OAK3UNYX4XANCNFSM5DDCHA5Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[PJB3005]

It is basically impossible to "nicely" have these two systems exist side by side. You can, at best, tailor the code around one and then have the other be the janky, poorly maintained alternative.

[AJCM-git]

@metalgearsloth movement acceleration addresed this or is there more to be done?