SM 4117 Virtual Reality Assignment 2 By Li Yiu Chong (50262340) In this essay I would analyze the environment of driving game under a network. The analysis will be base on 3D driving game of decentralized architecture and the example I will use would be Midtown Madness 2 (MM2 hereinafter) from Microsoft. Fig. 0.1 Microsoft Midtown Madness 2 I choose such aspect for my analysis because of certain reasons. The first reason is the relatively longer history of the architecture on those games, the game platform can offer the best function and stability compared to the Internet based centralized architecture. Second, it is one of the most popular types of game in the current game market, with a great number of users and players. These games also provide the widest range of connection method (Internet game zone, TCP/IP, Modem Phone Line connection, Local Area Network IPX Protocol, Serial Port Connection, etc), and thus help widening the scope of analysis. Last but not least, these games are usually base on 3D engine, which indicates that there maybe more bandwidth problems and more demanding to the hardware, as the close-to-real time requirement. 1
How does the information shared? Connection Method Most of the games in this category allow both single player mode and multiplayer mode. In MM2, multiplayer connection can be done by Internet (MSN game zone/ipx/tcpip) and non-internet (Serial Cable/MODEM) connections. These allow users as close as in the same room or as far as oversea to share the same race Fig. 1.1 Multiplayer Screen with connection method with their own computers in different locations. The following examples was based on serial cable connection with 115200 bits per second between two users if not specified. The architecture of these games, if clearly specified, is actually a mix of both centralized and decentralized architecture. In each multiplayer game there would be a player to be a host and the other players would be the join-in, no matter there are. The host would keep the most update version of the virtual environment (VE hereinafter, the city for driving in MM2), while every join-in user(s) would still keep their own copy of VE in their own computer. So the join-in computer does only communicate with the host for the change in VE and users state and the host have to deal with updating the VE and sending the updated data to the join-in. Fig. 1.2a the host is waiting for the join-in to start 2
There can be problem if there is great different in the processing speed of different participants computer. In these type of games the starting time would be hold the same, the fast computer will have to wait for the slower computer, the host will have to wait for the join-in to process in order to start, and the side with stronger processing speed will do more updates per second than the side with weaker processing speed. Fig. 1.2b the side with faster computer setting will have to wait for the slower side to start the game, and we can see the other side with their name and an arrow pointing to their vehicle 3
How fast do we need for the connection? Bandwidth Requirement The following can be the things the players need to communicate with each others once the game started: - Game Timer - Players Location (Who passed which check point?) - Players State (Players speed, damage level, action, etc) - Change in VE (What is crashed? Which building is damaged?) - Traffic Light State (Under Cruise Mode) Fig 2.1 there is traffic light in cruise mode Updated coordinate numbers of players vehicles, coordinates of the changed object in the VE, together with many other figure of timer, player speed and damage level and traffic light state, therefore, lead to a great amount of numbers communication need. Hence, the communication speed can be a problem. Fig. 2.2 Connection setting using serial cable connection Among the connection method in MM2, MODEM, MSN Game Zone and Serial Cable connection can be a speed bottleneck to the communication. I have tried to play MM2 with serial cable connection at 9600 bit-per-second, and the number of update per second in the game was greatly reduced to an unacceptable 4
level in both the host computer and the join-in computer (as slow as 10 updates per second). When the speed was set back to 115200bps, the game went back to normal, with the update of screen in both host and join-in back to normal level (over 30 updates per second, since the processing power is not too weak for the testing system of both side). Therefore, a connection speed at 28800bps (close to 28.8k MODEM speed connected to ISP) is generally recommended for this kind of games. When the number of players increase, the connection speed between host and join-in also need to be increased. If the vehicles selected have a greater number of polygons, the bandwidth requirement is also higher. There is a need for a high connection speed for the host especially, as the outgoing bandwidth need is the total number of one in the join-in computers. Hence, there is a maximum users allowed of 8 in each network game session. Since this kind of game emphasis on real time, in most circumstances, the connection speed is considered before the latency problem. If the upload or download speed between the two parties is far too low and affecting the amount of information transported synchronizing the time, both side will wait till the information transportation finished until the next update / next information transported take place. Hence, the number of update per second in both parties machine is reduced. 5
Who is the owner of this and that? Objects ownership Generally specking object ownership would not be a big problem in this type of games, as the only object each user own is the vehicle they selected. Some games may allow users to have fine turn in their vehicles or put some extra equipment on their vehicles, but that can be easily solve if every user have those kinds of add-on equipment and vehicle fine turn allowance in their copy of VE. And in MM2, fine turn and add-on to the vehicles are not allowed. Problem exists if not every users / players have the VE or vehicles selected by the other parties in every of their computers. How if the join-ins computers do not have the copy of VE / driving city same to the host s computer? Fig. 3.1 Error message in join-in side if he/she hasn t got the city file the host is using This can be an important issue in MM2, as the users are allowed to use the city provided by them as the racing city in the game, which the third party but not the game producer produced the city. In MM2, race location error will be prompted in the join-in player(s) computers if they do not have the copy of city in their computer, and the one who has not the copy of the city is not allowed to enter the game of other users who have the city file. The other treatments can be found in other games of this type would be: (1) the join-in players would receive the city file from the host player; (2) the join-in users and host player can still start the game, with the two parties in different VE environment. There will be no problem once if the host player and join-in player(s) all get the city file in the folder of MM2 in their machines. Then how if the join-in player(s) do not have the vehicle that the host player is using? 6
The solution to this problem is different to the city. If the join-in player(s) do not have that vehicle file that the host player is using, the vehicle of the host in their screen will simply replaced by a Mini Cooper Classic (See the example in the following figures). The host is using a Japanese police car and the join-in is using a London taxi. While the join-in do not have Japanese police vehicle in his copy of MM2. The following figures will show how would the vehicles different in the two computers. Fig. 3.2a Host s view Join-in: London taxi Host: Japan police car Fig. 3.2b Join-in s view Host: Mini Cooper Join-in: London taxi Other problem solutions are similar to those mentioned in VE: either the user will be prohibited to enter the game or the user without the file will seek replacement for the file. 7
Fig. 3.3 The prompt message when a new user joined in cruise mode Fig 3.4 User left message prompt when any other user has left the game Generally speaking the game will solve these problem before the start of the game, so all the players would see the vehicles of others and the same VE. In race modes, new user is not allowed to enter the game once a session started. But in cruise mode, new user can enter the game anytime once the session has at least one user. Since the users start in different location in cruise mode, the other users may only see message same to the figure at the left, together with an arrow indicator of the new user s location in the map in the right bottom corner. Any players can leave the game anytime no matter what mode they are in. A message will prompt the other player(s) for the leaving. If the leaving player was the host, after his leaving, MM2 will automatically shift the host player to the one who was the first join-in player of the session. In the game, players will interact with the VE and other players, how would that be treated in MM2? Simply say, the player s interaction with the VE can be treated as the players modification to the VE. Once the interaction took place, for example if a light pole is knocked over by the red London bus in fig. 3.5, the player of the red bus will record 8
down the location of the knocked down light pole and the state of the light pole, then send the updated VE to the host, the player of the blue London bus, and the host will send the VE to other players in the next update. Fig. 3.5 Damage to VE As we can see in the figure, the ranking of other vehicles would be shown above the vehicles. The interaction between players, i.e. crash between players, would be treated similarly. Rather than recording the location and state of other objects, the player side will record the level of damage of their bus, and then update the damage level in their computer and send the new state and location of their vehicles to the host s machine. The host player would manage all these changes and interactions, and it will be the one who finalize the modification to the environment and vehicles. Fig. 3.6 we can see the action of other player once when the location of the vehicles of both parties is close. We can see the damage and the effect to the other user vehicle and vice versa, but we can only guess the damage level of their vehicles according to their look, but no the exact speed and damage level. 9
Who am I? User Representation and Share of Private Information Since this is a driving simulation, the issue of user representation is simple: that is, user is a vehicle. There are external view, internal view and internal view with dashboard of the user s own vehicle. Private information such as current speed, the gear Fig. 4.1 Internal view with dashboard of a London bus using, the damage level of our vehicle and the view the user using, would be hidden to other players. What we can observe about the other player(s) would be an arrow pointing their location and direction in the map extract, and their appearance and ranking if the distance between two players is short. Social behavior in this type of games would be rather simple, as any player is allowed to crash on any object and the other players, and the effect will be shown according to the attribute of the object, such as the collapse of rubbish bin, the turn over of a London bus, etc. The only rule is that if the player exceeds the boundary of the VE, his would not be able go further and he will be restarted in the location he falls out the VE after a few seconds. One thing on private information has to be note: that is, under TCP/IP connection, the join-in players have to know the IP of the host player. Whether the join-in users can share the information of the host machine beside the game would still be questionable today. The host can set a password to let some join-in Fig. 4.2 Password setting for the host player 10
player to join the game and refuse the others, but he does not have the share control on his information other than the game (or whether those information would be shared is not mentioned to the host player). Anyway, it is rather the problem of the host s computer operating system, than the problem of the game itself. Note: 1. Midtown Madness 2 is the trademark and/or copyrighted materials of Microsoft Co. All manufacturers, cars, name, brands and associated imagery featured in the game and this essay are the copyrighted material and/or trademark of their respective owners. 11