General Project Description

You have just recently started an internship with GamesCo - a local interactive game company and your supervisor wants you to create an electronic version of the old BattleShip game. You will be responsible for creating the interface that users will see, all of the game logic, a networking component that will allow users to play each other head-to-head, and an artificial-intelligence component that will allow users to play the computer. Each phase of this project will add on a different component so that by the end of the five phases, you will have a completely operational BattleShips game.

Project Description

Class Description

• Game Board - a class that represents the game board
• Human Player - a class that represents a human player
• Computer Player - a class that represents a computer player

Functional Description

Functionality

• Print an introduction to the user describing what the current application does and how to play the game (keep this brief, assume that the user already knows how to play BattleShip).
• Accept and use 2 command line arguments, in the following order
  • The first is the name of the text file that has the human's ship configuration stored in it.
  • The second is the name of the text file for the computer's ships.
• Accept a third, optional command line argument that must have one of the two following values (capitalization must be exact):
  • HUMAN - indicates that the human player will go first
  • COMP - indicates that the computer player will go first
  If no argument is supplied, then a random selection is made as to who will play first. Hint: Look up the srand() and rand() functions.
• Loop as long as there is no winner
  • Let a player take a turn, repeat request for a board position until a valid position is given by the player.
  • Report the result to the human player (for both players)
  • Record the result
• Report who the winner of the game is
• Exit the program

Error Handling Updated!

• If the human board does not exist: report the error, print a "usage" message, exit the program.
• If the computer board does not exist: report the error, print a "usage" message, exit the program.
• If the HUMAN/COMP argument is not supplied: choose a random player to go first.
• If the HUMAN/COMP argument is invalid: report the error, print a "usage" message, exit the program.
• If the user enters an invalid position: report an error, reprompt for another position (continue to reprompt as long as position is invalid).

Guarantees

• If a board file exists, it will be properly formatted.
• Users will enter in exactly 2 characters followed by a return with a single space between the 2 characters.
• Users may enter alphanumeric or punctuation characters.
• The board file will be formatted in exactly the same way as Project 1.

Design and Implementation Requirements

Classes

• Game Board - this class stores the board and provides operations that give access to the board for a human or computer user. In keeping with information hiding principles, think very carefully about how the players should get access to the individual positions on the board.
• Human Player - this class is responsible for interacting with the human user, displays the board to the user, and handles any record keeping the user needs in order to play the game.
• Computer Player - this class is responsible for handling the human's opponent, any strategy that player uses, and any record keeping that the opponent needs in order to play the game.

You may add any other classes that your application requires. It is up to you to determine what the best way for the above classes to interact, there are many acceptable solutions, no one is necessarily better than another.

In designing your classes, adhere to the following guidelines:

• Support high cohesion - each class should have a responsibility and should handle it very well - this responsibility may have many components, but all operations within the class should be tightly connected to one another.
• Support low coupling - classes should not be dependent upon the internal representation of data from another class. For example, if one class uses a vector to store data, other classes should not know that a vector is being used - they should have some other method for accessing vector items.
• Demonstrate aggregation - classes should store instances of other classes as data members.
• Functional cohesion - as with functions, each method of a class should have a single job, and do that job very well.
• Data storage - data should not be duplicated within a single class or between classes, store information in a single place and allow access to that data using appropriate mechanisms.
• Limit input/output in classes - it is acceptable to localize the use of cout/cin to Input and Output function (like Print()), however, it is more acceptable to pass an istream or ostream to the function (i.e. cin/cout) as a parameter. These parameters must be pass by reference.

Tips for Developing Classes

• You will need to add a target for each of your classes to your makefile. Begin by creating the .cpp and .h files for each of your classes, and performing a make.
• Develop your classes slowly. Begin development of the Board class, start with just a simple .h file with no methods, save, compile. Get your Board class to work in your current application before adding functionality.
• Implement "stub" methods that do not carry out their entire task, but return a valid response. These methods will gradually be fleshed out.
• Add precondition checking to each of your methods. Save, compile.
• Develop a simple main function for each class to run and test each method as you develop them.
• Add one method at a time. Modify the testing main to check for this newly implemented method. Save, compile, run, test.
• DO NOT try and implement an ENTIRE class at once - you will spend more time debugging and correcting your errors than if you develop testing applications and test each method as you develop it.
• Add about 5 lines of code in each iteration. Save, compile, run, test.

Functions

• Limit the use of these "helper" functions by your classes. No access to these functions is the preferred design. Classes can instead use private methods that serve as helper functions.
• All functions called from main() or any other function, must be implemented in a separate file named Proj2Aux.cpp. The prototypes for these functions must be found in a file named Proj2Aux.h.
• Be sure your function header comments list the pre- and post-conditions and handle each pre-condition that is not met.
• Review the class notes on the different methods of passing parameters. Each is best for a different situation.

General Tips Updated!

• TEST your program thoroughly - the makefile provided has a 'make test' target that you can use to ensure that your application will work with our test suite. HOWEVER, you need to test your application using other boards that you create yourself. Be sure to examine the guarantees closely and be sure that your project handles all of the "tough" cases.
• Be sure to name your Aux files as noted above, otherwise, you will have to modify the makefile we provided for Project 1. You will have to add rules for each of your classes that you add to your project.
• Because your program will be tested using Unix redirection, DO NOT prompt for any input not specified in the project description.
• Use incremental development, develop one function at a time, write code that will thoroughly test it, run and test it, then move on to another function. Don't be afraid to write testing code that you will eventually get rid of.
• This project is approximately 150 - 250 lines of code... don't procrastinate.
• Ms Wortman's public directory for this project is /afs/umbc.edu/users/d/a/dana3/pub/CMSC202/p2.
• Do not cheat, you will be caught. Do not look at another student's code - it is very tempting to "borrow" an algorithm. Do not show your code to another student. Use the Tutors, TA's, and Instructors.
• Make sure you have completed Project 0.
• Check the discussion board before emailing a TA or Instructor - your question has probably already been answered.

Project Design Assignment

Project Makefile

The "make" utility is used to help control projects with large numbers of files. It consists of targets, rules, and dependencies. You will be learning about make files in lab. For this project, begin my modifying the makefile provided to you from Project 1.

When you want to compile and link your program, simply type the command make or make Proj2 at the Linux prompt. This will compile all necessary .cpp files and create the executable named Proj2.

The make utility can also be used for compiling a single file without linking. For example, to compile Proj2.cpp, type make Proj2.o.

In addition to compiling and linking your files, make can be used for maintaining your directory. Typing make clean will remove any extraneous files in your directory, such as .o files and core files. Typing make cleanest will remove all .o files, core files, Proj2 executable and backup files created by the editor. More information about these commands can be found at the bottom of the makefile.

Updated: If you are building your own makefile, you MUST use the /usr/local/bin/g++ compiler to compile and build each file. Do not depend on setting your default compiler to be this compiler, the grader may use a different compiler. There are two compilers on the GL systems, and you are required to use the one located at /usr/local/bin/g++.

Grading

The grade for this project will be broken down as follows. A more detailed breakdown will be provided in the grade form you receive with your project grade.

85% - Correctness

• Your project produces all required output.
• The output produced is correct.
• The output is in an acceptable format.
• Your program follows good top-down design principles.
• All function parameters are passed using the appropriate method.
• const variables are used wherever appropriate.
• All unmet function pre-conditions are handled.
• Classes demonstrate high cohesion.
• Classes demonstrate low coupling.
• Classes demonstrate appropriate distribution of tasks.
• All project requirements are met.

15% - Coding Standards