CS302 / Program 7

Sections 15 & 22
Instructor: Colby O'Donnell

Due Date: Saturday, Dec 13, 2:00 PM

Battleship

Battleship is a popular two player game of warfare at sea.
If you have never played the game, please read the instruction page first to understand the rules of the game.

Background:

The purpose of this assignment is to give you a chance to combine all the knowledge that you have learned over the semester into a single larger project. The program will focus on the use of classes and dynamic data structures, but the program will require the use of of functions, loops, conditional statements and multi-dimensional arrays. The project is to design a battleship game that can be played against the computer.

Requirements:

The requirement for full credit on this program is that it allows a user to play a game of battleship against the computer. The parts of the program must be broken up into classes and put in separate files (similar to the last program). Also, at least one of the four following parts must be allocated dynamically, however you can choose which part or parts. We have provided reasons both for and against using each part of the game dynamically.

Dynamic Part of Program Reason For Reason Against

Ship Size

Ships are different sizes
Might want to record status of each section of ship

All games to have same ship sizes
Possible to record ship status without keeping information about each section

Number of Ships

Allows for flexibility for different game varieties
Easier to test/debug a game with fewer ships
Could assign player handicap by giving each player a different number of ships

If you also make the ship size dynamic, you need to overload the assignment operator for the ships
Standard game always has five ships

The Board

Play games with board other than 10x10
Assign board of different sizes to each player for handicap

Difficult/awkward to dynamically allocate a two-dimensional array in C++
Standard games have 10x10 board

Players

Might want to have games with more than two players

Standard games have two players

Incremental Design Philosophy

Grading on Program 7 is emphasize correctness above completeness. This is a very large program to write. The grading philosophy will favor a partial program that works correctly (an executable that runs) above a complete program that is broken (has no working executable, or executable crashes). Incremental Design is an important concept that is valued in the computer software industry. This program gives you a chance to practice this philosophy.

Design

The design of a program is one of the first and most important step in the creation of a software project. Before you begin writing any code, think about how everything is going to fit together in your program. Below are a few issues that you should think about when planning your design. There are many other decisions that need to be made before you can start coding.

Is the board going to be an member variable of the player, or the other way around, or neither?
Will there be separate classes for the computer and human players or are they similar enough to use the same class?
Are the hits going to be recorded by the board, the player and/or the ship?
Which parts of the game make sense to allocate dynamically or statically?
What needs to be displayed to the player, and when should the display be updated?

These and other questions should be well thought out before you write any code. Drawing pictures and writing out plans on paper is a good way to start.

Once you feel comfortable with your design, you should proceed to write header files, which provide the class definitions that will be used by your implementation code in the .cpp files. Here are a few suggested classes.

Board Class, board.h
Ship Class, ship.h
Player Class, player.h
(Other Classes)

Implementation

Although the majority of the written code exists in the implementation (.cpp files), almost all of your thought and planning should already be invested into the header files containing the class definitions. At this point, implementing the member function definitions should be more of an exercise and less of a brainstorm. If you find yourself wondering why you designed your header file in a certain way, you might not have spent enough time thinking first.

Be cautious however. A seemingly perfect design can become unperfect in the light of implementation difficulties. It's very possible that you find yourself improving your header files to compensate for difficulties or oversites in design. This is a normal process, although computer programmers attempt to minimize this circular redesigning as much as possible.

It's very important in both this program (in terms of grading) and also the real world (in terms of others continuing your code) for each stage of your implementation to result in a product that functions correctly. In other words, a Battleship game that only prints the board and places ships (correctly) will get more credit than a complete program that won't compile or run, due to bugs. Try and get each piece of the program to work before proceeding on to the next piece. A goal of object oriented programming is to allow the parts to be written individually, and it is far better to turn in a compiling, partially working program than a program that doesn't compile or one that crashes.

Here are the milestones we would suggest you follow on your way to a complete Battleship game. If you run out of time and cannot finish, it is best that you stop immediately and thoroughly test and hand-in your partial solution. Remember that you can always turn in your program at the end of each stage, giving you a good backup program to fall on.

Game Setup
- Printing the Board (will be enhanced as you add ships, features, etc)
- Placing Ships on the Board (Manual Placement first, then later attempt computer player placement)
Game Play
- Inputing guesses from player
- Generating random computer guesses
- Determine if a guess hits a ship
- Determine if a hit sinks a ship
- Determine if a sunk ship ends the game

The worst thing that could be done on this programming assignment is to write the entire program, only to find out that many bugs exist, and that producing a working program would be impossible in the remaining time.

Testing

It is often the case that programmers write temporary code (later commented or deleted) that tests the behavior and correctness of individual classes. Most of the time, errors are more detectable when analyzing a single program function, rather than trying to determine which function in a complex function relationship causes an error.

For testing, it may be easier to have both you and the computer set up the board randomly so that you can quickly play games.

We created class Foo that demonstrates how to use the copy constructor, overload the assignment operator and use dynamic allocation.

Hand-in Procedure

Electronically submit all source and header files (.cpp and .h) from your project. Also submit an executable. Other files should not be included in your hand-in.

Good luck!

(Last modified: 12/09/97)