A 2D, multiplayer tank game developed in PLT Scheme - PowerPoint PPT Presentation

1 / 12
About This Presentation
Title:

A 2D, multiplayer tank game developed in PLT Scheme

Description:

The main idea was to make the program as clean, expandable and as readable as ... A recursive call around a draw-bitmap-section function. Menus: ... – PowerPoint PPT presentation

Number of Views:64
Avg rating:3.0/5.0
Slides: 13
Provided by: Joh6348
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com