Многопользовательский режим высокого уровня

Программный интерфейс (API) высокого уровня против низкого уровня

Ниже объясняются различия между высоко- и низкоуровневых сетей в Godot, а также некоторые базовые основы. Если вы хотите перейти сразу к делу и добавить сеть в свои первые узлы, перейдите к разделу Инициализация сети ниже. Но не забудьте прочитать остальные разделы позже!

Godot always supported standard low-level networking via UDP, TCP and some higher level protocols such as SSL and HTTP. These protocols are flexible and can be used for almost anything. However, using them to synchronize game state manually can be a large amount of work. Sometimes that work can’t be avoided or is worth it, for example when working with a custom server implementation on the backend. But in most cases, it’s worthwhile to consider Godot’s high-level networking API, which sacrifices some of the fine-grained control of low-level networking for greater ease of use.

Это связано с присущими ему ограничениями протоколов низкого уровня:

  • TCP гарантирует, что пакеты всегда будут поступать надежно и в правильном порядке, но задержка обычно выше из-за исправления ошибок. Это также довольно сложный протокол, потому что он понимает, что такое «соединение», и оптимизируется для целей, которые часто не подходят для приложений, таких как многопользовательские игры. Пакеты буферизуются для отправки большими партиями, что снижает накладные расходы на пакеты для увеличения задержки. Это может быть полезно для таких вещей, как HTTP, но обычно не для игр. Некоторые из них можно настроить и отключить (например, отключив «алгоритм Nagle» для TCP-подключения).
  • UDP is a simpler protocol, which only sends packets (and has no concept of a «connection»). No error correction makes it pretty quick (low latency), but packets may be lost along the way or received in the wrong order. Added to that, the MTU (maximum packet size) for UDP is generally low (only a few hundred bytes), so transmitting larger packets means splitting them, reorganizing them and retrying if a part fails.

In general, TCP can be thought of as reliable, ordered, and slow; UDP as unreliable, unordered and fast. Because of the large difference in performance, it often makes sense to re-build the parts of TCP wanted for games (optional reliability and packet order), while avoiding the unwanted parts (congestion/traffic control features, Nagle’s algorithm, etc). Due to this, most game engines come with such an implementation, and Godot is no exception.

In summary, you can use the low-level networking API for maximum control and implement everything on top of bare network protocols or use the high-level API based on SceneTree that does most of the heavy lifting behind the scenes in a generally optimized way.

Примечание

Большинство поддерживаемых платформ предлагают все или большинство из упомянутых высокоуровневых и низкоуровневых сетевых функций. Поскольку сеть всегда в значительной степени зависит от оборудования и операционной системы, некоторые функции могут изменяться или быть недоступны на некоторых целевых платформах. Платформа HTML5 в настоящее время предлагает только поддержку WebSocket и не имеет некоторых функций более высокого уровня, а также необработанный доступ к протоколам низкого уровня, таким как TCP и UDP.

Примечание

Подробнее о TCP/IP, UDP и сети: https://gafferongames.com/post/udp_vs_tcp/

Gaffer On Games имеет много полезных статей о нетворкинге в играх (here), включая всестороннее introduction to networking models in games.

Если вы хотите использовать низкоуровневую сетевую библиотеку вместо встроенной сети Godot, см. здесь пример: https://github.com/PerduGames/gdnet3

Предупреждение

Добавление сети в игру сопряжено с некоторой ответственностью. Это может сделать ваше приложение уязвимым, может привести к использованию читов или эксплойтов. Это может даже позволить злоумышленнику скомпрометировать машины, на которых работает ваше приложение, и использовать ваши серверы для рассылки спама, атаки других или кражи ваших пользовательских данных, если они играют в вашу игру.

Это тот случай, когда сеть существует и не имеет ничего общего с Godot. Конечно, вы можете экспериментировать, но когда вы выпускаете сетевое приложение, всегда заботьтесь о любых возможных проблемах безопасности.

Среднеуровневая абстракция

Прежде чем перейти к тому, как синхронизировать игру по сети, может быть полезно понять, как работает базовый сетевой API для синхронизации.

Godot использует среднеуровневый объект NetworkedMultiplayerPeer. Этот объект не предназначен для непосредственного создания, но разработан таким образом, чтобы его можно было обеспечить несколькими реализациями:

../../_images/nmpeer.png

Этот объект простирается от PacketPeer таким образом, он наследует все полезные методы сериализации, отправки и получения данных. Кроме того, он добавляет методы для установки однорангового узла, режима передачи и т. д. Она также включает в себя сигналы, которые позволят вам знать, когда участник сети подключается или отключается.

This class interface can abstract most types of network layers, topologies and libraries. By default, Godot provides an implementation based on ENet (NetworkedMultiplayerEnet), but this could be used to implement mobile APIs (for adhoc WiFi, Bluetooth) or custom device/console-specific networking APIs.

В большинстве случаев использование этого объекта напрямую не рекомендуется, так как Godot предоставляет сетевые средства еще более высокого уровня. Тем не менее, он доступен в случае, если у игры есть конкретные потребности в API более низкого уровня.

Инициализация сети

Объект, который управляет сетью в Godot-это тот же самый объект, который управляет всем, что связано с деревом: SceneTree.

Для инициализации сети высокого уровня SceneTree должен быть предоставлен объект NetworkedMultiplayerPeer.

To create that object, it first has to be initialized as a server or client.

Инициализация сервера, прослушивание, заданного порта, с неким максимальным количеством подключений:

var peer = NetworkedMultiplayerENet.new()
peer.create_server(SERVER_PORT, MAX_PLAYERS)
get_tree().set_network_peer(peer)

Инициализация клиента, подключение к указанному IP и порту:

var peer = NetworkedMultiplayerENet.new()
peer.create_client(SERVER_IP, SERVER_PORT)
get_tree().set_network_peer(peer)

Get the previously set network peer:

get_tree().get_network_peer()

Проверка инициализации дерева (клиент или сервер):

get_tree().is_network_server()

Закрытие сетевых функции :

get_tree().set_network_peer(null)

(Хотя, возможно, имеет смысл сначала отправить сообщение, чтобы другие участники знали, что вы уходите, вместо того, чтобы закрывать соединение, зависит от вашей игры.)

Управление соединениями

Некоторые игры принимают подключения в любое время, другие только в лобби. Godot можно запросить больше не принимать соединения в любой момент (см. set_refuse_new_network_connections(bool) и связанные методы на SceneTree). Для управления разрешениями на подключение, Godot предоставляет следующие сигналы в SceneTree:

Сервер и клиенты:

  • network_peer_connected(int id)
  • network_peer_connected(int id)

The above signals are called on every peer connected to the server (including on the server) when a new peer connects or disconnects. Clients will connect with a unique ID greater than 1, while network peer ID 1 is always the server. Anything below 1 should be handled as invalid. You can retrieve the ID for the local system via SceneTree.get_network_unique_id(). These IDs will be useful mostly for lobby management and should generally be stored, as they identify connected peers and thus players. You can also use IDs to send messages only to certain peers.

Клиенты:

  • connected_to_server
  • connection_failed
  • server_disconnected

Again, all these functions are mainly useful for lobby management or for adding/removing players on the fly. For these tasks, the server clearly has to work as a server and you have to perform tasks manually such as sending a newly connected player information about other already connected players (e.g. their names, stats, etc).

Лобби можно реализовать любым удобным для Вас способом, но наиболее распространенным способом является использование узла с одинаковым именем во всех одноранговых сценах. Как правило, автоматически загружаемый узел/синглтон отлично подходит для этого, чтобы всегда иметь доступ, например, «/root/lobby».

RPC

Для связи между узлами проще всего использовать RPC (удаленные вызовы процедур). Это реализовано в виде набора функций в: Node:

  • rpc(«function_name», <оptional_args>)
  • rpc_id(<peer_id>,»function_name», <optional_args>)
  • rpc_unreliable(«function_name», <optional_args>)
  • rpc_unreliable_id(<peer_id>, «function_name», <optional_args>)

Синхронизация переменных также возможна:

  • rset(«variable», value)
  • rset_id(<peer_id>, «variable», value)
  • rset_unreliable(«variable», value)
  • rset_unreliable_id(<peer_id>, «variable», value)

Функции можно вызывать двумя способами:

  • Надежный: вызов функции прибудет, несмотря ни на что, но может занять больше времени, потому что он будет повторно передан в случае сбоя.
  • Unreliable: if the function call does not arrive, it will not be re-transmitted; but if it arrives, it will do it quickly.

В большинстве случаев требуется надежность. Ненадежный в основном полезен при синхронизации позиций объектов (синхронизация должна происходить постоянно, и если пакет потерян, это не так уж плохо, потому что новый в конечном итоге прибудет, и он, вероятно, будет устаревшим, потому что объект перемещается всё дальше).

There is also the get_rpc_sender_id function in SceneTree, which can be used to check which peer (or peer ID) sent an RPC.

Вернёмся к лобби

Давайте вернёмся к теме лобби. Представьте, что каждый игрок, подключившийся к серверу, расскажет нам об этом.

# Typical lobby implementation; imagine this being in /root/lobby.

extends Node

# Connect all functions

func _ready():
    get_tree().connect("network_peer_connected", self, "_player_connected")
    get_tree().connect("network_peer_disconnected", self, "_player_disconnected")
    get_tree().connect("connected_to_server", self, "_connected_ok")
    get_tree().connect("connection_failed", self, "_connected_fail")
    get_tree().connect("server_disconnected", self, "_server_disconnected")

# Player info, associate ID to data
var player_info = {}
# Info we send to other players
var my_info = { name = "Johnson Magenta", favorite_color = Color8(255, 0, 255) }

func _player_connected(id):
    pass # Will go unused; not useful here.

func _player_disconnected(id):
    player_info.erase(id) # Erase player from info.

func _connected_ok():
    # Only called on clients, not server. Send my ID and info to all the other peers.
    rpc("register_player", get_tree().get_network_unique_id(), my_info)

func _server_disconnected():
    pass # Server kicked us; show error and abort.

func _connected_fail():
    pass # Could not even connect to server; abort.

remote func register_player(id, info):
    # Store the info
    player_info[id] = info
    # If I'm the server, let the new guy know about existing players.
    if get_tree().is_network_server():
        # Send my info to new player
        rpc_id(id, "register_player", 1, my_info)
        # Send the info of existing players
        for peer_id in player_info:
            rpc_id(id, "register_player", peer_id, player_info[peer_id])

    # Call function to update lobby UI here

You might have already noticed something different, which is the usage of the remote keyword on the register_player function:

remote func register_player(id, info):

This keyword has two main uses. The first is to let Godot know that this function can be called from RPC. If no keywords are added, Godot will block any attempts to call functions for security. This makes security work a lot easier (so a client can’t call a function to delete a file on another client’s system).

Второй способ применения указывает как функция будет вызываться через RPC. Всего есть 4 разных ключевых слова:

  • remote
  • remotesync
  • master
  • puppet

Ключевое слово remote значит, что rpc() будет идти по сети и вызываться удалённо.

The remotesync keyword means that the rpc() call will go via network and execute remotely, but will also execute locally (do a normal function call).

The others will be explained further down. Note that you could also use the get_rpc_sender_id function on SceneTree to check which peer actually made the RPC call to register_player.

With this, lobby management should be more or less explained. Once you have your game going, you will most likely want to add some extra security to make sure clients don’t do anything funny (just validate the info they send from time to time, or before game start). For the sake of simplicity and because each game will share different information, this is not shown here.

Starting the game

Once enough players have gathered in the lobby, the server should probably start the game. This is nothing special in itself, but we’ll explain a few nice tricks that can be done at this point to make your life much easier.

Player scenes

In most games, each player will likely have its own scene. Remember that this is a multiplayer game, so in every peer you need to instance one scene for each player connected to it. For a 4 player game, each peer needs to instance 4 player nodes.

So, how to name such nodes? In Godot, nodes need to have a unique name. It must also be relatively easy for a player to tell which node represents each player ID.

The solution is to simply name the root nodes of the instanced player scenes as their network ID. This way, they will be the same in every peer and RPC will work great! Here is an example:

remote func pre_configure_game():
    var selfPeerID = get_tree().get_network_unique_id()

    # Load world
    var world = load(which_level).instance()
    get_node("/root").add_child(world)

    # Load my player
    var my_player = preload("res://player.tscn").instance()
    my_player.set_name(str(selfPeerID))
    my_player.set_network_master(selfPeerID) # Will be explained later
    get_node("/root/world/players").add_child(my_player)

    # Load other players
    for p in player_info:
        var player = preload("res://player.tscn").instance()
        player.set_name(str(p))
        player.set_network_master(p) # Will be explained later
        get_node("/root/world/players").add_child(player)

    # Tell server (remember, server is always ID=1) that this peer is done pre-configuring.
    rpc_id(1, "done_preconfiguring", selfPeerID)

Примечание

Depending on when you execute pre_configure_game(), you may need to change any calls to add_child() to be deferred via call_deferred(), as the SceneTree is locked while the scene is being created (e.g. when _ready() is being called).

Synchronizing game start

Setting up players might take different amounts of time for every peer due to lag, different hardware, or other reasons. To make sure the game will actually start when everyone is ready, pausing the game until all players are ready can be useful:

remote func pre_configure_game():
    get_tree().set_pause(true) # Pre-pause
    # The rest is the same as in the code in the previous section (look above)

When the server gets the OK from all the peers, it can tell them to start, as for example:

var players_done = []
remote func done_preconfiguring(who):
    # Here are some checks you can do, for example
    assert(get_tree().is_network_server())
    assert(who in player_info) # Exists
    assert(not who in players_done) # Was not added yet

    players_done.append(who)

    if players_done.size() == player_info.size():
        rpc("post_configure_game")

remote func post_configure_game():
    get_tree().set_pause(false)
    # Game starts now!

Synchronizing the game

In most games, the goal of multiplayer networking is that the game runs synchronized on all the peers playing it. Besides supplying an RPC and remote member variable set implementation, Godot adds the concept of network masters.

Network master

The network master of a node is the peer that has the ultimate authority over it.

When not explicitly set, the network master is inherited from the parent node, which if not changed, is always going to be the server (ID 1). Thus the server has authority over all nodes by default.

The network master can be set with the function Node.set_network_master(id, recursive) (recursive is true by default and means the network master is recursively set on all child nodes of the node as well).

Checking that a specific node instance on a peer is the network master for this node for all connected peers is done by calling Node.is_network_master(). This will return true when executed on the server and false on all client peers.

If you have paid attention to the previous example, it’s possible you noticed that each peer was set to have network master authority for their own player (Node) instead of the server:

[...]
# Load my player
var my_player = preload("res://player.tscn").instance()
my_player.set_name(str(selfPeerID))
my_player.set_network_master(selfPeerID) # The player belongs to this peer; it has the authority.
get_node("/root/world/players").add_child(my_player)

# Load other players
for p in player_info:
    var player = preload("res://player.tscn").instance()
    player.set_name(str(p))
    player.set_network_master(p) # Each other connected peer has authority over their own player.
    get_node("/root/world/players").add_child(player)
[...]

Each time this piece of code is executed on each peer, the peer makes itself master on the node it controls, and all other nodes remain as puppets with the server being their network master.

To clarify, here is an example of how this looks in the bomber demo:

../../_images/nmms.png

Master and puppet keywords

The real advantage of this model is when used with the master/puppet keywords in GDScript (or their equivalent in C# and Visual Script). Similarly to the remote keyword, functions can also be tagged with them:

Example bomb code:

for p in bodies_in_area:
    if p.has_method("exploded"):
        p.rpc("exploded", bomb_owner)

Example player code:

puppet func stun():
    stunned = true

master func exploded(by_who):
    if stunned:
        return # Already stunned

    rpc("stun")
    stun() # Stun myself, could have used remotesync keyword too.

In the above example, a bomb explodes somewhere (likely managed by whoever is master). The bomb knows the bodies in the area, so it checks them and checks that they contain an exploded function.

If they do, the bomb calls exploded on it. However, the exploded method in the player has a master keyword. This means that only the player who is master for that instance will actually get the function.

This instance, then, calls the stun method in the same instances of that same player (but in different peers), and only those which are set as puppet, making the player look stunned in all the peers (as well as the current, master one).

Note that you could also send the stun() message only to a specific player by using rpc_id(<id>, «exploded», bomb_owner). This may not make much sense for an area-of-effect case like the bomb, but in other cases, like single target damage.

rpc_id(TARGET_PEER_ID, "stun") # Only stun the target peer