Throughout the entire development of RBG, I’ve tried hard to maintain at least a semi-consistent work schedule. However, this next update has proved to be a genuine hurdle for me to cross; the hardest challenge this project has thrown out me thus far.
The day I implemented the multiplayer menu was an interesting say for development. Everything was going well! There weren’t major bugs, the IP masking (unity relay) and lobby system was working, I was on top of the world! Things took a turn for the worse the second that menu was added.
I wanted to make it to where the join code and buttons weren’t constantly on your screen, and actually interactable. This is when I came up with the idea of a menu that you could open that would allow you to view join codes, send it to people, and etc. In it of itself, a rather simple thing to implement. Got the menu working just fine… but then came the issue of host VS client control…
I want the HOST to be the one to send join codes to people, just to avoid issues with join consistency. Additionally, if we ever play this game on stream—it would be hell to have to invite people, you could never open the menu… it’d just be easier to have that be the host’s job. What else do I want only the host be able to do? Okay, so the client can join a server and disconnect from a server. The host on the other hand, can kick players (Let’s say you hate your friends, or more realistically encounter issues where someone leaves their game open when they leave, causing you to be unable to start games), AND delete lobbies (to re-host)… You can imagine this was hell to implement, but by the end of the day I SURPRISINGLY actually got it to slightly function. (See my last (significantly more optimistic) post!!). The host could manage players, and redo lobbies.
It was great. But, in game development, one step forward always means 2 steps back.
The bugs infested everything! Every script was showing warnings, and the game was so choppy. This catches us up to… yesterday actually…
- If the player joined a lobby that existed but no longer exists (after a host terminated it), they’d be stuck on a static scene with no UI or way to escape.
- If a host opened the menu to invite a player and then another player joined, the host would be stuck on the multiplayer menu and could no longer close it.
- If the player started joining a lobby and then created one, the player would be stuck in limbo between scenes. (No UI or way to escape).
Overall some pretty groundbreaking errors that were such a headache to fix. However, today (pretty much) I got them fixed. But now I’m left with just a few bugs that have remained pretty persistent throughout the multiplayer experience.
- Players no longer can be stuck in limbo menus. A clientside coroutine tracks whether or not a player is committing to an action whenever they join/create a server. If this action stalls out or runs into a conflict, after 25 seconds if the player is not instantiated (also helps mitigate shitty internet) it will send the player back to the og server menu.
- Fixed the multiplayer menu issue for hosts, just was due to the fact that I was trying to make the client side menu be networked across servers as an OBJECT > DEPLOYABLE. 😞
- NEW BUG where the player list does not work. Just displays as thin lines… you can however kick players as a host if you click the farrrrr right pixels of the list.
- OLD BUG where when the game is deployed to the public, the player’s look system will be SHELLSHOCKINGLY choppy. I think this is also due to me trying to network confirm the look system, which could mean that it’s constantly trying to approve a look with the server hundreds of times per second… Will fix today if possible!
Long post. Wow! Thanks for checking in. DM me or ping me in la discordia if you’re ever interested to learn more. See ya around, this was Lua, checking out.
-Lua