Blue: 2-D Multiplayer Tank Game using PLT Scheme

1. blue A 2-D, multi-player tank game developed in PLT Scheme ~ ~ ~ Ben VandenBos, Tim Reeves, Justin Hall, and John Ericksen ~ ~ ~ Senior Project - CS496 Spring Quarter 2003

2. The Goal: Our goal was to develop a basic 2-D multiplayer tank game using PLT Scheme within a group development environment. The main idea was to make the program as clean, expandable and as readable as possible so the CS211 and CS311 classes could use ‘blue’ as a tool to learn about multi-threading and TCP/IP sockets.

3. Our Beginning Thoughts: • We needed to figure out how to do the following items: • How to determine where each tank is on the screen • How to control the tanks • How to synchronize each client’s data • How to draw to the screen • How to manage collisions (bullets and tanks, tanks and tanks) • How to increase playability of the game • We also wanted to elaborate on the game with additional features: • Sprites • Chat • Animations • Menus

4. Movement: • The two things we needed to look at: • Keeping network traffic to a minimum • Everyone views the same movements Our Solution: To keep track of each player movement as a vector with the following elements: (x, y, r, m) x, y : initial coordinates of movement change r : initial angle of movement change m : type of movement We then had to use this vector to calculate where each tank is during a given movement based upon time.

5. Types of Movement: • Up • Down • Left • Right • Up & Right • Up & Left • Down & Right • Down & Left • Stop x, y, r These movements are sent to the server along with x, y and r values of where the movement changed. This happens every time a button up or button down occurs on the up, down, right and left arrows. When a client receives a change in the movement of an object it uses the timestamp of when the change occurred to calculate the “current” x, y, and r values.

6. Client / Server Architecture • The server and client: • Listens on the given port for S-expressions • Checks the validity of the input S-expressions against available functions • Evaluates S-expressions after checking command validity • The functions available to the server simply make it a synchronization agent of current objects for all of the clients. • The functions available to the client help update the list of current objects. New (x, y, r, m) Current Objects: ((0 tank) (1 tank) (2 bullet)…) Tell-all synchronize (x, y, r, m) Functions: add-object remove-object update-object Functions: tell-all-except Current Objects: ((0 tank) (1 tank) (2 bullet)…)

7. Drawing to the Screen: • To begin we used simple wire frames with an angle indicator. These are simply drawn using draw-* functions in the MrEd graphics library for PLT Scheme. • To streamline screen updates each object on the screen is updated through a thread named *refresh-thread*. • To cut down on screen flickering we implemented double buffering.

8. Collisions: • Each client’s tank (the tank the client controls) checks if it enters the boundaries of another object. Bullet collisions are simply checked by the tank being hit. • After a collision is detected the server is notified and all instances of the objects involved in the collision are destroyed. All the clients are then synchronized. • For playability the given tanks are then respawned in a new location. • The fact that every local object checks if it crosses the boundaries of another cuts down on the overhead of checking for collisions between every single object.

9. Playability: • Screen follows the client’s tank by panning with bounding box: • Allows users to move around the tank universe and be able to see where and how the tank is moving at all times • Arrows show where other tanks off the screen are: • This makes sure that you cant loose track of where other tanks are in the universe (which can be annoying)

10. Added Features: • Sprites: • Instead of drawing wire frames, functions were designed to accommodate sprites used to represent the tanks and the bullets. • Used a color mask to allow transparency to see the background • Chat: • Simply a call on the server that tells all the clients to add the given text from the given person to the command window to the side. • Animations: • A recursive call around a draw-bitmap-section function • Menus: • Before implementing the button up and button down events, the menu was catching the button up event. This event had to be forwarded in order to allow full control. • Menus were made for connecting, exiting, and switching between wire frame and sprites.

11. Development Programs: • CVS: • Allows version synchronization during development • Puts a safety net in place, in the case that you need to roll-back the code to a previous version • Essentially allows multiple people to work on a project • Provides ability to show color-coded differences between two pieces of code • We also used a web-based interface to maximize usability • DrScheme: • Fully featured Scheme editor and interface to PLT Scheme • Mailman: • Most of our communication regarding this project occurred over e-mail through the bespin.org “cs396” mailing list via Mailman

12. Limitations: • Real collisions where tanks stop and react appropriately is a very difficult problem and requires a fairly advanced algorithm • The main inconsistencies in ‘blue’ are caused by the time it takes to update the clients over a network connection (lag is an untamable beast) • Due to the limited number of available threads on the average desktop PC, the is theoretically limited to roughly 40 simultaneous players • Given more time and research these problems could be hammered out