Hi, what do you think would be better:
Replicate the train’s position on the client every frame (continuous synchronization)
Or send one-time events: “train started moving” and “train stopped,” and calculate the movement locally on the client?
And another question—how to make physics calculations for monsters when the train touches them on the server?
So, with that one time event thing, the issue would be that the location is never corrected, you can’t get around ping, its just how long it will take to send a message to the client, meaning if you sent start and stop signals, they would just get further and further from where the server thinks the train is, or especially where other players think the train is. A constantly updating position means that the difference between clients and the server is just each individual’s ping, which, would be the same if you did the updating once idea, just that instead of the differences exponentially being worse and worse, its a more stable slight difference.
For the second question, I think you kinda forgot there’s 0 context to what that means, but I can assume you are making a dead rail’s kinda thing, and that question is for how you would do it if you did the one time event idea. The answer: a lot of math, since the train wouldn’t exist in workspace (since thats automatically replicated to clients), and you would have to make your own system for all that.
There’s a lot of specific logistical issues that can arise when it comes to server -> client and client -> server replication.
The first thing I would say when it comes to replication of physical objects, models, vehicles, etc… is that you tend to want to lean on Roblox to handle that networking for you. What I mean by this is Roblox has already handled the networking needed to replicate positioning of an object to clients in a reasonable and often better way than utilizing something like a RemoteEvent. Now this comes with the assumption that the train is meant to replicate on every client. Unless there is some absolutely necessary reasoning behind not just allowing Roblox to handle the replication I would always say utilize that first by mutating the train and its positions via a server script.
There are always tradeoffs when picking the solutions listed and they are dependent on what your use cases are, and, as you didn’t fully list the use cases the best I can do is provide the tradeoffs:
The golden rule about most game development that took me a while to come to terms with (but should ALWAYS be understood) is to never trust the client. Assume that at all moments the client is a filthy liar and wants to hurt your server.
If you use the first example of replicating the trains position on the client every frame — my understanding is you would be blasting out RemoteFunction firings on a continuous loop with the server sending back coordinates. And, while this could work for a smaller number of users, as the number of users grow you could experience latency issues and a loss of packets.
It’s also worth noting there may be a rate-limit on the amount of times you can call a RemoteFvents of 20 times per second.
This would be a choice I would try to avoid entirely if possible, simply because if you are looking for reliability within the train location, relying on the client to calculate the start and end based only on a “train start” and “train stop” event can cause the train to desync, and MOST IMPORTANTLY, if new users were to join the experience where the train location would be important they would view a train that would be misaligned from the rest of the server as all it is able to understand is “start” and “end”
Overall, I truly believe if possible to just allow Roblox to handle the replication of the train, it will make it easier for you and for your users. Simply handle movement on the server directly and all users, new, and joining, will be able to have the train location and movements replicated seamlessly without the worry of overly-used RemoteFunction or RemoteEvents.
I would save yourself the heavy work of having to deal with physics calculations and include a hit-box on the train itself utilizing a .Touched event for the hit-box and then conditionally checking if the object hit (ie. an arm, leg, torso) is apart of the humanoid of the monster. If so, you can handle the logic as needed for what that means for you and the experience.
