Course Home | Documentation | Lab Hours/Tutoring | Projects | Quizzes | Schedule | Submit

Saint Louis University

Computer Science 1050
Introduction to Computer Science: Multimedia

Michael Goldwasser

Spring 2016

Dept. of Math & Computer Science

Programming Project 03

Missile Command

Due: 11:59pm Wednesday, March 23, 2016



Read this entire document carefully. There are a lot of details to discuss, and we will use this to provide an explanation of the project, advice for how to make progress, and a summary of what is required and what is optional, together with our grading rubric. I recommend that you read through the entire document before beginning, and then refer back to it throughout your work on the project.

Collaboration Policy

This assignment is more technical in nature. Therefore, we are going to ask you to work with one other student in developing your software, and we will devote some class time to support the partnerships. We will allow students to form their own partnerships; please let the instructor know if you wish to have help in finding an unpaired partner.

It is vital that both students contribute to the development of the project. Please make sure you adhere to the policies on academic integrity in this regard.


Our inspiration for this project is the 1980s arcade game Missile Command, originally created by the Atari company. You may read about the history of the game on the Wikipedia article. To get a feel for the game, we strongly suggest you spend some time (but not too much!) playing this online version of the original game.

The basic flow of the game has a cold-war era theme with randomly generated balistic missiles raining down from the sky which will explode if they reach the ground. The player controls the firing of counter-missiles that can explode in the air to destroy the incoming missiles before they reach the ground.

Although we will not be recreating a complete version of the original game in this project, we hope to implement many of the core aspects of the game. This will require significant effort and the key to success will being able to manage the complexity with incremental software development. That is, it is difficult to imagine doing the entire project if you focus on the entire project at once. Instead, we will want you to focus on small, incremental goals to build up more and more functionality as you go. We will also help guide you through this process with the rest of this document.

MVC: Model-View-Controller Software Design

Although we have focussed greatly on graphics in Processing this semester, the graphics is actually the easiest part of the project. The real challenge is to properly manage the state of a game to produce. To help separate the programming tasks, we will follow a relatively common software design approach known as MVC, which stands for model-view-controller (if interested in reading further details, see wikipedia). We separate the software responsibilities as follows:

Object-Oriented Programming

To help in the design of our program, we will rely on a technique known as object-oriented programming, which is supported by Processing. In particular, you are to define a Missile class that defines how a single missile is modeled and rendered. We will later see that if you can successfully define the behavior for one missile, it will become relatively easy to structure the program to include many simultaneous missiles and counter-missiles in our model.

As a first goal, consider the following simulation of a single missile falling from the sky. (This demonstration can be restarted by pressing the 'r' key while the canvas has the focus.)

Before you tackle the full missile command game, we want you to successfully implement such a simple simulation of a single missile. The structure of the above program is implemented as follows, relying on a Missile class that you must create.

There are three important behaviors of the Missile class used in the above sketch: To ensure variety in the game, we use randomness to select the traits of each missile at the time it is constructed. In particular, we immediately pick its start location as a random point on the top edge of the screen, and its target location as a random point on the line that represents the ground. This use of randomness ensures that all missiles are threats (i.e., they won't leave the sides of the screen). Finally, we introduce variance by randomly selecting, for each missile, the number of time units that it will require to go from its start to its target (in our final demonstration, we use a range of 500 to 1000 units).

When using object-oriented programming, all of the information about a single missle will be stored as instance variables defined within the Missile class. For example, to keep track of the starting location, you might either choose to use two distinct numeric values, such as startX and startY, or if you wish to use more abstraction, you can use Processing's PVector class, declaring a single PVector as

  PVector start;    // the starting location of this missile
With that definition, you would refer separately to the fields start.x and start.y for the individual coordinates. To track the motion of the missile, we recommend the following variables:
  PVector start;    // the starting location of this missile
  PVector target;   // the location of the missile's target
  int totalSteps;   // total number of time steps needed from start to target
  int steps;        // number of time steps since the start
With this internal model, the role of advancing a single time step is quite easy: we just increment the steps variable. At any point in time, to determine the current coordinates of the missile, Processing's map() function can be used to separately interpolate the x- and y-coordinates, based on the numbers of time steps out of the total number of steps needed when going from start to target. As we noted before, with this proper modeling, the rendering of the actual missile is trivial, as its simply a red line from start to current locaiton, and a white point at the current location.

Incremental Development

To manage the complexity of the program, we strongly encourage you to do incremental development of the project, getting one piece of functionality working before moving on to additional features. For example, you should not move on to attempt additional aspects of the program until you have been able to implement a Missile class to support the simple simulation given above with a single missile. Once that is done, we recommend the following progression of achievements.


Here is a demonstration of a more complete version of our game. It includes all of the functionality previously described, as well as some extra "bells and whistles" beyond the minimum requirements.

Bells and Whistles

Beyond the minimum requirements, there should be ample opportunity to have fun with this project and expand the functionality and usability of the software. Possibilities include (but are not limited to):

  1. Allow player to use up/down arrows to adjust the spawn rate of incoming missiles (and thus the inherent level of difficulty)

  2. In the official game the "x" that markes the target location for a fired counter missile rapidly blinks until the time at which the counter missile reaches that spot. Implement that effect

  3. Track and display the player's "hit rate" which we define as the fraction of incoming missiles that are destroyed before reaching the ground.

  4. Track and display the player's "efficiency" which we define as the average number of incoming missiles that are destroyed per counter missile.

  5. Our demonstration has an unadorned line to represent the ground, but the original game has more decoration with cities and batteries. Add to the artistic nature of the game.

  6. In our version of the game, all counter missiles are fired from the same location on the ground. In the original game, there are three different firing locations and by default, when a counter missile is fired, it comes from that launching pad which is physically closest to the target. Implement such behavior.

  7. Our demonstrated version of the game goes on indefinitely. The original game includes six cities that are each destroyed if struck by a missile. The game ends if all six cities are destroyed. Introduce such a feature.

  8. The original version of the game progresses in rounds, presumably with some fixed number of incoming missiles that occur within a round, before there is a pause and the beginning of a new (harder?) round. Implement such a framework.

  9. Our demonstration allows for an unlimited number of counter missiles. The original game has a finite number of such missiles (per city, per round). Implement such a mechanism.

  10. In the original game, some of the incoming missiles will occassionaly split into multiple trajectories. Implement such a feature.

If you implement any of these features, make sure that your readme file details those successes.

Submitting Your Assignment

For this project, only one member of a partnership needs to submit the work, but both members of the team should be clearly identified within the header of the source code and the readme file. We ask that you submit the following three files:

  1. The .pde file that contains the actual Processing source code you've written

  2. A separate 'readme' text file, as outlined in the general webpage on programming projects. Of particular note for this project, your readme file must include:

Please see details regarding the submission process from the general programming web page, as well as a discussion of the late policy.

Grading Standards

The assignment is worth 70 points, which will be assessed as follows:

We will consider the possibility of some extra credit for additional Bells and Whistles.

Michael Goldwasser
Last modified: Saturday, 23 April 2016