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 changer : initial angle of movement changem : 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 ArchitectureThe 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-objectremove-objectupdate-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 timesArrows 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 backgroundChat:• 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 functionMenus:• 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 e-mail 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