A server-authoritative character replacement for roblox. This is a complete replacement for character physics and replication for roblox. It implements:
Server owned character physics
Client network rollback
Player model replication with bitbuffer compression
100% custom collision detection
100% custom player movement, including acceleration and friction
Several anticheat strategies - Is completely immune to fly, teleport and clipping hacks
Because due to Client-Server replication, Things like These happens:
Not so smooth transition between client-Service networkPhysicsOwnerShip meaning that the parts that rely on physics get stuck in place when the ownership is switched between players and server.
Exploiters have complete access to the client.
Other stuff i dont know but sure do happen because of roblox’s replication system being behind the industry standards by a certain level.
I think this is a great module all in all. Just need a little nudge of optimization and its gonna be very useful.
Im def not going to use this in my upcoming game (Well i still did not decide). But ill test it in my own accords.
This is meant to be for competitive real-time multiplayer games, for people with relatively smooth connections.
If you have 900ms latency, this is not going to be a great experience for you
It’s a strange thing to bring up, you’re already not going to be able to play overwatch or valorant on a 900ms connection - there is no magic that is going to make that a fun time.
Hmm, So your saying that its useful for competitive real time multiplayer games? Just like rocket league, fortnite and valorant?
Cool! im making a game similar to this… but im not completly sure if this module is a great thing to use for low-end and mid-end devices that can already play Fortnite and rocket league… I would love to see a preview video of this system at work… especially in competetive game like situations.
Are you sure this is working properly? I tried hopping on the test place using a ping emulator (credit to Inobservatus for showing me this), and the character moved perfectly fluidly with 1000 ping.
I would advise against shrugging off performance at seemingly ridiculous latencies like 900ms. Not because anybody would have a sustained 900ms connection, but because there are a surprising amount of people who have acceptable average ping, but experience frequent (every minute or so) ping spikes that can go up to ~2000ms (from what I’ve measured). Those ping spikes usually last a few seconds, but in that time, if the system doesn’t handle high ping well, things can go haywire.
The reason why I know this is because my racing game also uses server authority, and I had quite a few testers who experienced issues with it because of ping spikes. I was able to improve my system significantly and now it will gracefully handle >1000ms ping without any issues (tested in studio using the network latency simulator).
Anyways for the record I tested your game from a VPN that managed to get me ~350ms ping, and the experience felt no different than when I played on my 60ms connection.
This is absolutely amazing so far! Something like this is absolutely essentially for any PvP game. Client authority movement is just unacceptable in competitive games.
If you are still looking to expand the module, I have some feature requests:
-Compatibility for additional roblox interactables (right now ProximityPrompt doesn’t seem to work, likely because it requires a Character or something)
-MeshPart/Terrain collision
-Player-Player collision
-Climbing state for TrussPart ladders and such
-Default R6 Rig Support (I already got this working, but it would be nice to have default)
-Support for a MaxSlopeAngle to prevent walking up 89 degree walls
-Additionally, maybe a simple ‘gun’ tool to show help developers integrate this into an shooter type game
This module is great and a major step towards finally allowing secure competitive games on Roblox. Hopefully with the recent exploit prevention survey Roblox will also be taking steps to solve these age-old movement exploits.
Compatibility for additional roblox interactables (right now ProximityPrompt doesn’t seem to work, likely because it requires a Character or something)
Agree, but anything that would involve forking a system to get access to it is zero priority right now.
-MeshPart/Terrain collision
Waiting on roblox for this one. They’ve said they’re going to do swept collisions at some point in the future, allowing me to discard my horrible hashmap/minkowski summed convex hull solution.
-Player-Player collision
Agree! Although players are big fat boxes right now…
-Climbing state for TrussPart ladders and such
Low priority. But player states needs to be added for sure.
-Default R6 Rig Support (I already got this working, but it would be nice to have default)
Pull request! Not sure I agree about it being the default, but an option would be nice.
-Support for a MaxSlopeAngle to prevent walking up 89 degree walls
Agree.
Additionally, maybe a simple ‘gun’ tool to show help developers integrate this into an shooter type game
It won’t be using a tool system, but some weapon code does make sense.
Of course, I wasn’t shrugging it off - I simply said it’s not going to be a fun time. As you noticed, it already handles a purely high ping quite gracefully
What it’s less forgiving about is dropped packets, and connection interruptions. The general rule of thumb is anything that is going to make you appear laggy to other players is not forgiven by the system, but there are buffers in place to make that less likely.
I think the key to making server authority work for high ping/variance is to handle rollback/correction as gracefully as possible. If you’re doing proper rollback, as you say, it should be not an issue at all.
(below is not directed to you, but might be of use to anyone looking at server auth):
For me, I did not want to afford the client-side CPU costs of recalculating rollback’d frames so instead opted to try and estimate the “current ground truth” after a correction through some basic position extrapolation. That was a really, really bad idea and would lead to a completely unstable system at high latency. The solution, I found, was to simply give up on preserving the simulation time-scale for the desync’d client, and simply revert the server state back to the last frame where the client had already received the server’s position (so simply go back by “one-way-latency” duration). In a racing game, this can lead to time loss in a race obviously, so I combat this disadvantage by applying a time warp to future simulation until the client is back up to speed with the rest of the players.