Hi @hardik_sl,
You may modify the requestJoin method to allow creating the room regardless of the param create is being passed as true or not. I've made this example to demonstrate that clients may have control to create or join into rooms. By omitting the requestJoin method, it will always return true.
Hi @holyxiaoxin, it looks like this.broadcast() would be better on this case. Then the message is broadcasted instantly. You can retrieve the message using the room.onMessage signal from the client-side.
Also on a Unity based game with colyseus, is there any source to understand how to process every data that the server sends, it's a hell having to cast every parameter.
Hi @endel thanks for you quick reply, as you said... yeah.. too many issues already LOL
I'll go for the database option to persist the data between room changes, I'm working on it now, the idea is to save the player progress > leave the room > join the new room > re-authenticate the user with the data in the session and reload the progress.
I though it will be too expensive in terms of server response time, but keep a room or persist too much information in the presence could end up been even more expensive than just hit the DB to get the data.
Best,
Thanks for answers and recommendations. My aim was to avoid crashs due to the bugs I haven't discovered yet, or any undefined action client made that could make the whole server(all the other rooms) crash.
As an answer to @endel, errors that I have come across so far was thrown from timeout callback functions so putting try catch to onJoin might not help :) .
A colyseus + DB with authentication would be the ideal example IMO
something like the existing tic tac toe example with a simple user creation (DB) and login (authentication) would be enough
and it would be all someone needs to make a complete multiplayer game experience
