Storing Player Data - Server Sided

Help and Feedback Scripting Support
#1

Please do not get confused with the title, this does not have to do anything with Data Stores (yet)

I have a building system where whenever the client places a brick, the client sends that brick data to the server, however I am unable to decide how to save their data temporarily on the server before saving the placed bricks’ data to the DataStore.

I’ve came up with two methods:

Method 1 - Data Stored in Server Script Variables

Whenever the client places a brick, the data gets sent to the server, and the server keeps individual client data in a table on the server script.

local PlacementData = {
   Player1 = {
      Brick1 = {
         Position = "X,Y,Z",
         Size = "X,Y,Z",
         Orientation = "Y",
         Color = "Reallyred",
         Material = Enum.Material.Brick;
      },
      Brick2 = {
         Position = "X,Y,Z",
         Size = "X,Y,Z",
         Orientation = "Y",
         Color = "Reallyred",
         Material = Enum.Material.Brick;
      }
   },
   Player2 = {
      Brick1 = {
         Position = "X,Y,Z",
         Size = "X,Y,Z",
         Orientation = "Y",
         Color = "Reallyred",
         Material = Enum.Material.Brick;
      }
   }
}

Method 2 - Data Stored in Server Storage

Whenever the client places a brick, the data gets sent to the server, and the server makes a folder in Server Storage to each individual client with corresponding placement data.

image

Usability wise, the table with variables would be easier to save to a data store.

2 Likes
#2

You should use your first alternative, store the data in variables in your code (like a table which holds all player data). Roblox has made it easier to have alternative ways to store the data, you should get used to do it all with coding, though, as with many other game engines you must do it through coding, and not by creating objects. (I mean, you probably could, but it’s just bad practice.)

I would recommend that you use ModuleScripts so other scripts can access the data as well.

3 Likes
#3

I’d go for Method 1 too, you’d be using less memory this way around other than making Folders and values to hold each brick.

In addition to this, it would be easier to implement algorithms to try to stop data loss since you got a place to store the data before its saved

3 Likes
#4

Also you should better optimize the data you are saving if it’s always the same. There is no reason to have a dictionary Instead if an optmized string if it’s always the same data, you will just end up using more space than what’s needed.

You could also compress your data, but that’s up to you.

An example of how your data could look like when saving:
{position, size, orientation, color, material}

And if you only give the players certain colors to choose from you could also shorten the data again by creating a dictionary with unique keys that refers to certain colors.

Example:

{[“r”] = “Reallyred”}

Now in the end you can also do this with the orientation and material if you want.

Example data:
“15,12,13|200,1,2|5|r|SmoothPlastic”
In this case, “|” is the separator.

1 Like
#5

I would use method 1 for 2 reasons:

  1. It uses less memory
  2. More efficient than creating values inside of a folder
2 Likes
#6

The code above is just for easy interpretation :slight_smile:

I use tables just like what you’ve mentioned

1 Like
#7

I would go for method 1 as the others have said it will require less memory. Also you should put checks in place to check for exploits to be on the safe side as the client is sending information to the server. You will only need to put checks in place if you are using LocalScripts. The checks could be to check the bricks position and orientation as an exploiter could put the brick outside the plot boundary’s.

2 Likes
#8

I recommend saving brick data in tables, module scripts are great for this, other scripts can access the data aswell then, uses way less memory than storing it in folders and object values too.

If you need clients to access brick data simply just send a copy to the client.

Make sure to make building exploit proof as well, send a position and brick type to the server and let the server decide if the position and brick type is valid.

What I also would recommend is to have set of bricks so you no longer need to store data like material and color but can store bricks just by name.

Little example, you have a brick with the color red and the material slate in Replicated (or server) storage, this brick has the name “RedSlate”, if you do this you only need to save the name, size and cframe.

players = {
 ["Player1"] = {
  ["Brick1"] = {
   ["BrickType"] = "RedSlate", --A brick with the color red and material slate.
   ["CFrame"] = CFrame.new(), --CFrame = position + orientation.
   ["Size"] = Vector3.new(4, 4, 4)
  }
 }
}

A brick with the name “RedSlate” must already present in a storage though, this way you don’t need to store data such as color and material but only a name is required.

Hope that helps.

2 Likes
#9

I personally use a modified version of idea 1. I store players data in a global (_G) table that every server script can access.

1 Like
#11

Not sure if this is a good idea but what you also could do is
store brick data like this.

["RedSlate"] = {CF = CFrame.new(), Size = Vector3.new(4, 4, 4)}

That way you only need to store the CFrame and Size of the part.
To load data/build you simply cycle through the whole table for every type of part the game has, to improve perfomance a little you make a temporary copy of the table and remove the parts/bricks that have already been loaded so that you don’t have to cycle through so many bricks for every type of brick your game has.

What I mean is this basically.

for num, v in ipairs(Players[Player.Name]) do
 if Players[Player.Name][num.."_RedSlate"] ~= nil then --Check if bricks of this type still need to be loaded.
  --CODE
  table.remove(Players[Player.Name], num) --Remove it because we don't need it anymore after loading, perfomance+.
 end
end

Please correct me if I’m wrong, hopefully you do understand what I mean.
This way you can save a lot of memory in the save data if I’m right.

1 Like