ANSWER NEEDS TO BE IN JAVA

Your task is to write two applications, a client, and a server. They are really equal peers, play the same game, and have the same capabilities. Its just that one of them needs a ServerSocket, so lets refer to it as the server peer (SP) and the other one simply as the peer (P). You can run both P and SP on the same system, using localhost for the server address. Getting this to work by involving your Linux VM is much more interesting, because that way you will have had to set up the local network, transfer files, compile and run Java programs under Linux. Its all very straightforward once the network is set up.

For convenience you can write all code locally in Eclipse on your host but then transfer the applicable Java files with WinSCP to your Linux VM. Editing and tweaking a Java file under Linux works the same as we did for our C programs:

$ gcc Hello.java & assuming you want to edit a file called Hello.java and want to keep the terminal available for input,

run the editor in the background. To compile the same file youd enter

$ javac Hello.java 

and to run it

$ java Hello

The networking part of this assignment will likely turn out to be straight-forward. Working out the game protocol, logic, and framework may take a bit longer.

Familiarize yourself with the examples from class, especially the simple chat. We can use an overall very similar communication logic for the game. You can base SP on the SimpleChatServer, and P on the SimpleChatClient. Instead of sending text messages back and forth we can send strings that hold game data, location of guesses, results of guesses, etc. The sender has to transmit their data by converting to strings, and the receiver has to parse and extract the data before they can apply it.

As we did in the simple chat where the server sent the first message, implement your game also such that SP starts, in this case by making the first guess.

We will be implementing a simple two player version of the game. Each player will hide 4 treasures on a 4x4 board, i.e. 16 squares. A treasure fits into one square. Each player must track the state of the game independently but cant know the location of the opponents treasures. They must know how many of their own treasures are still undiscovered, i.e. how close they are to losing. It may be also interesting for them to know how many of the opponents treasures they found so far. They must also know the history of their past guesses because we will prevent repeat guesses.

At the start of the game, both players hide their treasures. Then SP makes the first guess while P listens. Since Ps treasures are hidden, P must reply to SPs guess and let them know the result. Think about the different outcomes a guess could have. Then they reverse roles, SP listens and P

makes a guess to which SP replies. And so on. A player never gets to make two consecutive guesses. The player who first finds all of the opponents treasures wins. Before any implementing, determine the game protocol, i.e. the order in which the important game steps have to happen, who talks when, who listens when, what information must get transmitted at what moment and in which direction, etc.

Determine required data structures for maintaining the game state in P and SP. All game events and states must be clear from the screen output. One should not be looking at the screen without knowing what is happening, what is being expected or waited for, what was the result of a guess, and so on. The game must initiate input with meaningful and clear prompts including type, range, and format.

Furthermore, when a player makes a guess the game must prompt for a repeat if the guess is invalid. In order to be valid, a guess must lie within the boards bounds and it must be unique. The game must not allow repeat guesses on the same location by the same player. If your output uses certain symbols then you must explain them in some fashion, perhaps by displaying a legend prior to game start.

Playing should continue until one player has discovered all of the opponents treasures. Can there be a tie? The outcome must get announced on each players screen, and the game should shut down automatically for both.

It looks as if each of the two players has identical tasks. Both must make a guess, verify a guess, check the opponents guess, keep track of stats, display stats, etc. Are there OOP concepts that might be useful here in order to avoid code duplication between SP and P?