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

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. The Goal:

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

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.

Types of Movement: Up Down Left Right Up & Right Up & Left Down & Right Down & Left Stop 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. x, y, r

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. Functions: add-object remove-object update-object Functions: tell-all-except Current Objects: ((0 tank) (1 tank) (2 bullet)…) Current Objects: ((0 tank) (1 tank) (2 bullet)…) New (x, y, r, m) Tell-all synchronize (x, y, r, m)

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.

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.

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)

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.

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 through the bespin.org “cs396” mailing list via Mailman

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