How to handle multiple layouts in Multiplayer

Right now I'm working on a multiplayer game which will eventually require multiple layouts. Pretty much it's an RPG where players can go where they want. The problem is that the host can't be on multiple layouts if 2 players arent on the same layout. I've thoguht of 2 workarounds for this.

First one is to have every level on one layout, then set the players position to the new map when they change maps. However, even though the collision system is very well optimized I can see there being performance problems with too many players and too many maps. Another issue is if I wanted to add custom maps for players, that would not be possible.

The second option is to take the load of the player controllers off of the main server and have a new client that controls each map. Each player would be constantly talking to the main host, then depending on the level they are on, they will communicate with the other client which is handling that level. I could break "areas" into cells using the first method, so for example all of the indoor maps of a certain city would be on one layout which is handled by a seperate client. The problem with this method is that I wouldnt not be able to use the built in sync object position with the Multiplayer plugin. I would have to use my own method with instance variables and interpolation. I would also have to have a whole bunch of versions of the game for each set of levels, and have each of them running seperately which would require more resources from my computer.

So my question is, what is the best option? And are there any othe solutions? I don't think the Multiplayer plugin was really made with multiple layouts in mind, but there's usually workarounds for every problem, I'm just trying to find the best/most effective workaround.

— Yeah I know actually having custom maps won't be an issue. But it's actually loading them and placing them down properly. I dont know if there will be 1 map active, or 100. If that makes sense. And having them created for each player that has their own custom map will end up producing a LOT of new tabs and clients if I also have one for each layout

— I'm not sure if I'm going to continue trying to make a single dedicated server in C2. My first problem was with this, if there's no ways to have large amounts of maps without usinga single layout/a bunch of tabs it seems inpracticle to me. Then I had the problem with peer to peer connections where almost half the people that tried to play couldnt, which Ashley has stated is due to the users network setup, not mine. These two reasons have pretty much compeltely halted my game.

I was thinking of trying to do more of a grid based game where having the actual map loaded visually on the server would be unnecessary. Positions would be grid based on that specific map so positioning would be done realtive to the users screen, and maps would be loaded client side based on which one the server says the player is on. There is still the connection problems but that's something I (might) be willing to oversee and just tell people they're screwed unless they want to change up their network configuration

I had the same problem a whil ago and there was another topic about it. It seems to be possible to use a Server with multiple layouts if you create something like a shortcut (on key down) to recognize you as server (or loginpw) and then switch to the server layout. There you can have several buttons to open the "maps". Now open the game on multiple tabs and each tab klicks on another map button so multiple maps can be open at once. But it may have some issues if a browser tab has no focus and I did not have time to test this yet.

Use peer messaging peers for commands/controls

Eliminating Host control / logic needed.

Only use host functions to determine active rooms so players can join.

Effectively one of the peers would still be host, but would not be fulfilling host duties.

You can use ajax / php / mysql to store various info.

Chop up huge layouts into smaller.

Switching layouts is basicalyl just loading a new layout once all players are already in the room.

Upon loading the new layout, all players get created again.

Just make some back and forth checks if all the players are on the new layout and ready.

Everade Yes, thats usually what you're supposed to do. But the way that the multiplayer plugin works is that it will set the players position to an exact position on the screen.

My problem lies within having seperate maps (different layouts) lets say there are 2 players on my server at one time. There are both in the overworld and player A decides to go do a quest. The quest is to go do something in a cave. Normally you would just have the cave on a seperate layout, then when the player enters the cave, you go to that layout. Leave the cave and you go back to overworld layout. However, since player B is still on the overworld I can't just switch layouts. Now the server has a different map loaded with different collisions resulting in player B being able to walk over some walls/not able to walk over empty space.

One way of solving this is just to make the one layout have all the maps, then set the players position to wherever the "door" is that they went through when they do. My biggest issue would just be trying to handle all of that, keeping track of positions, not letting players show other players and objects not on their map, etc. Then you'll get performance issues on the clients end because they have to have every single map in the entire game loaded at once.

So either there needs to be some sort of relative position (the server would have every map on one layout, then each player would have them in seperate layouts, the server would then tell the client the offset position relative to their current maps top left vs 0,0 so the client can put them at the correct position), or the multiplayer plugin needs to somehow support different players being on different layouts.

layouts as levels.

a sprite somewhere, which is the entrance to the cave, .. upon overlaps, set room name cave_layout, autojoin room.

Another player pops over the sprite, room name set to cave, and pops in the cave as well joining whoever joined it first.

Would not require a server, just a player indicating an available room.

Say you want to make it a quest requiring 2 players ..

player overlapping cave sprite entrance, set boolean on cave entrance

pick players cave entrace boolean true

picked count = 2

for each player boolean cave entrance is true send tag entercave message "caveroomname"

on message received "entercave", set room name to multiplayer.message, autojoin room

voila 2 man enter for quest

lennart I don't want to have multiple tabs open OR have palyers acting as the server in any way at all. The game isn't specifically for 2 people either. I don't know how many people will be in the game and what maps they will be on.

lennart I don't want to have multiple tabs open OR have palyers acting as the server in any way at all. The game isn't specifically for 2 people either. I don't know how many people will be in the game and what maps they will be on.

Even if you have a server running a single tab in a browser ... isnt it capped with connections ?

I believe the browser has 256 soft cap on connections, not sure how it is with webrtc.

I am guessing is that if you want to have a single server running something as host, you will have game instances around that number per window.

I think the smartest approach with this is to have to have players act as a host for a rooms where other peers can join.

Thats how the mechanic of the current plug in is set up and works fine.

You can toy around with instance names and room names and find nice ways to manipulate them to simulate some sort of world with entries and exits everywhere leading you to another layout where you automatically join existing rooms or create on one the fly.

Wait, my players have to be *on the same layout*? This is a huge, huge problem.

My plan for multiplayer (a zelda-y world that players can move freely around in) was:

-Every screen of the world is a separate layout (makes life easy in a number of ways)

-Players only sync data with other players in the same layout as them (so if you're the only player in a given layout, you're not syncing with anyone)

-Global world variables (is it day or night? Are there orcs attacking the castle?) sync globally once every five seconds (for low bandwidth consumption)

This seems like it would be low data while still allowing the feeling of a 'permanent' world (with most things including character save data handled by the client, at least at first, I'm not a professional operation I don't feel the need to move everything server-side).

But according to what you're saying, this extremely simple vision would be impossible?!

Ugh.

Televangelist yep, pretty much. I think I'm just going to switch over to a grid based movement system (think FF1), and not require any actual collisions in C2, just grid based collisions which will allow all players to be in their own layout with a relative position of their own map. It's the best I can do with what I have.

Wait, my players have to be *on the same layout*? This is a huge, huge problem.

My plan for multiplayer (a zelda-y world that players can move freely around in) was:

-Every screen of the world is a separate layout (makes life easy in a number of ways)

-Players only sync data with other players in the same layout as them (so if you're the only player in a given layout, you're not syncing with anyone)

-Global world variables (is it day or night? Are there orcs attacking the castle?) sync globally once every five seconds (for low bandwidth consumption)

This seems like it would be low data while still allowing the feeling of a 'permanent' world (with most things including character save data handled by the client, at least at first, I'm not a professional operation I don't feel the need to move everything server-side).

But according to what you're saying, this extremely simple vision would be impossible?!

Ugh.

No your players do not have to be on the same layout.

As long as you do not want a single host determining everything, you should be in the clear.

ATM it is like, every single layout, requires at least 1 host. Be it peer or a 'super host'

—, how about writing up your own javascript version of the server side, and use node.js with the web RTC module to communicate with the peers ?

That should be definitely possible, and , if your any good at programming, you can make the host run without the need of a browser.

You would just have to write up the host side of things in a code only set up. Tough, do-able though.

> Wait, my players have to be *on the same layout*? This is a huge, huge problem.

>

> My plan for multiplayer (a zelda-y world that players can move freely around in) was:

>

> -Every screen of the world is a separate layout (makes life easy in a number of ways)

>

> -Players only sync data with other players in the same layout as them (so if you're the only player in a given layout, you're not syncing with anyone)

>

> -Global world variables (is it day or night? Are there orcs attacking the castle?) sync globally once every five seconds (for low bandwidth consumption)

>

> This seems like it would be low data while still allowing the feeling of a 'permanent' world (with most things including character save data handled by the client, at least at first, I'm not a professional operation I don't feel the need to move everything server-side).

>

> But according to what you're saying, this extremely simple vision would be impossible?!

>

> Ugh.

>

No your players do not have to be on the same layout.

As long as you do not want a single host determining everything, you should be in the clear.

ATM it is like, every single layout, requires at least 1 host. Be it peer or a 'super host'

Ah, okay! So could I do it like this?

No super hosts; whenever a player moves into a layout, that player becomes the 'peer host' of that layout, and anyone else who enters the layout will enter the peer host's version.

So when a player enters the "Dangerous Cave" layout, the game pings the signaling server to see if anyone else is currently hosting the 'dangerous cave' layout, and if so it connects them, and if not that player becomes the first 'peer host' of the 'dangerous cave' layout. That will work?

And then for syncing global variables, I could use WebKit or something like that for syncing the global variables from a simple data file I host on a server somewhere? So, for example, if the world has a day/night cycle, that will sync up across all players playing the game through a separate mechanism than the multiplayer object?

Televangelist yep, pretty much. I think I'm just going to switch over to a grid based movement system (think FF1), and not require any actual collisions in C2, just grid based collisions which will allow all players to be in their own layout with a relative position of their own map. It's the best I can do with what I have.

Is there a good guide to implementing grid-movement collisions somewhere? This was something I was having trouble implementing in my grid-based movement system... assume there's some way of doing it simply/elegantly that I missed.