2d Position Replication

Scenario:

Game where the characters are 2d objects (GuiObjects) that can be controlled like a normal character, except on 2 axis… Can move up, down, left, right.

How would I go about replicating the character’s position to the server efficiently?

The only method I could think of is to constantly fire a RemoteEvent from the client to the server… however there is bandwidth limitations to this, and I would need to fire it something like 30-60 times a second: per client.

Any input? Has anybody achieved a multiplier 2D game on Roblox?

2 Likes

Just fire based on input events, when they press/release a movement key (change their move direction or speed). Then you could just have the client simulate the other players’ movements and correct it if it’s wrong.

Does this sound like a decent layout?

  1. Client presses a movement key (W/A/S/D) : Fires to Server for movement change, Client immediately starts to move 2d character in the direction it desires for immediate feedback
  2. Until the Client fires again, Server constantly calculates the movement in the characters current ‘direction status’ (Up/Up-Left/Up-Right, etc)… This could be something like a constant 3 pixels per 0.1 seconds.
  3. Server constantly Replicates the new positions of all characters thru their respective PlayerGui’s

That sounds about right, but if you were to send the direction/speed to the other clients, they could guess where the other client should be. Of course, you’d have to then have a system that would update the inital position once they recieve a new direction/speed; since you could fall out of sync (might even be a good idea to periodically send an update).

3 Likes

You could fire 15 or 10 times a second and have the other clients smoothly tween your position, so it looks smooth (and compensates for server lag instead of looking like you’re teleporting)

Another thing is you could have a table on the server with all the positions of players, when they tell the server their position the server updates the list. Then the server will fire all clients with the list 30/15 times a second. That way instead of firing all the clients every time the server gets fired, it fires at a consistent rate.

2 Likes

Sending all these remote events seems overly complex. Wouldn’t it be a lot easier to just create a part in 3D space for each player? You could give each player network ownership of “their” part, and let them control that part using WASD (basically a custom character that moves only along 2 axes). The client can then use every player part to position and orient the GUI version of the respective player.

If you are dead set on making a 2D game, use @Darkmist101’s replication method.

Otherwise, it’s much easier to make a pseudo 2D game by simply adjusting the camera perspective than it is to make a legitimate 2D game with GUI objects.

They are both usable approaches. A remote event that sends a few values like X,Y coordinates, or a 2d velocity is certainly not overly complex. It’s dead simple and lightweight in terms of the amount of data that gets replicated, relative to something like a part CFrame (which is 12 floats). The part-based approach would make sense if you want to make use of Roblox physics and part collisions, but map the results onto a 2d GUI “view”.

Cody’s low-FoV suggestion is the preferred way to do an effectively-2d game. ScreenGui are not optimized for 2d sprite animation, and never will be; this is not a supported use case. There is a very real risk that a future change to UI layout code could make something that you create now completely non-viable, performance wise.

5 Likes