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

Project Modifications

• Use inheritance to add a Player base class
• Create an inheritance hierarchy using the Player, Human and Computer classes
• Use both virtual and pure virtual methods in your hierarchy
• Extend the application to play against other student applications
• Add the capability to run the application as a server or client
• Alter the command-line arguments

Above is a graphical depiction of what your system may look like and may give you an idea of what needs to happen. The main system will interact with a single Player "object" (either a Human or a Computer) which has access to one or more boards. Your main system may also have access to one or more boards (this is the dashed line). The key component here is the socket-based communication between two main systems - both of which can begin as the same main, but will have an if/else statement somewhere that will modify the actions slightly.

Functional Description

Command Line

• Board file
• HUMAN or COMP - will this be a human or computer player?
• SERVER or CLIENT - will this be a server or client?
• Port number - a number between 49152 and 65535
• [Client only] Host name - the IP address or machine name that the server is running on (usually linux1.gl.umbc.edu or linux2.gl.umbc.edu)

The second command-line argument is no longer optional and must be either HUMAN or COMP, indicating which player should be used for the current execution of your application. This no longer indicates who will go first.

The third argument which will be either SERVER or CLIENT indicates whether the current execution will be the Server or the Client.

The fourth argument is the port number that the server is running on (or will run on if this is the server).

The final argument is only required for the client and is the machine name or IP number that the server is running on.

An example of properly running the applications might be:

Server (always start this first):

Design and Implementation Requirements

Classes

Player Class

In designing your inheritance hierarchy, ensure that you adhere to the following guidelines:

• Base classes have data that is commonly required by all derived classes
• Base classes have methods that are commonly required by all derived classes
• Derived classes add data that is unique to only that class
• Derived classes use, extend, and replace base class methods
• Virtual methods allow derived classes to extend and replace base class methods
• Pure virtual methods define a single interface at the base class level that is implemented at the derived class levels.

Communication Protocol

Server

"Server running on port: 51234"

If the server fails to open the socket, the server must print an error message.

If the server detects a win condition during the game, it must print a message indicating the winner.

If the connection to a client is successful, the server should then go into a loop sending and receiving messages from the client.

Client

"Connecting to host: linux1.gl.umbc.edu" "Connecting on port: 51234"

If the client fails to connect to the server, the client must print an error message.

If the client detects a win condition during the game, it must print a message indicating the winner.

If the connection to a client is successful, the server should then go into a loop sending and receiving messages from the client.

Linking to KLSocket.o Updated!

Warning: Do not add the $(SOCKET) to the 'make clean' or 'make cleanest' targets - this will cause your makefile to attemp to delete something that you don't have write access to and will cause a makefile error/warning.

Messages

An example of a sequence of messages might be:

Error Checking Messages Updated!

Extra Credit

Stack-based AI: 10 points

Using the same strategy as the original Queue class, implement a Stack class (last-in, first-out). You must use the same node-based dynamic data structure that you used for the Queue class. In fact, if you just make some basic modifications to your Queue class, you shouldn't need to generate the whole thing from scratch.

In order to determine which is the best strategy, you should devise a "testing suite" that you can use to examine which strategy is best and in which situations. For example, if the ships are randomly distributed, which is better? If the ships are clustered, which is better? If the ships are in a line, which is better? You should plan on running your tests LOTS of times and you must collect the data and analyze the results. The above questions are NOT a sufficent set of questions to ask/answer in your test suite - you need to think of some other comparisons to make between the two. I would recommend running each test at least 100 times to get a good sample-set of results. Some of the metrics you will want to collect are: how many turns were taken? How many squares were missed? How many squares were hit before a loss? You should also think about what the opponent's strategy should be - should you write an opponent that guesses all the ships correctly? One who never wins? Or should you run the AI against itself? Or should you use a combination of these and test all of them (hint, hint)?

Add a command-line argument to your application that indicates "QUEUE" or "STACK" - which should be used.

To get credit, you must submit a README file along with your code for the Stack class and the automated test suite (add this to your makefile). Your README file must include a description of your testing suite, directions for running and building your testing suite, and a discussion on which performed better and under what conditions. Finally, it must include a discussion about why you believe these are the results - given the data, what conclusions can you make about why one class performs better (or the same) as the other? Why do you think this is happening? What about the BattleShip game makes one class a better choice than the other?

3 Levels of AI difficulty: 10 points

• Easy - This must be "easier" than the Queue-based strategy but must include at least one component that makes it harder than just "random selection".
• Medium - This should be the Queue strategy. But you may want to add one or two more challenging components that will improve the performance.
• Hard - This strategy must employ more advanced AI techniques to the game and must show a significant improvement over the Medium strategy.

Add a command-line argument to your application that indicates "EASY" or "MEDIUM" or "HARD" - which should be used. This must be the same argument as the "STACK"/"QUEUE" argument for the other extra credit

To get credit, you must submit a README file along with your code for your strategies and the automated test suite (add this to your makefile). Your README file must include a description of your testing suite, directions for running and building your testing suite, and a justification of how each represents a "significant" improvement over the last. Use your data analysis to support your claims that each "harder" level is a significant improvement over the last (you should probably see the same improvement from the easy to the medium as you do from medium to hard, for example if the medium strategy takes 5% fewer attempts than the easy, then the hard should take 5% fewer attempts than the easy). Finally, include a discussion on what about your "hard" strategy takes advantage of the structure of the BattleShip game to produce a more intelligent AI component.

BONUS Extra Credit: 0-5 points

In order to participate, you must put a file named "BATTLE" in your submission directory (it can be an empty file, but it must be named as indicated. Your application must print "WINNER" if it won the game or "LOSER" if it lost, on a line all by itself - this must be printed to the 'cout' stream. Any applications that attempt to cheat by printing the wrong message will immediately be disqualified and will receive a zero for the entire project.

General Tips

• There are several BIG changes that you will need to make, I would recommend starting small and then implementing the changes one by one. I would also recommend doing them in the following order (this is neither exhaustive nor a requirement, simply a recommendation):
  • Add the Player class (but don't add any methods or data...yet...)
  • Move any data from the Human/Computer classes into the Player class that you want to move
  • Move any methods from the Human/Computer classes into the Player class that you want to move
  • Add virtual destructors as necessary
  • Modify the application to recognize the new command-line arguments
  • Remove all the logic for "who goes first" from previous versions
  • Add methods, etc. to split the client and server components, pretending that the user is a client (i.e. don't integrate the socket class yet, simply model the behavior using 'cin')
  • Write the client component, pretending that the user is a server (i.e. don't integrate the socket class yet, simply model the behaviour)
  • Play with the "example" application so that you understand how to use the socket class
  • Convert your server/client methods to use the socket instead of 'cin'. Due to the fact that the socket library supports the extraction and insertion operator (just like cin/cout), you should have minimal changes to make
• TEST your program thoroughly - the old makefile 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 "bad" cases. You will need to alter the 'make test' to handle the new command line arguments.
• 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/p4.
• 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.
• 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, the makefile will be provided for you. You will be responsible for providing makefiles for all future projects. Copy the file makefile from Ms. Wortman's public directory to your directory.

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

The make utility can also be used for compiling a single file without linking. For example, to compile Proj4.cpp, type make Proj4.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, Proj4 executable and backup files created by the editor. More information about these commands can be found at the bottom of the makefile.

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.
• All unmet function pre-conditions are handled.
• Classes demonstrate high cohesion.
• Classes demonstrate low coupling.
• Classes demonstrate appropriate distribution of tasks.
• All dynamic memory is allocated and deallocated appropriately.
• Player, Computer, and Human classes are organized into a polymorphic hierarchy
• Design uses virtual methods appropriately
• Design uses pure virtual methods appropriately
• Design places data at the correct level of the hierarchy
• Design places methods at the appropriate level of the hierarchy
• All project requirements are met.

15% - Coding Standards