What is a good practice for displaying data?
I am creating a game in which the Server holds all the data and the client will download bits of that data for displaying to the user.
All data changes will be controlled by the server, thus, it is unnecessary to send the data to the client every fraction of a second, but rather only when the data changes.
Say I had an object, whose components are displayed by the client. The data on the server changes. How do I convey this change to the client with the best adherence to the Model-View-Controller scheme?
Do I fire an update function within the server that conveys a change to be interpreted by the client?
Do I fire a specific function of the client from the server which tells it to update the exact element of the display?
What approach would allow room for animations to be set off on the client?
1 answer
Hey randomsmileyface,
The best way to go about doing this would be to make a BindableEvent that fires when a players' data is changed and connect to it as needed, similar to what you suggested. Assuming we make a RemoteEvent called 'PlayerDataChanged' in ReplicatedStorage, let's do the following:
-- Let's assume this is a Controller responding to a data change made by a Model
local PlayerDataChangedEvent = game.ReplicatedStorage:WaitForChild("PlayerDataChanged")
-- ...
local function OnPlayerDataChanged(player, data)
if (PlayerDataChangedEvent) then
PlayerDataChangedEvent:InvokeClient(player, data)
end
end
-- A client-side Controller
local PlayerDataChangedEvent = game.ReplicatedStorage:WaitForChild("PlayerDataChanged")
-- ...
local function OnDataChanged(data)
-- Reflect the new data on the client
end
-- ...
PlayerDataChangedEvent.OnClientEvent:Connect(OnDataChanged)
All that really needs to be done is to use custom events that only fire when needed. Pretty sweet. c:
Now, don't sweat yourself worrying about implementing MVC perfectly, just do your best and use it more as a tool to help you make better, more maintainable code. After all, the reason I wrote the article was to introduce people to a concept that makes their lives easier in the long run.
I don't explicitly mention this in the article, but the end goal is really to inspire people develop their own architectures that fit ROBLOX better. In truth, I chose MVC not because it was a perfect fit for ROBLOX, but because it's so easy to tweak to fit your needs. No wonder it's the basis for a lot of other widely-used architectures today (MVVM, MVA, and MVP, to name a few.)
In short, don't use MVC because tkc here told you to. Use it because it empowers you. Feel free to play around with it. c;
Have a good one, randomsmileyface, and best of luck with your game (and adventures in program architectures! :D )
Warm regards, tkcmdr
0
0
0
0
0