A 2D, multiplayer tank game developed in 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 clients 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.

Current Objects ((0 tank) (1 tank) (2 bullet))
New (x, y, r, m)
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 clients 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 clients 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