Easy way to have multiple matches in the same server

  • I want to have multiple matches on different maps going on in the same server, without being able to see other matches from where you are. I know games like MeepCity have accomplished this (but MeepCity just had the multiple areas part, which is what I'm worried about). I want something that wouldn't be very intensive on the client. I know parenting stuff to the players camera works, but I was wondering if any other solutions exist and use Roblox's default humanoid replication.

    (Also, I made this on the forum because I feel this could have more discussion, which the normal site doesn't really work with as well.)

  • Internally, there are strictly 3 ways of replication in roblox:

    1. Server Exclusive - Instances do not replicate to any of the clients. This can be achieved by parenting objects to a server camera, or to any service/container exclusive to the server.

    2. Client Exclusive - Instances do not replicate to the server. Can be done by parenting objects to the client camera, or to any service/container exclusive to the client.

    3. Server to All Clients - Instances replicate to all clients from the server. Typically occurs within the workspace.

    Subsequently, there is currently no method that roblox themselves have implemented to replicate instances from the server to one client (and vice - versa with NetworkOwnership). There are many ways to achieve something similar to this, though with it comes different pros and cons. If you'd wish for me to list off common methods I know of, I'd be happy to do so.

  • @Dog2puppy

    I don't know if I completely get what you're trying to do, but as for what I have understood, this is what I would do (With Filtering Enabled):

    1 - Player wants to enter an area. If the area already exists, he follows step 5. Otherwise, player Fires a RemoteFunction telling the server he wants to enter the area. Player waits for the area to be created.

    2 - Server creates the area and tells the player it is ready.

    3 - Player enters the area.

    4 - All other players that have nothing to do with that area move the model that contains the area inside a folder in their "PlayerScripts", so they don't render it. The area is still being replicated between the server and all players, but players don't see it.

    5 - If they want to enter the area, they simply move the model from PlayerScripts to the Workspace.

    6 - If everybody left the area, the Server can Destroy it.

    Maybe this helped?

  • @LateralLace @Aimarekin Thanks for your replies. Sounds like it might be better to just use TeleportService like I was originally planning to.

  • Global Moderator

    @Aimarekin You shouldn't use PlayerScripts for storing models. Use ServerStorage and ReplicatedStorage instead, that's what they're for.

  • @Link150

    A client can not access ServerStorage, and I want the model not to replicate between server and clients, so I can't use ServerStorage, neither ReplicatedStorage.

  • Global Moderator

    @Aimarekin ReplicatedStorage should work just fine. It can be accessed by the client and, thanks to FilteringEnabled, the reparenting of the model wouldn't replicate to the server and therefore other clients.

    Although, I think I can see some issues with either solution.

  • Global Moderator

    @Aimarekin This is irrelevant. FilteringEnabled still applies to ReplicatedStorage.

    When ReplicatedStorage was first introduced Experimental Mode was still widely used, and in Experimental Mode its contents would be replicated back to the server, hence the description. But this is not the case with FilteringEnabled turned on.

    In fact, you can't turn FilteringEnabled off anymore; the setting is now a dummy. So this description is outdated.

  • @LateralLace
    If the server adds something to a player's PlayerGui, that object will be replicated to that specific client. I don't know if that's officially supported behaviour, but I read that someone successfully made a large Roblox game using it.

    You can also manually replicate models, animation, etc using RemoteEvents - though they can't send server-only Instances, you can refer to anything in ReplicatedStorage and instruct the client to clone, move, animate, and destroy models as needed.

    Further, you can keep the default humanoid replication without seeing other players if you have the client store (in ReplicatedStorage*) all character models of players who aren't in the current match. (The client should keep track of the models and reparent them to the workspace if you want the client to see the other players again).
    *If you set the parent to nil, animation errors will occur when a player tries to move.

  • Global Moderator

    @chess123mate Yeah, adding objects to a player's PlayerGui from the server is perfectly fine, and supported.

    But while adding Guis to a player's PlayerGui container from the server is fine, it is wrong to modify a player's Guis from the server.

  • @Link150
    Oh? What do you mean by "wrong"? (Or maybe my question is what do you mean by "modify"?)

    I just tested it out (using Test mode in Roblox Studio) and, as expected with FilteringEnabled, no client changes nor input are replicated to the server, so (for example) modifying a TextBox that the player has already entered text into would overwrite client-side changes. I agree that a server should not be trying to update the GUI based on player input events - it can't receive them without RemoteEvents, and there'd be the latency between server and client that would make the GUI appear unresponsive if this were attempted. But do you see anything wrong with the server managing a "server status" label (that the client code would then not modify)?

  • @chess123mate

    That won't work in live servers, but will work in Studio because FilteringEnabled is not taken into account while testing solo in Studio.

  • @Aimarekin In Studio's Play Solo mode, there is no separation of the server and client.

  • @incapaz

    That is what I was saying

    EDIT: Well, ok, you expanded it but It's similar.

  • Global Moderator

    @chess123mate Separation of concerns. The server should not have to mess with client-side stuff. This is the client's territory. The server should merely notify the client through a remote and let the client make the necessary changes itself.

  • @Aimarekin and @incapaz I tested this in "Test" mode in Studio - not "Play Solo". Start a local server with 1+ players and you can test it out yourself - it is the same as a live server on Roblox (as far as I know). ex, if you add a Part in the workspace of one of the clients, it won't replicate to the server nor to any of the other clients.

    @Link150 Fair point. I suppose, even in the example I was thinking of (updating a server status message), the moment you want to display it differently to different users (whether because of different devices, resolutions, user options, etc), it's better suited for the client to handle.

  • @chess123mate Things client should handle:

    User input
    GUI powering (listening for them to be clicked and such)
    Playing animations (these replicate to the server)
    Modifying GUIs (changing colour, visibility, etc)

    As stated before, it's fine for the server to add things to the PlayerGui, but they shouldn't be modifying it. Just because something works doesn't mean it should be used.

  • @chess123mate

    We already know what is test mode and play solo lmao

Log in to reply

Looks like your connection to Scripting Helpers was lost, please wait while we try to reconnect.