So long time ago I have created a spaceship flight system that, while it works, it uses a what I consider a subpar replication technique. This thread isn’t for actual code to be posted on, but instead ideas.
On topic again, the replication system of the ship scripts (more than two years ago, didn’t took the time to finetune it these days) is, from an user experience standpoint, generally bad - unless the user has very low ping&jitter values. The image below shows how does it work in a nutshell:
The BodyGyro and BodyVelocity values are updated by the script. The “accelerations” are controlled by the script: The velocity increases over time like:
local speed = 0
local acc = 60
while true do
speed = speed + (acc * wait())
BodyVelocity.Velocity = speed*Part.CFrame.lookVector
end
The current system was designed with a little conservative/protective mind to stop cheaters, but I realize now that since the client has the network ownership, cheating issue wasn’t really fixed, while the experience is damaged in the first place.
The main question here is, what’s the optimal approach for this so that players can have the best experience possible while keeping cheaters/exploiters in control? Your input is highly appreciated.
I would have the code to update the body movers be client side, you can always check for cheats on occasion from the server, but for quick response from the players point of view, you need to do those on the client.
I’d say the easiest way to modify what you got is to include a copy of the server side script locally (stick it in replicated storage). Then, modify the original local module to use custom events and function and fire/call them whenever the normal remote events and functions are fired/called. The ship’s ownership and then be given to the server. After these simple changes you’ll probably have something that works half decent.
To complete the solution there should be some updates from the server to the client so the client doesn’t get out of sync. Also, if the client and server are editing the same instance there may be issues (I haven’t experimented though). I’d have the client actually remove the original ship and make a copy of it. To edit the server code to have it send updates back to the client, I’d make a new ship update module which communicates to the server ship module via custom events and functions to make sure that you can have an exact copy of the server ship script on the client. You can even have the custom functions and events for sending updates to the client on the client side, but they wouldn’t be hooked up to the module that actually calculates/sends those updates since it would only exist on the server.
The final question would be how/when to send updates… I like syncing position, velocity, and acceleration, rotation, angular velocity, and torque at a given time using tick(). Given this format a client can stay completely in sync without additional updates using mathematical formulas until the ship is in some way acted upon. Usually acted upon means hit by something, or in response to user input. Since user input is being handled on the client and server, it should be smooth and nice. The server can simply send an update every time input is given or acted upon.
Using this method the user wont be able to cheat by moving their ship fast than possible or colliding with objects owned by the server.
I would have the clients own all objects far from players, and when players get close to objects, change ownership over to the server so it can handle the collision fairly from all player’s perspective. The only problem that should exist is that if player latency is high it may seem like for a second that they missed what they hit, until their ship starts reacting to the hit. But they will have to be cutting it close to see that (1/10th of a second, maybe 1/5th). From all other players perspectives it will be perfect. No cheating with ship movement will be possible.
Alternatively since this is in space with fairly simple calculations, you can also let the clients own everything and perform a couple simple checks. First you can see if with their maximum acceleration/velocity if they could have traveled as far as they did since you last checked. Second, you can sample their flight path and if they get close to objects, do some simple and lose bounding box/sphere/cylinder checks to make sure no major no-clip cheating is going on. You can choose to do these samples based on how fast they are going and how close obstacles are. While not comprehensive, this solution does offer good protection.
Unlike the majority of Sci-Fi games, this one is relatively fast-paced (see the video below) - is your proposal robust enough to account for repentine and steep changes on those values?
The issue I identify with it is that it would be hard for the server to delineate the actual fuel consumption.
I would not recommend doing any fancy server/client model stuff. You state you want:
Give players the best experience possible
Keep cheaters/exploiters in control
This does not necessitate spending 90% of your development time writing custom controllers to prevent exploiters. All you need to do is take corrective action. Sanity check client movement on the server to make sure they’re not teleporting around or going faster than they should, and if they break that sanity check, disqualify / penalize / kick them. These sanity checks are trivial to implement, and are much easier than writing a convoluted controller that bridges the client and server.
