MiMaze
Architecture![]()
![]()
Our main work on MiMaze was to design a new communication model for interactiv real-time applications on Internet. Such applications have strong time contraints and perform heavy calculations that define our approach. We use two main concepts, distributed calculations and multicast communication, to deal with this constraints. The main related research is the DIS which uses a quite less flexible protocol unappropriated for Internet.
The main caracteristic of an interactiv real-time application is the interaction delay, that is the delay between an action and its effect. Interaction delay is also called response time. Concretly, interaction delay is acceptable when a human player feels that action effect occurs immediately. The DIS defines the maximum interaction delay to 100ms. For less constrained applications like MiMaze, less than 160ms can be acceptable.
MiMaze use the concept of virtual reallity. Players meet each other in a virtual place (a maze). So, all players must have the same view of the virtual world at any moment. That is, the view of the global state of the game. As exposed here, this constraint is impossible to achieve. We will attempt to have a weak state in each player as close as possible to a fictif global state. The acceptable difference between this weak state and the fictif global state is not known as this moment.
Note that this constrains are totally subjectiv and depend on the accuracy of players. We suppose as a basic hypothesis that players will not make any difference between a totally exact simulation and our best effort simulation.
IMaze is the application we choose to experiment our communication model. IMaze has a complet centralized architecture that works fine in a local environment thinks to small delays and low loss rate.
The server of iMaze is in charge of three functions:
Clients of iMaze behave just like basic terminals. They have three functions:
To join the game session, each participant connects to the server with TCP. He leaves the game when he closes the TCP connection. Moreover, this connection is used to transfer the labyrinth in the initialization phase.
While playing, all actions from the clients to the server and all game states from the server to the clients are transmitted with unicast UDP.
Limits of this model:
MiMaze is the distributed version of iMaze. It is distributed at the computation level and at the communication level. This approach suppresses the drawbacks of the server listed above.
MiMaze connects at the initialization phase to a game area database to retrieve the labyrinth. It uses a TCP connection just the time to load the maze. This phase can be replaced by a dynamic process to load areas in real-time while playing. The MAGIC project proposes such mechanism.
Participants in MiMaze communicates with UDP on multicast IP. It allows each participant to receive the actions of other participants in only one step. The global state of the game is not sent over the network. Moreover, multicast mechanism optimizes the network ressources.
Like lots of multimedia distributed applications such as FreePhone or IVS, MiMaze is based on the Real-time Transport Protocol (RTP). RTP manages the session, that is the players joining and leaving and some basic information about them. It computes some usefull statistics about the network like round trip time (rtt) between participants. It provides transport level facilities needed by MiMaze. RTP is totally connection less. If any participant crashes, there will be no consequence for the others.
With the MiMaze multicast architecture, the transmission delays are totally optimized. This is an important point regarding distributed game contraints, but the virtual world constraints are not achieved as easily. As there is no global state computed in a single place, each participant must compute localy his own game state from his player state and the data received from the other participants. Those game states have to be coherent. MiMaze includes a synchronization mechanism we design specifically to allows participants to compute coherent game states at the same moment.
At this time, MiMaze uses only one multicast group for all participants. As we aim to manage lots of players (let say 10000), new communication mechanism based on cells will be studied soon.
![]()