![]() This will require the handling of problems such as: Valid RPC parameters are int, float, string, NetworkPlayer, NetworkViewID, Vector3 and Quaternion.If you are planning to make a multiplayer game in Unity, be it two player turn based or massive multiplayer online, you will have to implement some sort of networking solution capable of ensuring that all players share the same consistent world view. lossy connections and the handling of lost dataįor real time games the above problems are especially relevant and if not handled correctly will result in players experiencing “lag”.ĭiffering network latency between players (round trip time), and differences in the variation thereof (jitter).players with differing connection ayers playing on differing hardware platforms (cpu/memory), such as pcs and mobiles.A brief history of networkingīefore diving into the networking solution that Unity offers, lets briefly look at the history of multiplayer games and their networking solutions. Initially, each computer exchanged game information with each of the other computers in a star topology. The game consisted of “turns” and in each turn a computer could choose from a limited number of “moves”. Once all the computers had communicated their next move to all the other computers, each computer carried out the moves after which it was time for the next turn. Assuming that all computers started from the same initial game state, this would ensure that all games played out identically across computers. The disadvantage of this networking solution is that each computer has to wait until it has received the move from the last computer, the slowest computer thus determing the pace of the turns (and thus lag). Real Time Strategy games typically use variants of peer to peer lockstep, albeit with better handling of the lag issues. To avoid having to wait on the slowest computer, each computer now communicates with a single server. ![]() The server has the game “world” and the clients just receive a view on this world. The clients have (almost) no code, they are just dumb terminals sending input (key presses) to the server. The server then carries out the input and sends back a “picture” of the resulting world. There is no longer a problem of keeping the game world consistent across computers as there is only one world (on the server). The solution works fine for computers with the same low network latency but begins to fall apart when players have higher, differing latency. For players with a high latency, the game quickly become unplayable, the world moving in jarring jumps. Doom worked like this and if you had a high latency then most chances were you were dead before you had a chance to see what hit you. To smoothen the game experience, clients no longer wait until they receive a view back from the server. They take the players input and predict what will happen, immediately updating the world view accordingly. This requires the client to know about the game mechanics and game objects, thus the client is no longer dumb. The resulting game play is much more responsive. Of course, a problem occurs when the server world view comes back and differs from what the client predicted. The world view is then yanked back in line with the server view, often causing a noticeable glitch. This solution was first introduced in Quakeworld.
0 Comments
Leave a Reply. |