How to handle multiple layouts in Multiplayer

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'

DatapawWolf, 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.

EncryptedCow

DatapawWolf

You guys are simply going beyond the multiplayer behaviour capabilities of construct 2.

The official multiplayer system is a simple signaling server which connects players with each other, so one player will always be the host.

What you guys are talking about is a simple dedicated server, that's it.

So as long as you're not going to code a dedicated server, there's no way you're ever going to achieve what you're looking for.

From what i've read from Ashley so far... he's not really interested into further developing the multiplayer part.

It looked like he felt that the multiplayer feature was a complete waste of time, because there are not enough people actualy using it. (i'm just interpreting what i've read so far, but his words came pretty close to that) So according to that i would guess that he's not willing to help you in a dedicated server matter.

(i would love to get my hands on a dedicated server version as well)

The only way to prevent players to become host right now is, to run the "main game" on your own server.

What i mean is.... run the game itself on your own private dedicated windows server (for example) which will then always be the host.

That would prevent players to become host themselfs, and you could offer your players a dedicated bandwith.

But it's just a simple and bad workaround.

So either you're going with lennaerts suggestion, which is actually pretty good.

Or you're going to code your own dedicated server.

Using lennaerts suggestion would simply mean that creating an actual (dungeon) instance will just be a new player being abused as a new host.

This would save you an *** full of money rather than being forced to host a dedicated server.

Of course there's a big downside on that, as you would have to rely on the players internet connection/location.

But i'm sure you would be able to add some checks on the players connection to prevent such players to become a host.

If you're actually willing to go for a real MMORPG, just keep in mind that this will require a really fast and big database / a good dedicated server. MMORPGs require the most powerfull servers when it comes to gaming (compared to a shooter for example)

In short: it's expensive

EncryptedCow

DatapawWolf

You guys are simply going beyond the multiplayer behaviour capabilities of scirra.

The official multiplayer system is a simple signaling server which connects players with each other, so one player will always be the host.

What you guys are talking about is a simple dedicated server, that's it.

So as long as you're not going to code a dedicated server, there's no way you're ever going to achieve what you're looking for.

From what i've read from Ashley so far... he's not really interested into further developing the multiplayer part.

It looked like he felt that the multiplayer feature was a complete waste of time, because there are not enough people actualy using it. (i'm just interpreting what i've read so far, but his words came pretty close to that) So according to that i would guess that he's not willing to help you in a dedicated server matter.

(i would love to get my hands on a dedicated server version as well)

The only way to prevent players to become host right now is, to run the "main game" on your own server.

What i mean is.... run the game itself on your own private dedicated windows server (for example) which will then always be the host.

That would prevent players to become host themselfs, and you could offer your players a dedicated bandwith.

But it's just a simple and bad workaround.

So either you're going with lennaerts suggestion, which is actually pretty good.

Or you're going to code your own dedicated server.

Using lennaerts suggestion would simply mean that creating an actual (dungeon) instance will just be a new player being abused as a new host.

This would save you an *** full of money rather than being forced to host a dedicated server.

Of course there's a big downside on that, as you would have to rely on the players internet connection/location.

But i'm sure you would be able to add some checks on the players connection to prevent such players to become a host.

If you're actually willing to go for a real MMORPG, just keep in mind that this will require a really fast and big database / a good dedicated server. MMORPGs require the most powerfull servers when it comes to gaming (compared to a shooter for example)

In short: it's expensive

What a lot of us are aiming for is a multiplayer world without the 'massiveness' of MMORPGs -- you might have, for example, a cap of 50 people per server, movement in two dimensions (which is a lot less data being passed back and forth than a 3D MMO), inventories that are simpler and require less data storage than an MMO with, say, loot permutations (so an object in a player's inventory is simply recorded as "Item #263," which references local data on what all the items are, rather than all the special properties and permutations a modern MMO's 'Vorpal Sword +3 of Shadows' has undergone.

Multiplayer without persistence is boring and done to death. Who wants to play another competitive 2D arena game? But we're not trying to compete with the Big Boys here. We can do a form of persistent-world on the cheap.

As for a player potentially hosting with a poor connection, this is one more reason for me to split up every single screen of my Zelda-y multiplayer game into its own layout... if a screen is choppy because the first player to arrive on it is a poor web host, well, hop to any other screen and you'll be fine.

The one downside is that if players aren't 'connected' until they're on the same screen, how will I handle chat? That'll be tricky... Unless there's some way to have the chat box as a 'separate' multiplayer connection that I permanently host and have all players of the game as permanent peers... if that's impossible, though, text is simple enough that there's gotta be some weird Java-y way of handling it.

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?

Exactly !!

And for the mmorpg part of things ...

Use PHP /mysql back end with ajax.

I used it for my first version of tankwars (even the movement) and with a good approach in php you can make certain transaction safe enough, the vast majority of mmorpgs run on php/mysql

For the game side of things, it really livens things up ...

ie

mysql database having a table wit player info, and rooms/wordparts.

The player table should contain a reference to in which layout it resides atm. (current location)

Player starts app and ajax request ID info, if ID exists, send info from player etc.

If does not exist, create ID etc.

Now, if you move to another layout piece, simple ajax your way to the db and update player current location.

This will make you peers optionally available if they are offline too

Or, imagine sending someone a message ... store in DB, and when they come online, they check the db through ajax for messages.

I think the multiplayer plugin could improve a lot if Scirra added a syncing condition to it, for example if all players has a room instance variable you could make the peers only sync players/objects positions that has the same room value and the host would work more like a dedicated server, correct me if I'm wrong.

This doesn't sound like a huge request to me but I'm not sure how it's programmed in the backend. Would definitely help with this problem a lot though.

I think the multiplayer plugin could improve a lot if Scirra added a syncing condition to it, for example if all players has a room instance variable you could make the peers only sync players/objects positions that has the same room value and the host would work more like a dedicated server, correct me if I'm wrong.

This doesn't sound like a huge request to me but I'm not sure how it's programmed in the backend. Would definitely help with this problem a lot though.

Even if this would be a pretty small amount of work compared to what's already been done on implementing multiplayer, the problem is convincing Ashley that we (those of us who want to build worlds for players to inhabit) exist; because people aren't out there making Multiplayer 2D Arena shooters etc. with C2 right now, the impression he has is that multiplayer isn't really what people want to do.

Emy Televangelist Yup, the primary issue is convincing Ashley. I have had no luck in my emails, but I'm still optimistic that if we can show him that we could, in fact, greatly use this potential feature, he might give in. But until then, I will most likely have to shave my project's scope since I cannot wait any longer for such important features to be implemented.

I think a lot of people would be willing to use the multiplayer plugin more if it wasn't so complicated to create a dedicated server with it, I think that's what most of us want to use the plugin for anyway to be honest. Using tabs or having all rooms on the same layout is not reliable at all or a waste of memory.

I hope Ashley are willing to add this in the future because I really like the multiplayer plugin.

Emy those are my exact thoughts on the subject. I can even imagine that many of those who voted originally for multiplayer wanted to be able to make precisely what we are asking for, not peer-to-peer tech limited to mostly tools and noncompetitive gameplay; because that is what we currently have.

One can only hope we get this feature, or if someone familiar with the engine can craft an export suitable for this kind of project, that would be just as well.

Construct 3 dreams, perhaps?

Wait so if my host can handle 200 or 400 objects on a large layout and then my peer gets laggy there is no way for me to let the host continue to do so but without bogging down the peer with syncing info on far away objects.

All I wanted to do was find away to be like

if object is within 500 pixels of peer then sync object

else don't sync object

But my guess and after reading this it appears this wont work or would be buggy and would stop syncing to all peers or something.

We need to start an open source project for a C2 centralized web socket plugin...