The Outer Space Battle Game

Prepared by
Jim Heliotis (Rochester Institute of Technology)

for OOPSLA 2003 DesignFest


You are to develop a multi-player action game that takes place in a shared, 2-dimensional, virtual space. Each player is at a separate work station, and navigates one vehicle through this space. The space is made visible through a graphical window. All the players' vehicles appear there, and are updated in real time. Space is of finite size, but the ends "wrap around". If you keep heading north, you'll show up at the southern border; if you keep heading east, you end up at the western border; etc. (the technical term for a space like this is a torus). The view (viewport) each player has of this space may not be identical to the others' at any point in time, but the part he or she sees will definitely contain the player's own ship.

Players can control their ships' velocity through forward acceleration and rotation. As in real space, an unacclerated ship maintains a constant velocity forever.

Ships start with a certain amount of  "strength". It is possible to lose strength and gain it back, but a ship can never have more than the initial amount. If a ship's strength drops to or below zero, the ship is destroyed and the player is eliminated from the game. Play continues until only one ship is left; its owner is the winner.

Vehicles have the capability of shooting torpedoes. Each time a torpedo hits a ship, some of its strength is lost. Shooting or being hit by a torpedo has no impact on ship velocity. Torpedos have a finite lifetime, after which they just disappear.

If vehicles collide, each one involved in the collision loses some of its strength.

There are no other objects present in the playing space. Inert background graphics are fine, but objects like pulverizing asteroids or planets and stars with gravity would be outside the scope of this statement of needs.

Time is simulated in small discrete intervals. Time increments are coordinated among the various players' workstations, eliminating the possiblity of some players getting ahead of others for no reason other than the platform on which they are running. Every so many time units, all the ships' strengths are augmented by some fixed amount, but again, remember there is a maximum.

A player may type in a CR-terminated message. That message will be displayed on all the players' workstations.

A player may start a new game at her/his workstation, or join an existing game. This means that games must be named.

Major User Use Cases

  1. Player joins game.
  2. Player changes direction of his/her vehicle.
  3. Player changes speed of his/her vehicle.
  4. Player shoots a torpedo.
  5. Player types in a message; all other players see the message ("chat")

There are other use cases that do not involve the user as the initiator:

Players earn a certain number of points when they successfully hit another ship with a torpedo.

Players' ships can survive a finite number of torpedo hits.

Collisions between ships cause both ships to be destroyed.

Players are given a specific number of lives before they are forced out of the game.

Implementation Considerations

Here are some possible keyboard assignments.


1. Players have the ability to broadcast messages to others during play.

2. Asteroids are created at random times, with random velocities (speed is within an established range). A collision with a ship is equivalent to its being hit by two torpedoes.

Last updated by Torsten Layda, SWX Swiss Exchange, DesignFest® Webmaster.