Please note, this section is still a work in progress, and will be completed soon.
Peer-to-peer is the Table Realms technology layer that assists in building multiplayer games. Peer-to-peer is often referred to as P2P.
P2P is implemented with slight differences in each engine due to that engine’s specific shape and requirements, however most of the basic concepts are universal.
P2P works for Hosted, Native, and Embedded games. Whilst P2P is meaningless for console games, a P2P game can still be launched for console with very little effort.
EG: If we build a Construct P2P game we might launch it embedded P2P or from a web browser as a Console game. The same implementation should be able to handle both assuming the game does not require a separate screen per player.
We have implemented the P2P functionality in two modes. We are calling them P2 and P3 respectively.
P2 is the simplest form of a peer-to-peer game, and if at all possible you should use P2, as it will shorten your development time and leave you with a simpler solution. However, P2 may not be flexible enough for all games, and, in fact, there are times using it causes more issues than it solves. If you find this to be the case, P3 is a more complicated solution but allows for more flexibility.
So the 2 in P2 stands for the idea that there is a host game and a client game (or several client games). P2 essentially treats the clients as a display of the game logic, but all decisions are being made on the host game. No messages can travel from the client to the host, they can only travel from the host to the client.
Characteristics:
Please Note: Global and Local Model Data are explained in greater detail in [the next chapter].
Strengths:
Weaknesses:
So the 3 in P3 stands for the idea that we have the connection from the host to the client, and now additionally the connection from the client to the host (and in turn all the clients). P3 allows messages to be delivered from a client to the host and then to all clients. There is no way to target specific players with messages currently.
When we build a P3 game we need to manage more carefully who is setting what. For example we might build a player’s character from the host, but expect the client to manage its location. We need to make sure we do not accidentally try update a global variable like score on the clients and hosts, as they might update at the same time and the value would lose cohesion becoming unpredictable.
Characteristics:
Strengths:
Weaknesses:
So we implement P2P with a few functions, each is made available differently in each engine but in effect they remain the same. Even if you are using a tool like construct where these functions are hidden behind tools, it is still useful to understand how they work.
Game objects have to belong to an instance of the game. In P2, all game objects belong to the host. In P3 the game objects with a playerID attached belong to that player, whilst the ones that have no playerID attached are managed on the host. It should be noted that the host is also a player and has to manage its player’s objects as well as all the game objects that don’t belong to a player.
Firstly, let’s talk data. You have a complicated model that is shared. Use it. This is the most effective way to share data. Just remember that the data should always have a single place (We mean game instance, not place in code) where it is managed. This is the best way to ensure the data is not changed by two people at the same time and the changes pass each other over the network, effectively leaving the data in a unknown state.
So use the global data for as much as you can. We’re not suggesting the coordinates of a mob for example but we are suggesting a player’s current threat or score - things of that nature, especially if they need to be displayed on all the clients.
What follows is the list of functions we have created to assist building your games. We have kept them few and allow for your own expansion through the extendable command function.
This instruction creates a game object on all the players’ environments. This object will have an ID and also might have a player ID. The player ID is set if the object belongs to that player. In P3 this would mean if the player’s movement is tracked, the client for that player is assumed to be the master for the object’s movement.
These messages are sent to track a game object’s movements, scale, and orientation. Usually the tracking of these is handled automatically after the instantiate as when you instantiate you instruct the object whether or not it should be tracked.
This is usually triggered on the owner of a game object. When the object is destroyed on its owners instance, the message to destroy it will be sent to all the other objects.
Commands are the flexible interface where developers can add their own P2P functionality. You will register a command and then send it. Commands will execute on the machine sending as well as all the other devices. Commands can take a payload as defined by the developer. Be careful to only include serealizable primitives in your payload.
Message is not implemented on all game engines. Message is a way to send an instruction to a specific game object instance on all machines. This is useful for changing state of an AI, assuming its behavior is executing locally on all machines. Of all the P2P instructions available, message is the most unique per engine implementation.