Peer "ghost" in multiplayer when changing/resetting layouts

Discussion and feedback on Construct 2

Post » Fri Jun 26, 2015 4:00 pm

Hi all !

I've been encountering a small glitch in multiplayer when changing/resetting layouts ; basically, peers positions' still seem to interpolate between the old position and the new one (before/after changing layout), and peers also leave a "ghost" (multiple instances of the peer's player object bound to the same peerID)

Surely it's got something to do with the way I use Multiplayer.Associate(peerID), or some assumptions about the layout transitioning logic I don't fully understand (my guess is that all objects should be wiped clean and re-create, but are they...?)

Bottomline question : what happens to synced objects during layout transitions ? What are the best practices in terms of object creation/destruction and peer association to deal with layout transitions ?

I have re-created a "small" .capx example demonstrating the problem (nothing is really "small" with multiplayer, even if C2 makes it easy, but it's as minimal as I could make it) : 2+ players (blue squares) need to collect all the collectables (yellow squares), upon completion the layout is restarted (hosts restarts and broadcasts a "restarts" message to peers)
.capx : https://db.tt/4X0NpqRh
video : https://db.tt/5qaa0ktJ

4 layouts to deal with the front-end and 4 stages of multiplayer setup : menu (checks for multiplayer support), login (player id), matchmaking (room id), and lobby (multiplayer set up, waiting for all players to be "ready")
1 dummy layout containing prototypes of all entities
1 actual "game" layout where the collection / restart logic is
WASD to move

Any suggestion would be greatly appreciated :D Thanks !
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Fri Jun 26, 2015 4:38 pm

How about making the peer objects global ?, and destroy them when a player leaves/disconnects, and hide the peer in menu screens. (if needed)


Solves a lot of creation issues :)
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,592

Post » Fri Jun 26, 2015 5:10 pm

Interesting ! That would make peer objects persist across layouts, giving me full control of their life cycle (created by the host, destroyed when players disconnect as you said). That should remove the destroy/re-create question altogether. Thanks :)

I'll investigate that ! Though I'm still curious about what actually happens to synced objects when changing layout :-?
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Fri Jun 26, 2015 5:14 pm

There is a moment of layout transition on 2 parties, happening at different moments. (host side/peer side)

You could have solved the issued performing a check if the object you are about to create already exists.

pick all peer
pick peer by evaluate peerid = peeridat(loopindex)
else
create peer
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,592

Post » Fri Jun 26, 2015 5:18 pm

Ahaaah ! Great, thank you very much, I will be experimenting with all this !
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238


Return to Construct 2 General

Who is online

Users browsing this forum: Peticha and 10 guests