Architecting your Game for TCE
Building a game with TCE may require a significant shift in perspective from what you already know about game networking, because TCE takes care of all the low-level details for you. It will automatically manage connections to peers in a game session and perform NAT hole punching if necessary (though this may require the use of Tashi Relay if none of the players in the session have a publicly reachable IP address; see below).
At a high level, TCE works a lot like a distributed message queue (in fact, we used TCE to build a distributed MQTT broker to showcase its flexibility). Each player's game client passes messages (transactions) to their TCE instance, which will handle dissemination of the data to other peers and then return those messages in the same order for all clients.
Thus, instead of sending messages to individual peers to update their game state, you simply encode your player's actions as transactions and pass them to TCE, then each player's game client simply applies those transactions to the game state in the order that TCE returns them. Assuming this process is deterministic, every game client should end up with the same game state.
If you are familiar with the Redux library for Javascript, you can think of TCE as generating a single, global order for all actions regardless of which player submitted them, and then each game client individually applies these actions to its game state, in the order they are returned by TCE, using a reducer function.
This eliminates the need for a game server, as each game client individually enforces the game rules while applying transactions to their game state. If the game rules are applied deterministically, all honest game clients should end up with the same game state. A dishonest game client can only lie to its own player, as all the other clients will know what the true game state is and can simply ignore any transactions which violate the game's rules.
For randomized game mechanics such as attack rolls or loot drops, TCE provides a pseudorandom number generator (PRNG) seeded by the consensus algorithm. When a game event necessitates generating a random number, you'd get an instance of ConsensusRng from the latest consensus event emitted by TCE and use that. Assuming it is used to generate the same number of bytes for a given event on all clients, the output is guaranteed to be the same for all peers, but is designed to be very difficult to predict or manipulate.
The Tashi Consensus algorithm also calculates consensus timestamps for each consensus event which can be used as a synchronous clock source, as all peers will calculate the same timestamps for each event. This clock is not guaranteed to be steady, but is always increasing, and thus can be used for timed game events such as ability cooldowns or respawn timers.
Networking and Tashi Relay
Because Tashi is a peer-to-peer solution, players will need to be able to connect to each other directly. TCE's MeshNet is adaptive and should be able to handle many different network topologies automatically. TCE uses a single UDP socket for all communication.
As long as at least one player has a publicly-accessible IP address, their TCE instance will facilitate NAT hole punching for the other players in their session until they are all connected to each other, or else act as a relay between players if a connection cannot be established.
However, it's quite possible that none of the players in a session have a publicly accessible IP address without NAT hole punching. This is especially likely for players on home networks or mobile players behind carrier-grade NATs.
One possible solution is to instruct players to manually forward ports in their network firewalls and share their public IP address with other players. However, this solution may not be accessible to all players due to a lack of administrative access to their router or simply not having the technical inclination.
TCE does not use Universal Plug-n-Play (UPnP) for NAT traversal due to the myriad security issues with the protocol. Many sources recommend disabling UPnP for these reasons, and newer routers may have it disabled by default.
In this case, we provide a premium service, Tashi Relay, which can provide hole-punching and relaying services to ensure that your players never have trouble establishing a session.
Unlike other services like Unity Relay, which requires you to route all game traffic through it, the goal of Tashi Relay is to facilitate players getting directly connected to each other, and it only acts as a relay as a fallback. This means Tashi Relay can handle more concurrent users compared to Unity Relay for the same cost, or less.
Tashi Relay can also be used to hide players' true IP addresses from each other for privacy reasons. If you set EnableHolePunching to false in PlatformConfig and provide fictitious IP addresses in the address book, all traffic will be routed through Tashi Relay and players will not be able to discover each others' real IP addresses. To save on Relaying costs, this could be an optional feature that the user can toggle on if they want it.
To obtain a Tashi Relay API key, visit the following page: (TODO)