Multiplayer improvement requests

I'm sure Ashley already has an agenda for the Multiplayer feature, but I thought i'd weigh in after having made a few different multiplayer game prototypes as to what features I would find really useful:

* Lobby system. The room system is awesome, but without a room listing system it's pretty hard to help players join each other.

* Sync text instance variable. With the Peer ID being a string instead of a number, I have no way to properly attach the Peer ID on objects created and synced from the host, and have that PID synced to the clients. It's been very problematic for when clients need to know who "owns" a particular object. This is especially a problem as UID's are not the same between host/client. As a workaround I can assign and sync the host UID as an instance variable and use messaging to pass the Peer ID assignment, but this is pretty hacky.

* On Instance Variable Sync Change event. When the instance variable of an object is synced and an actual change to the instance variable is synced to the client, I'd really like for the client to know about it without me constantly polling. For example I often use multiple frames in an object as states rather than animations and if the animation frame changes on the host, there's no way to sync that change over to the client other than a peer message (see the above point for the object uid issues that come along with that...) or having the client check the instance variable for a specific value EVERY TICK. With that sync event I could simply update the animation frame from an aframe instance variable anytime (and only when) it changes.

* A good solution to the rubber banding effect you can get when performing extreme position changes to sync'd peer objects. This happens when a player dies and moves back to the start position, as well as when using the layout Wrap behavior (which I badly want to use in a game).

Nice job fixing the issue with Scroll To. My solution has been to use a single pinned object with Scroll To and attach it to YOUR peer, but that sometimes creates a weird jittery effect since the pinned object can struggle to keep up.

Those are the main things I've really felt were needed. Other than that, the multiplayer feature is an amazing game changer and totally worth the wait. You are amazing Ashley!

If anyone has any good suggestions/solutions to the above, I'd love to hear em!

mzo

You might want to actually study the Plugin before making requests.

* You can get a Room list already.

* PeerID are synced between player connections.

* Vars don't need auto syncing. When a client updates a var. Client sends a message. Host broadcasts the update. it's the point of custom messages. The purpose of syncing was to handle latency not tell you how your game works. Just remember when when the Host.Broadcast to also include the FromId. Then just get the trigger from the incoming message and update.... no polling required. if your polling your not doing it right.

* As for rubber banding. that's a good point in regards for teleport. But that's an easy fix. Once again we will use the magic mystical function called

SendMessage("teleport", "player.x, player.y").

OnMessage ("Teleport") then compare Player.peerID = Multiplayer.fromID; player.setPosition(Multiplayer.Message do some to get XY

Maybe try a simpler game rather than jumping into the large hurdle of multiplayer game developement. The plugin only job is to provide singnalling, room, positional latency, messaging. All network gaming situations can be handled with messaging.

While I appreciate your reply, I think you misunderstood some aspects and your patronizing tone is less than helpful.

[quote:2vngnzy1]* You can get a Room list already.

Where? I see actions and values for INSTANCE lists, but nothing regarding rooms. If i've missed an available action I would love a pointer in the right direction on that as there isn't a manual entry yet and I see no mention of it in the 3 tutorials provided...

[quote:2vngnzy1]* PeerID are synced between player connections.

What does that mean? I know all clients are aware of all PeerID's as well as which are there own, but that doesn't help my situation.

To better illustrate WHY I wanted that feature let me explain the sitation:

1) A player places a booby trap on the host (via input sending of the Z key). To make sure the player can see that trap, the booby trap object is set to sync position so it will be auto-created on all clients.

2) Only the player who placed the trap should see it, but it needs to also exist on the host so the host can detect player collisions with it authoritatively. If the trap had a synced PeerID instance variable on it, it would be very easy to determine which trap objects should be visible or not.

I ended up working around this by sending a multiplayer message to the specific player client to place a trap object at his location. This presents a new problem as when the host destroys the trap via triggering it, how do I reliably tell the client who placed it to destroy that specific object instance? I can't use object UID's as those differ between host and client.

[quote:2vngnzy1]* Vars don't need auto syncing.

See the above problem. If I want to broadcast a message that an instance variable of instance #5 has changed, how do I make sure the same instance is changed on host and all clients without any consistent UID? The auto-syncing handles this for me. I'm not saying I can't work around this, but it's much hackier and I imagine Ashley's syncing functions are more reliable and efficient than my manual ones would be.

[quote:2vngnzy1]* As for rubber banding. that's a good point in regards for teleport. But that's an easy fix.

While I agree with your premise, the specific context is local input prediction combined with the wrap behavior. Especially when the local input prediction is combined with object acceleration. In this case I have flying airplanes, but you could get the same issue with a multiplayer version of asteroids.

You can try a slightly older buggier version of both games here to better understand:

http://microwebdiner.com/carnage2/

http://microwebdiner.com/traps2/

The point of the plugin is to provide user friendly multiplayer features. If I wanted to do things the harder way I wouldn't be using Construct 2 in the first place would I? There's no shame in ASKING for features, I'm not demanding them.

Room listing and teleporting without interpolating are definitely necessary, but you don't need to sync peer IDs - if you are trying you're doing it wrong, you should be able to always assign them upon 'On created' as shown in the third multiplayer tutorial. Also variable change triggers are not really the responsibility of the Multiplayer plugin, polling is the best way to check this. (It's been requested before to fire a trigger when a variable changes, but this would have a big performance overhead on the entire engine.)

Well. I'm going to offer good luck to your project and have fun in development

Ashley

Thanks for the reply. I think maybe I was unclear on the PeerID's thing as I am not talking about assigning PeerID's to Peer objects, but rather to "bombs" that were placed by specific PeerID's which are created on the host and sync'd via Sync Object (position, low nearly static). I'll go ahead and use my workaround for dealing with the related UID issue though. The point was just to show why I have use for syncing non-numerical instance variables

On the variable sync'd event, I figured you had some function that knew when it was updating a variable as the result of a multiplayer sync rather than just a variable change itself, which seemed like it would be lower overhead than polling. I'll just poll as long as that's decently efficient.

Thanks again for such an awesome feature!