[SOLVED]Change Scene in a multiplayer game (selection character screen)

Hi again guys!
I’m sorry to bother again but I’m quite stuck! I’ve looked on the forum and on the internet for some help but couldn’t find anything.
I’m trying to add a selection character screen for my multiplayer game and I can’t do it.
For the moment, I’ve added it right after the lobby screen : instead of changing the scene to the main game, it changes the scene to the character selection.

For the moment, it looks like that :

I thought I would be clever by declaring a few global variables : P1_ready, P2_ready, P3_ready, etc (a boolean which turns true when the Player clicked on one of the button “RedShip” or “BlueShip”).

And I added a “Start the Game” which is supposed to change the scene to the main game.
I’ve messed with the code quite a lot so I removed all the things that cluttered the code for you guys and left only a few events.
I think there is a problem of ownership but I don’t really understand how to solve it.

So a few questions :
Are my conditions “The current player number in the lobby = X” correct at that point (after the lobby!)?
Do the players need to “own” the global variables P1_Ready, etc?

In the only other thread I found about this subject, the OP was given the advice to NOT change the scene but to create it in the main game in a remote place and “teleport” the characters there. Do you think I should do that?

Well, thanks for reading anyway!

If it can help : when I click the RedShip button on the Host, the debug message Debug_Ready is displayed on both screens and stays there but when I click on the RedShip button on the peer, the Debug_Ready shows for a second on the peer’s screen and disappears…That’s why I think it is a problem of ownership but I’m not sure!

OK…Sorry to have bothered you but I solved the issue…That’s the second time I do that : create a topic to solve the issue just after…I think writing the problem helps my thoughts process!
Anyway, here are my corrected events for those that may be interested :

2 Likes

Hi there!
New day, new tests!
My method DOES NOT work : it is flawed. A third player can not join the game. Well, they can but they won’t have a character to move around with.
So, I’m guessing that the chain of events : Joining the Lobby → choosing a character → going to main game is not a good strategy.
And now that I come to think of it, it reminds me of Mass Effect 3 Multiplayer (which I have played A LOT) : the player was asked to choose a character and then they could go join a game…
So, from here, I can imagine 2 solutions : Choosing the character → Joining a lobby → start main game
OR as was suggested in another thread (on reddit I think), placing the Character Selection Screen far away from the action and teleporting the characters…

I fully realise this is a long monologue but it may help someone in the future, perhaps…But if you have any suggestions or ideas, don’t hesitate!

Thanks!

Hi again!
Well, just to put an end to this thread and stop bothering you with what looks like my own personal devlog :sweat_smile:, here is what I have come up with.
As for now and after some testing it seems to work the way I wanted it to. I don’t know if it’s the most elegant solution there is but there you have it :
I made use of the Layer system of Gdevelop.
In my main scene, I’ve set my buttons to choose the different characters and when it’s clicked, the character is created, the buttons for the characters are disabled and the Layer hidden. As I work with multiplayer, I’ve given the authority (ownership) to the multiplayer::CurrentPlayerNumber!
Here is a snippet of the code if that is of interest to someone :

Cheers!

I like your thread. I have not been able to help as I have only made a character selection screen before the players choose to join a multiplayer game, which then saves the character skin/stats info to a non synchronized variable, which then when they join the lobby will create their character. So I had no relevant experience to help with what you were requesting in the beginning of the thread. Also December is a very busy time of year for me, so I did not have time to quickly try to make a character selection screen after joining a game and see what issues I ran into. But just wanted to let you know even if you are the only one posting solutions and issues in your thread, the information can be valuable to others so don’t be shy about it.

1 Like

Hey! Thanks for your reply!
Yeah, that’s true : December is a very busy month indeed!
Well, although my method has worked so far, I’m actually struggling with the cameras : I can’t get to deactivate the Smooth Camera behavior synchronisation and I’m wondering if the issue is not rooted in how my characters are spawn/created.
Or rather : who creates the characters.
I run into very weird bugs when I try to control the the Smooth Camera Behaviour. For example : the camera of Player2 follows Player1 and vice-versa.
I tried to follow the “official” tutorial here : multiplayer gdevelop camera - Google Search but a noticeable difference with my project is that the characters in the tutorial are already placed in the scene and they “belong” to the host untill the code says otherwise.
As for my project, each peer creates his character and thus, they should belong to that peer on creation (well, I think that’s how things work!) EDIT : No that is wrong I think!!
I thought this might be easier to work with (less ownership to manage?) but I’m suspecting it’s doing weird things…
As a conclusion, I think I need to have a look and a good thought at the method you used and try to replicate this chain : Character Selection → Lobby → main game
OR
carry on with my method and maybe drop the Smooth Camera behavior and manage the camera in the code (which I haven’t tried yet!). But If the character creation method creates weirdness, I’m afraid I’ll run into troubles later on!

Well, thanks again for sharing your method and replying to this stream of thoughts! :wink:

Another thought : I’d really like to make it work this way :
Lobby → Character Selection → Game
for one specific reason : when the game ends, the players wouldn’t have to change/go back to the lobby screen and could start another game with another character if they so choose with the same human players.

Also : I re-re-read the documentation here : GDevelop Multiplayer - GDevelop documentation and specifically this passage :

  • When a player creates an object, to define who is in charge of the object. For instance, when a player throws a bomb, the bomb will be owned by the player, so you can use this action with the Player number expression.

From what I can read, when an object is created by a player, the ownership of that object is given to the player defined in the Multiplayer Behaviour and then the player must take ownership if necessary.

So, I guess the same applies to the creation of the players themselves. As a consequence, if no change has been made in the Multiplayer Behaviour as to the ownership, the characters belong to the host until the code states otherwise.

Another note :
After some research on the forum, I stumbled on this thread : (SOLVED) Online Multiplayer Smooth Camera Bug
Where the behavior Smooth Camera seems to be causing some difficulties…
So maybe my problem has nothing to do with the Creation of the characters!
So, I’ll try managing the camera manually, without the behavior to see what happens!

(I deleted the next post by accident so I put it back here) :

EDIT : Yeah, removing the behavior for Smooth Camera and managing of the camera with a lerpas suggested by @MrMen is that thread above made the trick! So, for now (and I hope forever), the creation of the characters can be made after joining a lobby! We’ll see what other troubles that brings me :sweat_smile: :smiley: Thanks for reading guys!

The Smooth Camera behavior is brilliant at what it does, but I could never get it to pick correctly when installed on multiplayer objects, at least in my concept - in which one multiplayer object is created by each player after joining the lobby.

I found it far simpler to install the behavior on a non-multiplayer object called Camera, have each player make their own Camera when they join the game or have the Camera in the scene already, position it to their Char, and stick it with the Sticker behavior. Then there is never any confusion from Smooth Camera behavior about which Camera its behavior is supposed to be activated on, because there is literally only one Camera in each player’s game.

Although I too have recently read the solution by MrMen that you link to in a later post and I think that solution may offer better performance if you do not need any of the additional functionality included in the Smooth Camera extension.

Good to hear, you have to do what makes sense for your game.

1 Like

That is brilliant! I would NEVER have thought of that! I’ll keep that in mind! Thanks for sharing! :wink: