Multiplayer Online Car Racing Game
Team :
Jonathan Nesbitt, Yoshiaki Ishibashi, David Walker, Richard Brown.
Team Breakdown :
Jonathan and Richard focused on the game networking.
Yoshiaki and David focused on the game graphics.
Task :
Develop a multiple-player online game. The game is to be real-time, not turn based. Carefully select the network protocol and design of the game architecture. The game may be based on the existing code of the tank battle game (it already handles the problems of graphics, audio, keyboard input, and collision detection) or it may be made from scratch.
Basic Concept :
The team's idea was to utilize the code base of the tank battle game but modify it into a racing game. The basics of collision detection, the map, graphics, audio, keyboard input, and generally the user interface with the game were thus already managed.
New concepts :
The additional parts of the game to be created and handled were varied. Naturally being an online game we would have to handle the networking between multiple machines over a variety of networks. The machines would have to transmit information to each other and keep track of what the others were doing. This would be a necessity to keep all the machines in synchronization with each other.
There were also some other ideas that team members wanted to incorporate. We wanted the overall game map to be much bigger than the original tank battle game map. This would allow a much larger game play area and the ability to interact with other players in a different manner. Players on the larger map could get away from each other and thus incorporate a type of "hide-and-seek" quality into the game. Another new concept would be a natural necessity to a racing game, the concept of speed adjustment. In any race game players should be able to control their speed to move faster or slower as desired.
The idea of being able to shoot your competitors was not an original concept of the game but was later incorporated to increase the challenge of the game.
Game Design :
The general design of the game follows a simple plan. The transmission protocol used was User Datagram Protocol (UDP) to minimize the connection overhead. The game was designed as a server-side game to remove any synchronization problems. The keystrokes made by the clients are sent to the server which does all the computation for all the clients. The server then tells each client what to display on their screens. All the client machine does is present the information to the player as instructed by the server and thus there are no problems with synchronization. Actual game play from the client consists of keystrokes from the number pad, space bar, and arrow keys. The number pad keys control the direction of the player's car, the space bar fires bullets, and the arrow keys control the player's speed. The clients start the client side of the game, complete the client's registration form, then wait for the server to start the game. The server starts the server side of the game, starts the server registration form, and waits for the clients to join. When all the players have joined, the server starts the game. When the game starts each player sees a smaller rendered version of the whole map for his view. The player's car is always centered within this client map. As the players move around the whole game map each client's map renders the correct views by extrapolating the position of map squares and objects in the game. In this manner all the objects appear in the correct location and attitude for each player. The game map is part of both the client and server game code. Players drive and shoot until the last player dies. This last player is the winner.
Game Play :
The game requires a minimum of two computers, one as server or host of the game, and, at least, one client or player. One computer starts the server side of the game. Below is the initial server start screen. Clicking the "Start Game" button starts the server registration form (note the red cursor).
Below is the initial view of the server registration form when empty.
All other computers are players and start the client side of the game. Below is the initial client start screen. Clicking the "Connect" button starts the client registration form (note the red cursor).
Below is the initial view of the client registration form when begun.
Each client player then enters the server's IP address and some number (their choice) as a port number.
Below is the completed client registration form ready for the player to click the "Join" button to inform the server of his/her connection information (note the red cursor).
As each client clicks their "Join" button their connection information is transmitted to the server and their connection is displayed on the server registration form. Below is the form when all the clients have "joined". The server manager then clicks the "Start" button to begin the game (note the red cursor).
%20w%20cursor.jpg)
When the "Start" button on the server registration form is clicked the game begins. All players begin in the same area on the game map. Each client will see a section of the whole game map with his car at the center of his map. The player's car will always be centered within his map. Below is a game beginning from the server's view with three competitors and the registration form.
.jpg)
Now the original intent was to make a racing game. Avoid hitting the walls, deep water, other player's cars, and avoid getting hit by their bullets ... last player to die wins. But with so many ways to die, its hard to be the last one to go.
Death by bullets :
...................this is gonna hurt..................
.............ow............yup, that hurt................
Death by deep water :
.........gurgle..............gurgle..............glub...............
Death by wall :
Heading toward the wall..............
...................impact.........ouch !!!
A couple of problems that got discovered too late to fix :
The first was a failure to detect a collision between bullets and indestructible walls. Below you can see the bullets passing through an object they should not pass through ....... oops. The indestructible walls will kill the player as will the bullets but they don't effect each other.
The next problem was the mapping of the bullets onto the client view port. Mapping the movement of the player around the game map was tricky so its no surprise that mapping the bullets presented some difficulties as well. As seen below the bullets disappear (cease to exist) when they travel past the boundaries of the start position map. Note the red tip of the farthest bullet fired by the red car. That is just about the absolute maximum travel of bullets. Beyond that point they no longer exist in the game, they just vanish. Note also the red dots at the top of the screen. Those are bullet explosions reflected (echoed) in a wrap-around effect.
There was an interesting twist to the bullet vanish problem. It seems we discovered a strange quantum tunneling bullet effect. When fired from inside the starting quadrant the bullets disappeared at the edge. However, when fired from outside the start quadrant back toward the start quadrant from a close enough range the bullets would tunnel though sub-space and remain invisible (and harmless) until they reached the edge of the start quadrant. At that point they would become visible and deadly again, at least, for a short range. Oops again.
In Conclusion :
The game, while simple in concept, was a technically complex task in all respects. Both the graphic user interface (GUI) portion along with the networking proved to have steep learning curves which presented unique challenges that most of the team had not dealt with prior to this project. We are all of the opinion that every team member learned a great deal being involved with this effort ... perhaps even our esteemed professor and mentor, Dr. Fu, discovered a few things along this journey. For all his guidance, time, and support we are all tremendously grateful. Without Dr. Fu's tireless efforts we would not have managed even a vague semblance of the learning and accomplishments we ultimately achieved. Again, we thank Dr. Fu for all his leadership, support, patience, and unerring technical skills. We all learned much more than we expected and had a tremendous experience working on this project. Those team members not graduating look forward to future projects with a little less trepidation. Those team members who are graduating will carry the lessons learned from this project into their professional careers where they will undoubtedly pay very useful dividends.