The issue at hand involves finding the optimal balance between security and latency in a Roblox game featuring a spell casting system. Here’s a breakdown of the problem:
Current Setup:
Players can use spells in the game
Each spell has its own ModuleScript in ReplicatedStorage
Concerns:
Security:
Placing spell scripts in ReplicatedStorage makes them easily accessible to exploiters
Putting all scripts on the server improves security but introduces latency issues
Latency:
Server-side implementation requires firing an event to the server
Server then replicates the spell effect to all players, including the caster
This process can result in noticeable lag, especially for players with poor ping
Code Protection:
Unlike typical FPS games where a single “bullet” script can be used in ReplicatedStorage, each spell requires unique code which i don’t want to be visible to exploiters
Protecting this code from theft is a priority and so is latency and smoothness of the player experience
Question: What is the best approach for implementing spell scripts in terms of both security and performance? Should they be placed in ReplicatedStorage or ServerScriptService?
Any insights or suggestions on how to address this balance between security, latency, and code protection would be greatly appreciated.
I can’t tell you a good solution without fully understanding your code, but the way I handled my spells and abilities for my MMORPG was by:
storing all its properties and methods in separate ModuleScripts, and leaving them in ReplicatedStorage.
The reason was to allow easy access for the clients (which sounds counterintuitive because of exploiters), because it made zero sense to have the client keep pestering the server just because it wanted something as simple as an ability’s description.
I also made my peace with exploiters; they can have the code, but as long as they’re not ruining the integrity of my game, I’m fine with it.
Anytime a client fires an ability, it instead sends an “index” that refers to that specific module in question, but it also sends the timestamp of which the client fired that ability. The server will also keep track of when the request was received.
This was the foundation that I needed because abilities must be time-sensitive; one good ability cast at the right time can turn entire battles around here, so my server HAD to receive and process abilities promptly.
It also ensured soundness - ability casts can be received late by the server, but each ability cast must be chronological, so that the entire flow of the game made sense.
The cherry on top was how lightweight networking became - instead of sending huge chunks of data for whatever reason, now both sides of the model just has to send a specific index and the timestamp that the request was made and sent. Overall bandwidth got reduced significantly, and performance overall felt way smoother.
A good side effect to this was that it opened up an avenue for me to determine player ping - if both timestamps turn out to be really far apart or otherwise illogical, that player can be handled accordingly.
Hey, I’d propose a hybrid approach, where you handle all sensitive things like hit detection etc on the server and fire RemoteEvents to the client for visualisation.
All visualisation aspects like creating new instances, tweening, changing sizes/positions should be done on the client with this approach (unless it’s impossible or would complicate things a lot)
For example for a fireball spell on the server you could store only the current position of the fireball and in the beginning fire a remote which creates the fireball on each client, then each time you change it’s position do the hit detection handling and fire an unreliable remote event (or remote event) to each client. When the client receives the remote it tweens/teleports the fireball to the next position.
I wouldn’t worry too much about high latency players as I believe they shouldn’t be prioritised over low latency players and there’s no perfect solution to fix this issue anyway, they’ll always have some issues pop up because of their latency (for example it might seem to them like they hit someone, but in reality they were nowhere close to where they are seeing them). Don’t focus on the extreme cases is what I’m saying basically