Refactor Multiplayer Networking Logic

[zaphodb2002]

This issue will serve as the overview of a complete rework of the networking logic. See #140 for the long saga of me learning how to do any of this.

What I'd really like to do is to strip down the multiplayer stuff to be as simple as possible. I spend a lot of time refactoring things into separate nodes and that might not be serving me well here. Simplify, and add lightness.

[zaphodb2002]

Alright, let's see what we can do as far as a game plan.

Here's the two official examples from godot:

Pong Bomber

Here's a plugin that attempts to handle the multiplayer in a way that is very similar to what I've been trying to do:

Multiplay Core

Let's start with the official examples and see if we can succinctly understand and communicate how it works.

[zaphodb2002]

Pong

No Autoloads Lobby scene is loaded first lobby.gd extends Control, handles connection logic

lobby.gd

_ready() :

• called when all children have initialized
• connects to multiplayer signals

  callback _player_connected(_id) on multiplayer.peer_connected

• called on each peer with the new peer id and the new peer multiple times, once with each other peer's id
• instantiates the game scene and adds it to the tree, starting the game

  callback _player_disconnected(_id) on multiplayer.peer_connected

• called on each remaining peer with the disconnected peer's id
• calls _end_game()

  callback _on_host_pressed()

• called when user clicks the host button
• creates and sets the multiplayer peer

  callback _on_join_pressed()

• called when user clicks the join button
• connects to a remote peer

  callback _on_find_public_ip_pressed()

• called when user clicks the find public ip button
• calls OS.shell_open("https://icanhazip.com"), which is something I need for the social links.

  pong.gd

  contains game logic

  _ready()

• called when all children are initialized
• sets the multiplayer authority of the players

  update_score() @rpc("any_peer", "call_local")

• handles score logic and win/lose conditions
• if game_ended, calls stop.rpc() on the $Ball

  ball.gd

  the ball object script

  _process()

• called every frame
• to check for the ball making a score, we have to check the multiplayer authority and only update if it's the authority's goal
• when that does happen, we call update_score.rpc() on the parent, which is the Pong node, and also calls _reset_ball.rpc()

bounce() @rpc("any_peer", "call_local")

• both players can cause bounce so called as rpc, nothing else mp specific in the body

  stop() @rpc("any_peer", "call_local")

• same as above, if both players can stop the ball, no need for mp specifics

  _reset_ball() @rpc("any_peer", "call_local")

• again, nothing special here

paddle.gd

This is the player logic for the paddle object, handles input and movement

Exports

player number

_process()

• called every frame
• input checks for mp authority, and if true, will change the velocity of the object with set_pos_and_motion.rpc()
• regardless of mp authority, translate() is called to move the object

set_pos_and_motion() @rpc("unreliable")

• runs only on the server because not "any_peer"
• is unreliable because we don't care about anything that was slow to arrive
• doesn't run on the local peer either, so is JUST server action

_on_paddle_area_enter()

• called when the ball hits the paddle
• checks mp auth to see if it's my paddle, and if so, bounce.rpc() on that colliding ball.

[zaphodb2002]

Thoughts:

This solution does not use MultiplayerSpawner or MultiplayerSynchronizer nodes. This surprises me because I thought that's how we're supposed to be doing it now. There was a blog post I was working off of in #140, I gotta go find that and compare. It's entirely likely that this example wasn't really redone for 4.0 paradigms, just updated to work.

[zaphodb2002]

Bomber

Okay good, this one uses the node based solution.

Autoloads

• gamestate.gd

gamestate.gd

This is the global object for the state of the game. Handles mp connectivity stuff like lobby.gd did in the Pong example, but here it's more elegantly abstracted. There is a player list that requires registering and unregistering the players. Also manages starting and ending the game.

callback _player_connected(id)

• called from the SceneTree when a player connects
• calls register_player.rpc_id(id, param), which is calling it on the player that just connected, basically a confirmation/update

register_player() @rpc("any_peer")

• NOT call_local so only runs on server
• IS any_peer so any client can call it
• uses multiplayer.get_remote_sender_id() to save id as key

host_game()

• creates a new server

join_game()

• joins the server

begin_game()

• asserts that this is only on the server
• calls load_world.rpc() because we want this to happen on all clients

load_world() @rpc("call_local"):

• can only be called by the server, but does run on all clients
• instantiates world.tscn and adds it to the SceneTree
• unpauses the scene tree. I need to look at this a bit more, I see it used a bunch. What exactly is getting paused here?

lobby.gd

This handles just the UI management, and outsources the actual mp work to the gamestate via gamestate.host_game() or gamestate.join_game() and receiving signals from said gamestate when its status changes. There is literally no MP specific code in here.

player.gd

player logic, extends CharacterBody2D scene contains a child MPSync node, which is configured to replicate player:synced_position scene also contains a Node with player_controls.gd attached and another MPSync node below that for handling input authority

Exports

synced_position: Vector2 stunned: bool

_ready():

• using the name of the player node (which should be the mp id) , we set the child Inputs/InputsSync node's authority

_physics_process()

• if the local mp id matches the name of this node, that's us and we want to call inputs.update()
• if the local mp is the authority, we set synced_position to the current position
• if we want to do something (in this case poopin' out a bomb) we need to verify the multiplayer authority, because if you don't all players will do it when one presses the button
• if we want to spawn something in, as we do with this example, we also need to spawn things via an MPSpawner node. In this case, that node is on the world scene, which makes sense.

[zaphodb2002]

Thoughts:

This is much more in line with what I want to do. I think probably what we should do is scrap and replace what we have. I can bring over what I can but we need to really reduce the garbage here.

[zaphodb2002]

I've spent some time creating a new GameState autoload like what the Bomber example has. Going to require quite a bit of changes.

[zaphodb2002]

Okay, I think we're pretty much there. As it stands, the player list is getting populated correctly, the authority is getting set correctly (thanks to the MultiplayerSpawner.spawn_function callable) and it is syncing the requested info back and forth. Now we need to rework the UI.