TDTS04: Assignment 5 (2015)

TDTS04: Assignment 5 (2015)
Real-time chat and Othello (using Corba)

This lab was originally developed (by Juha Takkinen) and used in a previous course, but has been modified (by Niklas Carlsson and Rahul Hiran) so that you have the freedom to develop your "chat" client to play a simple real-time game with each other. In the process you will also get a chance to practice and refine your algorithmic skills; implementing the logic of a simple real-time game.

You will implement a simple version of a strategy game called Othello. (Alternatively, you can implement a version of the game "five in a row".) You do not need a nice interface; you only need to make a simple text-based version, but if you have time you can of course feel free to do more ...

You can find the code for this lab here.

OVERVIEW

In assignment 5 you will design, implement, test, and demonstrate a chat system. Your implementation should be done in Java, based on CORBA. As part of the chat system, the users of the system should also be able to play a simple version of "real-time Othello" (or "real-time five in a row"). Finally, you will be asked to answer a number of general questions.

We strongly recommend to first implement the chat system (without Othello), and then (when you have it working) add the Othello functionality.

THE SYSTEM AND ITS FUNCTIONALITY

The figure below shows the components included in the chat system that you will develop in this assignment.

chatsystem

Your solutions should contain a chat system, as well as a real-time game implementation. We next describe each of these components.

Chat System

The chat system is intended to function as follows:

  1. Clients should be able to connect to the server (using command "join"), or leave the server (using command "leave"). When a client joins it must specify its name (to be used as a user name for that session). The client can only join if the name does not already exist. When a client has connected to server, it is as an active client.
  2. Only active clients can publish messages (using command "post") to the chat group consisting of other active clients. An active client can publish one row at a time.
  3. All clients (passive and active) can request a list (using command "list") on all user and active clients in the system.
  4. The chat server should pass each post that is published to all active clients, including to the user that published the post. The chat server should also inform all active users about all new connections (join) and completions (leave).
Othello (or alternatively five-in-a-row)

During a chat session, any client can start a game of Othello (or in the case a game is already started, join an ongoing game of Othello). This is done using the command "Othello color", where "color" indicates the player markers, which can take value "x" or "o". You can assume that there is always only one game being played in the system. If there is no active player, the first person begins from an empty playing field. You must allow multiple players per color ("x" or "o"). You must also allow players to make moves in their own pace. (This should allow a faster player to place more markers than a slower player. Also, a team with many players may be able to place more markers than a team with fever players.)

To make things easier, we suggest you make a text-based solution (with "x" and "o"). You have a lot of freedom exactly how you implement the interface and update the board. For each freshly laid tile as expected, however, you update the playing field under the rules of Othello. As in regular Othello the winner is the player (or team of players) that have the color that covers the largest number of squares on the board at the time when there are no empty positions on the board. During the game, please update the board as soon as a player selects a new location for a marker. Each player can place markers by providing the coordinates for empty locations on the board. As with chess, within the 8x8 board, positions are numbered from A:1 to H:8.

Note: If you find the rules of Othello difficult to implement or the game itself boring, you can select to implement a version of five-in-a-row instead. Similar to the real-time version of Othello, you should allow the user to place markers at their own pace and team up against each other. A team of players are considered the winner(s) when they have five markers in a row (where "five in a row" can be achieved by having five markers in a row horizontally, vertically, or diagonally).

INSTALLATION OF CODE SKELETON

For this assignment, you should start from the code skeleton available on here. It implements a simple client-server based chat system that contains the building blocks you need to do the assignment.

First, make sure that you can compile and run code that you have downloaded from the course website. Learn how to decipher what the code does and how it functions. Use the included Makefile. Start the orbd name server on any port number. The Makefile uses port 1050, but you will have to change this port number as there likely will be other lab groups that run the same code on the same lab machine. (To avoid such issues, you can pick a number that is unlikely to overlap; e.g., the last four digits of your social security number.) If you do not change the port number, you are most likely to call a name server that belongs to another group!

Here is an example of how you compile the chat system:

% make target
% make clobber
% make idl
/usr/bin/idlj -fall Chat.idl
% make c
/usr/bin/javac ChatClient.java ChatApp/
*.java
% make s
/usr/bin/javac ChatServer.java ChatApp/*.java

For the assignment (and demonstration therefore), you may want to execute and test the chat system using (at least) three open terminal window on the screen.

Start the name server in the first window. The example below assumes that you have chosen port number 1057. Be sure to start the name server process in the foreground; i.e., without the ampersand at the end, so it's easy to stop it with Ctrl-C at the end of the lab.

% make orbd
orbd -ORBInitialPort 1057 -ORBInitialHost
localhost

Start the chat server in the second terminal window:

% make server
/usr/bin/java ChatServer -ORBInitialPort 1057
-ORBInitialHost localhost
ChatServer ready and waiting ...

Finally, start up the chat client in the third window:

% make client
/usr/bin/java ChatClient -ORBInitialPort 1057
-ORBInitialHost localhost
Hello....
....Goodbye!

As you study the code to understand how the chat system is constructed, pay extra attention to the callback function that is invoked by the server in the client. You will need to utilize this function.

When you no longer work with the lab, make sure to stop orbd-name server!

CHAT SYSTEM AND EXAMPLE

After installing the code skeleton (see above), you're ready to begin implementing the chat system.

  1. Start by defining the chat system interface for the client-server communication in the Interface Definition Language (IDL). This can be done in the file Chat.idl. Ensure that all functionality (join, leave, etc.) is defined with the interface. Then, add the code that handles this functionality in the files ChatClient.java and ChatServer.java.
  2. It is sufficient that you can demonstrate the chat system using one machine.
  3. Your program is expected to handle all errors in a nice, seamless way (e.g., see the test run below).
  4. Make your application interactive.
For example, a typical session might look like below. (Commands marked with%.)
% make client
/usr/bin/java ChatClient -ORBInitialPort 1057
-ORBInitialHost localhost
% join bob
Error: user bob is already an active chatter
join alice
Welcome alice
% list
List of registered users:
alice
bob
charlie
% post Who is out there?
alice said: Who is out there?
charlie left
% list
List of registered users:
alice
bob
% post Why did Charlie leave?!
alice said: Why did Charlie leave?!
bob said: Because you joined....
bob left
% list
List of registered users:
alice
% leave
Goodbye alice
% quit
%

EXPECTATIONS OF YOUR REAL-TIME GAME IMPLEMENTATION

The main goal with this part of the assignment is that you create a reasonable real-time game ("Othello" or "five in a row"). However, it is up to your creativity to provide a manner in which the user can enter the next move and how the board is being updated and displayed. A simple text based solution is sufficient, and slight variations in the rules are allowed. (For example, if you prefer a 9x9 board, or somewhat modified rules to allow a good multi-user experience, that is okay.) Just remember to document the rules of your game and describe how you tested your implementation. The focus here is to create the game, not the details of getting an official version of Othello working.

QUESTIONS ABOUT THE LAB

  1. Explain what is the purpose of the name server that is being used by the chat system. How would a call by the client have looked like if the name server would not have existed?
  2. The server in the lab is using the callback function. This is one way of implementing asynchronous method calls in CORBA and does not affect how objects are implemented in the server. Please explain why this is the case. Are there other alternative options for how asynchronous calls can be implemented in CORBA?

DEMONSTRATION AND REPORTING

To complete the labs, you must demonstrate your solution for the TA. At the time of demonstration, you should have started orbd-name server process, the CORBA chat server that you have implemented, and at least three different instances of the CORBA chat client.

Check that you have responded in detail to the (supplementary) questions in the assignment and use reputable sources as references.

Before you demonstrate your solution, give your TA a hardcopy (printout) of your code, including the Makefile.

Finally, you should hand in a report using a properly completed and signed IDA lab cover. Make sure you have carefully answered all questions in the text as fully as possible and that you have provided reputable sources that support your answers. Your report should explain and illustrate how you tested the functionality of your implementation. Any limitations should also be clearly stated.

Additional helpful hints from the TAs