well thats a great way of letting them exploit your game lol.
Read and actually think it through.
object value wont replicate client → server. Only server → client
if the server value needs altering through the client. - Remote
if client is being exploited - it needs to be compared
Your literally saying it, but not fully understanding that it it requires a remote should the client pass on any values.
Read this. The server decides what to update, it doesn’t need info. If you have a clickergame the server decides how much to add not the client.
So where are we asking the client for info?
You could create an auto-replication object system on the server. I did it, and it works great. I can create objects on the server and attach them to players. They get automatically sent to the attached player, and updates to the table are replicated. Also have useful functions inserted into the object to allow easy communication between the existing client/server object. Also, make sure you have a GUID for each object on the client and server!
so how will the server get the players gui being clicked on a serve then. or a mouse.
you got some funny ideas on how server vs client works lol.
You know the answer to that. That doesn’t relate to value objects.
You need to rely on the client to get the mouse. That doesn’t relate to value objects.
I don’t think my ideas are funny.
If you want to tell me why value objects are exploitable say something related to it, getting the mouse isn’t a problem with value objects.
the problem is that if they exploit it and it gets replicated.
No, replication isn’t done from the client. Server only.
The clients replicated from the server.
However the server might need information from the client.
Which brings it back to needing remotes to communicate.
what your describing is a one way communication system which means the client wouldnt be able to give information e.g clicking on a gui button to earn cash.
The client only sends a request probably it doesn’t actually give the amount to set to.
so lets say theres upgrades. how does the server know what the client has.
The client tells what item he wants to buy. The server checks if he has enough money to buy it using the servers value, not the client’s.
Client: Hey server I wanna but this cool upgrade
Server: hmm let check if u have enough money using my value object since you changing it from the client doesn’t replicate here.
hey client you dont have enough, so I cannot give u the item
Client : :\
I think you’ve misunderstood me. The server is the one that sends the information to the client, not the other way around. If the client somehow manages to change a value in the object, the server will send the real value anyways. The most up to date object always exist on the server, it would be ridiculous to allow changes from the client.
I mean you do you, I really do not see how this is relevant. Why would I use OOP for something like this? I’ve already used this system for an animated combat system. The server contains methods to construct the weapon, setup stats, etc. and then it’s sent to the player. Then, certain functions, such as attack, block, etc are exposed to the client. The client has no power in this case. Server/Client related properties and methods are separated. If I needed to send data from the client to the server, I’d do what every other developer does, and implement sanity checks on the server.
Also why does the server rely on the client for updgade info…
He just gets the data from the datastore when the game starts. Then you have two ways to do this using tables or value objects.
For value objects just add a string value with the item name when an item is bought sucesfully checked by the server
well information will have to come from the client at some point for something.
unless everything is running server sided.
And that is exactly the point I was on about. an amount of communication is unavoidable. And I mentioned earlier about Encryption and sanity checks.
how does the datastore get the value then. the client cant access datastores.
Yes, I was going to edit but I will just reply here.
As I included as an edit, if I needed to send info from the client, it would be done with sanity checks just like every other developer should do.
…
The server get’s it not the client.
using GetAsync()?? datastoreservice:GetAsync() when the game starts. This gets all the data from the previous session.
Then when you buy something from the game the server adds it to a cache table if your not using value objects
This thread has gone on a bit of a tangent.
My approach is to keep data in ModuleScripts, because it means I don’t have to search through directories to get the values I’m looking for (like going through folders to find the value object, to then return the value). This can be harder to manage if you don’t organise it properly - but then again, the same applies to value objects.
You don’t need to use OOP to store data or variables, you can just keep it all in tables or dictionaries. However, a benefit of using object values and updating them on the server is that they automatically replicate. If you want more control over this, then keeping variables in scripts or at least not visible to the client would be the way to go, because then you can fire a RemoteEvent whenever you want and update the value stored on the client.
To cover what has been talked about in this thread, the security is almost exactly the same. Whatever the client can see, they can edit - this means any local variables, any local objects (value objects included). While, yes, you can obfuscate and do all of these methods to make it harder to understand your code for exploiters, it isn’t foolproof and you’d do better to not rely on that. Having a good server-client validation system is the key for security.
Hope this helped. Would advise the other people in this thread to stop derailing it from the original intention of the post. At this point, what you’re talking about it barely helpful to OP and it’s best to be discussed in DMs. Let’s keep this on topic.
The datastore has the value from the previous session saved Using SetAsync() or updateAsync