Improve slightly doc

docs/gdevelop5/all-features/multiplayer/index.md

@@ -17,20 +17,20 @@ It is built to be easy to use, accessible to everyone, and provides a good exper
 Some features available out of the box are:
 
 - **Lobbies** for your game and a user interface allowing players to start a new game,
-- Built-in **authentication** for players to create an account and login to your game,
+- Built-in **authentication** for players to create an account and log in to your game,
 - Automatic choice of the _host_ of the game,
 - Automatic **synchronization of players**, depending on who is in charge of each object,
 - Automatic synchronization of the rest of the **game state**: game objects, variables...
 
 !!! tip
 
-    Usually, adding multiplayer features or creating from scratch a multiplayer game is something that is difficult and error-prone. Most solutions, including some you could adapt or use with GDevelop, requires some programming and networking knowledge. With GDevelop Multiplayer features, there is **no need to handle servers**, sending custom messages, handling connections, lobbies, packets being lost, prediction of movements, interpolation, etc.
+    Usually, adding multiplayer features or creating a multiplayer game from scratch is something difficult and error-prone. Most solutions, including some you could adapt or use with GDevelop, require some programming and networking knowledge. With GDevelop Multiplayer features, there is **no need to handle servers**, sending custom messages, handling connections, lobbies, packets being lost, prediction of movements, interpolation, etc.
 
 To use the multiplayer features, use the **Multiplayer** behavior on your objects, and the actions/conditions in the **"Multiplayer"** category in GDevelop. It is automatically available in your game, and you can start using it right away. This page will explaining how to use the behavior to make a multiplayer game and the actions/conditions to start and end a game.
 
 !!! note
 
-    GDevelop Multiplayer infrastructure is built to scale from very small game to games with thousands of concurrent players. If you're a game studio or an agency with specific needs (for example, launching a game for a promotional campaign to an audience of dozens of thousands of people), feel free to reach out to discuss your specific use-case.
+    GDevelop Multiplayer infrastructure is built to scale from very small game to games with thousands of concurrent players. If you're a game studio or an agency with specific needs (for example, launching a game for a promotional campaign to an audience of dozens of thousands of people), feel free to reach out at [email protected] to discuss your specific use-case.
 
 ## 1-minute example: from a static game to a 2 player platformer game
 
@@ -65,7 +65,7 @@ Use the action **Open game lobbies**. This action will show the lobbies to the p
 
     - When players join a lobby, they are automatically assigned a player number, and the host of the game is automatically defined (player 1).
     - When all players are ready, the player 1 can start the game.
-    - When the game is started, the lobby is automatically closed and players are automatically connected to each other.
+    - When the game is started, the lobby window is automatically closed and players are automatically connected to each other.
 
 ??? note "More about player authentication"
 
@@ -90,6 +90,9 @@ Note that there is also a condition called **Player is in a lobby** if you need
     - Condition and expression **Player number**. Use this expression or condition to retrieve and compare the player number of a player in the lobby. Numbers are 1, 2, 3, etc.
       This will be particularly useful during the game so you can assign who has permissions to do what, and who is in charge of what, depending on the player number.
 
+    - Conditions **Player has left**:
+      use this condition to know if a player has left the lobby. This can be useful to adapt your game if a player leaves the game, either by ending the game or adapt the difficulty of the game.
+
 When developing the game, you can open multiple preview windows and join the same lobby with the same account. This way, you can test the multiplayer features without needing multiple devices.
 
 ![Open multiple preview windows to test a multiplayer game](./multiple-previews.png)
@@ -114,19 +117,23 @@ By default, if this behavior is not used anywhere, no objects are synchronized b
 To make a multiplayer game, you need to identify:
 
 - Which objects must be synchronized between players (typically, most of the moving objects)
-- Which objects are "owned" by the server or by a specific player - see below.
+- Which objects are "owned" by the host or by a specific player - see below.
 
 For each synchronized object, there is a notion of **owner** of the object. The owner is the player who is in charge of the object instance: they can move it, change their properties, etc. Other players will simply reproduce this on their own game.
 
-By default, when you use the Multiplayer behavior, the owner of the object is the server.
-You can change the owner of an object by using the action **Change Player object ownership**. The owner is designated by the player number (1, 2, 3, 4...) or by 0 when the object is owned by the server.
+By default, when you use the Multiplayer behavior, the owner of the object is the host (Which is defined as Player 1 in the lobby).
+
+- If your object is not meant to be owned by a specific player, but it's critical for everyone to see it at the right position, you can leave it like this, and the host will be the owner of the object.
+- If your object is meant to be owned by a specific player only (a character for instance), you can change the owner of the object to this player number.
+- If your object is meant to change owner during the game (for instance, a bonus that can be picked up by any player, or an arrow that can be shot by a player or the other), then leave the owner as "Host", and change who owns this object during the game by using the action **Change Player object ownership**. The owner is designated by the player number (1, 2, 3, 4...) or by 0 when the object is owned by the host.
 
 !!! note
 
-    Even if player 1 is the server, there is a difference between an object owned by the server and an object owned by player 1.
-    You can for instance allow another player to grab an object if the server owns it (as in "no-one owns it"), but not if player 1 owns it.
+    Even if player 1 is the host, there is a difference between an object owned by the host and an object owned by player 1.
+    You can for instance allow another player to grab an object if the host owns it (as in "no-one owns it"), but not if player 1 owns it.
+    For the moment, player 1 is the default host, but we may allow other players to become host in the future.
 
-You can also remove the ownership of an object by using the action **Remove object ownership**. When this action is used, the object will be owned back by the server.
+You can also remove the ownership of an object by using the action **Remove object ownership**. When this action is used, the object will be owned back by the host.
 
 ### On which objects to use the Multiplayer behavior?
 
@@ -155,15 +162,14 @@ When an object is destroyed, the behavior will also ensure it's deleted on other
 
 In most cases, you just need to add the behavior **Multiplayer object** to the objects you want to synchronize, define who is in charge of this object, and GDevelop will take care of the rest.
 
-
 ### Setting ownership of objects
 
 The main action you will use during your game will be **Change player object ownership**. This action allows you to change the owner of an object, so that the proper player can be in charge of the object.
 
 It's often used:
 
-- At the start of the game, to define who is in charge of the objects that are already present in the game.
-  Typically, you will use this action on the player characters, depending on their player number at the beginning of the scene. You don't need to use this action on objects that are created by the server, as the server will be the owner by default (for example, a door, a button, a bonus, etc...)
+- At the start of the game, to define who is in charge of the objects that are already present in the game, if you haven't defined their owner in the behavior already.
+  Typically, you will use this action on the player characters, depending on their player number at the beginning of the scene. You don't need to use this action on objects that are created by the host, as the host will be the owner by default (for example, a door, a button, a bonus, etc...)
 
   ![Example of setting ownership of objects](./set-player-ownership-example.png)
 
@@ -178,13 +184,22 @@ It's often used:
 
 ### Synchronization of variables and the rest of the game
 
-During a game, the server will automatically synchronize the game variables and the scene variables between players. This is particularly useful to have a single source of truth for the game state, and to avoid having to synchronize everything manually.
+During a game, the host will automatically synchronize:
+
+- Which scene is currently played,
+- The values of the global variables,
+- The values of the scene variables,
+  This is particularly useful to have a single source of truth for the game state, and to avoid having to synchronize everything manually.
+
+Whereas each player will automatically synchronize:
+
+- The objects they own, as explained above, and the state of these objects (position, object variables, behaviors, etc...),
 
-If you want to make sure that everyone has the same information about a game state, then you can use the game and scene variables: a score multiplier, the difficulty level, etc...
+If you want to make sure that everyone has the same information about a game state, then you can use the global and scene variables: a score multiplier, the difficulty level, etc...
 
 !!! note
 
-    It means that if a player tries to cheat by modifying the game variables or wrongly change a variable because of a network issue, the server will automatically send again the correct value to the player.
+    It means that if a player tries to cheat by modifying the global variables or wrongly change a variable because of a network issue, the server will automatically send again the correct value to the player.
 
 ## Common patterns and things to look out for