0 Favourites

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.

  • [quote:3u9whxkx]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.

    This is basically what I was told. Multiple layouts/server-tabs for each map. I don't see why there would be any issues with either custom maps or performance issues.

    If you really need a way to transfer player states/data, you can use the Websocket plugin and make yourself a simple server to handle it. ... Well, simple on paper, anyway.

    But yeah, I think that passing states around is really the only unhandled issue here, as well as dictating exactly what map should be opened (but again, custom maps shouldn't be an issue in theory - just save the state of a layout and then transfer that to a new tab).

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • DatapawWolf 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

  • Just to bump this up, now that I'm getting deeper into the plugin I'm sorta apprehensive about how to start handling multiple layouts. It would be absolutely amazing to be able to export a project with the ability to have one central "server" process/executable that handles multiple specified layouts, without having to create many tabs/instances. Then I believe we could just use the already built-in persistence to transfer each peer/player object between layouts.

    After that, specifying which layout is the "GUI," so to speak, so that we could actually have somewhere to manage players; something that is presented to the Administrator of the server machine.

    Honestly, I'm starting to think that creating an online game using a (dedicated) server-peers relationship will be improbable unless we have the ability to export a project with the above Multiplayer-specific functions.

    @EncryptedCow do you see any way to accomplish this? Has anyone ever managed something similar? lennaert Everade, any more ideas to brainstorm with? In researching the discussion on multiplayer functionality I see your names mentioned a lot. : )

    I do see it emulatable by using - like I think you suggested, EncryptedCow - creating a gigantic layout. Almost like how, I believe Jagex Runescape (used to?) manage their giant world (for instance, clever players abused bugs to teleport themselves into restricted cutscene areas because these areas were simply X and Y distance away on the giant server layout). But then again, we would need extended Multiplayer functions such as specifying under what maximum distance should objects be sync'd to each client, and (probably more optional than required) the maximum number of client objects that can be sync'd (to prevent the server from trying to sync a needlessly large number of players at once)

    Maybe we can make a special request through Ashley to work on the first export feature if possible, unless there is someone else who has the know-how to achieve this.

  • Datapwolf 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.

  • I don't think that i can help in this case, as my project does not require either huge layouts nor multiple ones.

    My game is designed so that players "during one round" will only be playing on one single (medium~big size) map.

    So ones the next round starts, i will be able to load a complete new layout rather than being forced to load a new layout during gameplay itself.

    Just make sure that the Host handles everything that's important, so peers are not able to cheat.

    So check inputs by peers, but never let peers handle damage execution etc...

    With that Peers should never be able to cheat themselfs to a new location even if you're using a huge ass map.

    As long as only INPUT by the peer is given, there's no chance for any peer to actually cheat. Since the host handles their actual position on the map

    That's more or less the most important rule when it comes to multiplayer design.

    That's why in shooters you might still get killed even if you're already far behind a wall. Because the host handles the damage with using a prediction were the player's position was during the time the peer pulled the trigger.

  • 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.

  • lennaert thanks for the suggestions but I am on the same page with EncryptedCow, I have determined that to make my game project work efficiently, and without all sorts of attempts at circumventing some of the current limitations, I will need to have the ability to manage multiple layouts simultaneously either in export, behavior, or some other feature that enables 1 server, X clients, and Y layouts/maps/rooms.

    I understand the limitations, and for one, there are many successful games that don't have a whole ton of concurrent players (take games like Realm of the Mad God for example. Their servers do not usually host many people). I honestly do not expect to have that many concurrent players, and even if I do, that is what having multiple servers is for, like Runescape, Maplestory, AdventureQuest Worlds, Realm of the Mad God, & etc. Or if I do need to support more than 256, then I'd be happy using your suggestions to send players between server instances rather than trying to stuff everyone inside one.

    But until then, for sure to make this work efficiently and cleanly, I will need to have the option of managing multiple separate areas through support from Scirra in Construct 2.

    I have sent Ashley an email asking more about this subject, and I hope to gain more insight into the possibilities.

    In my email I also pointed this out: adding a feature that directly supports the creation of traditional MOGs would be an excellent selling point. There are other products out there that do support online multiplayer games through the web, however, none of them are straightforward, many of them have some sort of licenses more associated with business-class development, and none of them have the same level of simple development that Construct 2 has as an entire IDE. There are many users who would love this engine if the support were right out of the box.

    And I would gladly create tutorials and guides on how to start developing an MOG were we to see a feature like this since it would make development that much more straightforward. I understand, Lennaert, the concepts you've brought up, but I think just the fact that they are more hoops to jump through creates issues and winds up much more of a deterrent, especially to potential customers.

    On a side note, in the long run, you do not want any data to be passed off to a client machine in, say an MMORPG. People will learn to exploit even the smallest bit of information, which is why I will not develop in that way unless I take the whole "server" right out of the equation and develop a Multiplayer game more like Dark Souls than, say, Runescape.

    In that case, yeah, heck a DS-like game would be fun! But that is not what I am developing.

  • 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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)