1

LAMAR UNIVERSITY
Department of Computer Science

Computer Networks
Final Project Report

Submitted by:
Prem Tamang
Biyana Shrestha
Narasimha Bharadwaj Srirangam
 2

Index:

Content Page Number

A) User guide 3
B) Recorder’s log 6
C) Reflector’s Report 7

I) Introduction 9
II) Software’s used 9

References 14

A) User Guide
 3

Instructions on how to play the game:

1) First the user need to run the makefile of the client on the client machines
and make file of the server on the server machine.

2) We need to run the server with command

./svc

3) The players need to run the clients using command

./BattleShipGame
After running this command we will have the battleship window displayed as
shown in fig below.

4) Both the players need to enter the sever name and player name and press
OK button.
 4

5) If the client program is able to connect to the server, it will wait for the next
player to join in the game and his ships will be displayed.

6) Each player need to deploy the ships on the board and if he wants to change
the direction, he needs to double click on the ship and after deploying the
player needs to press the start button to start the game.
 5

7) Now, each player needs to wait for his chance to play on his opponents board
and his opponents moves will be displayed on his board and this continues
until the game is over.
 6

A) Recorder’s log:

We made a battleship program that can be played by 2 players on two computers.

Potentially gameplay could take place over the network and across two Solaris
machines.

This game will be for two players, the users must have at two different
computers to run the game. For the initial release battleship will be running on a PC
Solaris. This game will hopefully be entertaining.

Basic Game :-
Players have two grids, one with their ships and one to record attacks. Each
player gets 5 ships to position
Xwindows with motif - This will be a graphical client to the Basic
game.

It's primary role is to look pretty and take I/O over from the console.
The goal of this Xwindows client is not to reimplement the game but to sit on
top of the Basic Game.
- basic graphics working
- tcp communication tested.basic communication between two clients
working.
- Some 3D aspects to the game tested.

The basic game is the first thing that we wrote, basic classes to hold the boat,
grid, and gameplay. Then an Xwindows with motif front is placed on it.
While this is being worked on synchronous development took place on the tcp
communication for information transfer. Finally advanced communication features.
The final step included sending the board and ship locations to the server and start
playing.

Prem– designed graphical client, and client side programming

together with biyana.
Narasimha - server side programming and prepared report.
biyana - client side programming together with prem and collected
the images and other backgrounds for graphical use.

All of us together studied the basic game plan of how to play battleship and to
implement it into a good project.

We had a basic peer structure, prem took position of leardership, mostly

helped in focusing ideas. Narasimha and Biyana took the position of suggesting
implementation details.

We had deadlines for finishing the project before time.

 7

B) Reflector’s report:-
When started programming , we made a list of structures and functions we
need to use in this project and below are a list of those functions and
structures we used in this project and their purposes.

Client side:
ConnectToServer()//this function is used to get server address from
board and get connected
ReceiveMessage() // this function is used to receive messages from
server whenever there is an update from the other
player
SendMessage() // this function is used to send its updates to the
server in order to send it to the other player

Server side:
Structures used:

typedef struct Point{ //this structure is used to store positions

//of points on the board
int x;
int y;
}
typedef struct Square{ //this structure is used to store the
//information of a square in order to
//change its color according to the event
int color;
enum SQUARE_STATE state;
Point startPos;
Point size;
int ship_no;
}
typedef struct BattleShip {// this structure is used to store the
// information about each ship
int ship_type;
enum SHIP_ORIENTATION orientation;
int ship_size;
int destroyed_counter;
}

typedef struct BattleShip_pos{//this structure is used to store

// the starting and ending positions of the ships
Point start_pos[TOTAL_SHIPS];
Point end_pos[TOTAL_SHIPS];
 8

typedef struct Board{ //this structure is used to store the

//details of the game board
Square square[TOTAL_SQUARES][TOTAL_SQUARES];
Point startPos;
Point size;
int total_squares;
BattleShip battle_ship[TOTAL_SHIPS];
BattleShip_pos battle_ship_pos;
}

Functions used:
Init_Board() // this function is used to initialize the board
getBlockFromPoint()//in this function when the mouse is clicked
// the block number will be returned according to the point
IsShipHit()// this function is used to check if the ship is
//present at the clicked point or not
AllShipDestroyed()// this function is used to find the winner
GetShipHitStatus()// this function is used to check if the ship
// is completely destroyed or not
getShipStartPos() // this function is used to find the starting
//position of the ship
HandlePlayer1() //this fuction is used to handle the events of
//player 1
HandlePlayer2() //this fuction is used to handle the events of
//player 2
 9

I) Introduction :

What is BattleShip: BATTLESHIP is the old favorite Navy Game where two players try to sink
each other's hidden ships. Players place their "fleet" of 5 ships on their "ocean", hidden from the
opponent's view. Taking turns, players call out their "shots" attempting to get "hits" on the
opponent's ships in order to sink them. Strategy and some luck must be combined to be the first
to locate and sink all 5 opponent's ships to win the game.
Each player will have FIVE SHIPS as follows:
"Carrier" (5 holes), "Battleship" (4 holes), "Cruiser" (3 holes), "Submarine" (3 holes), and
"Destroyer" (2 holes).
THE OBJECT OF THE GAME is to be the first player to sink all five of his opponent's ships.
RULES FOR THE BASIC GAME: one shot in a turn and once the ships are deployed they
cannot change their places.
II) Software’s used: Software’s used in this project and the way they work
are explained below,

X Windows
Graphical User Interface makes interacting with the computer easier. It makes the interactiion
with humans and machines more attractive, pleasing and intuitive.
X Windows system is a computer software that provides GUI for networked computers. It is a
device-independent system and is widely used in UNIX machines. X windows provides a basic
framework for building GUI environment that includes drawing and moving windows on the
screen and controlling input devices like mouse and keyboards.
X windows is based on Client-Server architecture. It uses X display protocol which was designed
to use between computers over the network. One of the important feature of X windows is it’s
network transparency where it is able to transmit data over the network and integrate with the
client application seamlessly.
The server is the program that controls the display and client is a application program that uses
the X Windows GUI system. The server can either run in the local or remote machine. It can be
accessed by several clients. Other than making graphical display possible, it also interprets the
network message from client and maintains the local GUI resources like windows and cursors.
The programmer in X Windows system can develop an application in one language and run the
application on different machines. The program can run on one computer and the results can be
displayed on another computer’s terminal. C is the most popular language to program in X
Windows system.

Motif
Motif is a high level X interface toolkit. The visual appearance and how it operates is very
similar to Microsoft Windows and IBM’s OS/2. Motif includes the Motif Toolkit (XM). It uses a
widely accepted set of guidelines developed by Open Software Foundation and it’s partner
companies.
X Windows consist of different layers like Xlib, XT Intrinsics and Motif. Motif is the highest
level and we need work on Motif. Motif lies over XT. So, Motif needs to call different XT
functions. XT is just a mechanism and does not define the look and feel of the window or how it
 10

should be displayed. These look and feel aspects are controlled by Motif. We don’t need to
understand the mechanism and working of XT or Xlib. Motif takes care of it for us.
Xlib uses low-level programming language. It is difficult and time consuming to write complex
GUI components in Xlib or even XT. To avoid this, there are many high level C subroutine
libraries called toolkits and Motif is one of them.
Widgets
Widgets are the building blocks of GUI system. They are the actual GUI components that make
the interaction between human and machine possible. There is a hierarchy of widget classes
defined in Motif and each widget falls under one of those classes. On the higher level, widget
classes basically falls under two categories: the Primitive Widget class and the Manager Widget
class.
The primitive widget class contains the GUI components like buttons and scroll bars. The
manager widget class defines the widgets that hold other widgets. Widgets are programmed to
be independent of the application. They aid applications to interact better. They are capable of
responding to different GUI needs that includes drawing on the screen and intercepting input
events from mouse and keyboards. All aspects of widgets’ behavior and interactions are defined
in the Motif Reference Manual.
The DrawingArea Widget
DrawingArea widget provides a blank canvas for interactive drawing. It uses the basic Xlib
drawing primitives. However this widget does not draw on its own or follow any specific
drawing guidelines. It is subclassed from the Manager Widget class. Therefore it can contain
other widgets as children.
This widget is most useful in painting program where the user can draw anything of any colors
using different tools like pens and brushes without following any design patterns. So,
DrawingArea widget is a free-form widget that allows interactive drawing and placing different
geometrical objects anywhere in the canvas without following any well defined user interface
guidelines or rules.

Toolkits provide callback functions for DrawingArea widget. These callback functions allow
programmer to install very simple drawing routines without handling substantial event-handling
on his own.
Header file needed to call this widget: <Xm/DrawingA.h>
• Widget drawing_a = XmCreateDrawingArea ( parent, "name", resource-value-
array, resource - value - count );
• Widget drawing_a = XtCreateWidget ( "name", xmDrawingAreaWidgetClass, parent,
resource-value-list, NULL);
Scrolled Window
Scrolled Window widget provides a viewing area for another visual object which is usually
larger than the drawing area. The viewing area in Scrolled Window is called the viewport and
can be adjusted by a user by using Scroll Bars that are attached to the Scrolled Window. Scroll
Bars are the most common way to interact with the Scroll Window.
There are two models of scrolling: automatic scrolling and application-defined scrolling.
 11

In automatic scrolling, the Scroll Window widget operates entirely on its own and adjusts the
viewport in response to the attached scroll bar activity. When the user changes the viewport by
using the scroll bars, the Scroll Window adjusts to make the appropriate segment of the larger
object visible.
In application-defined scrolling, the widget assumes that another application or some internal
widgets control the data within the work-window and assumes that the data can change
dynamically as the user scrolls through the data.
Header file needed to call this widget: <Xm/ScrolledW.h>
• Widget scroll_w = XmCreateScrolledWindow (parent, "name", resource-value-array,
resource-value-count);
• Widget scroll_w = XtCreateWidget ( "name", xmScrolledWindowWidgetClass, parent,
resource-value-list, NULL);
TextField Widgets
The widget provides text-entry capability in an application ranging from a simple data entry field
to a full-fledged text editor. This widget also allows the programmer to control the format of the
data being entered by the user. The TextField widget provides same set of editing capabilities for
single-line data entry field but with less overhead than the Text Widget.

This widget follows the point-and-click model of interaction. So, the user can click anywhere
and start typing through keyboard.
Header file needed to call Text widget: <Xm/Text.h>
Header file needed to call TextField widget: <Xm/TextF.h>
• Widget text_w = XtVaCreateWidget ( "name", xmTextWidgetClass, parent,
resource-value-list, NULL);
• Widget text_w = XmCreateText ( parent, "name", resource-value-array,
resource-value-count);
For TextField widget, we need to use xmTextFieldWidgetClass and XmCreateTextField()
instead of the above two.
The RowColumn Widget
The RowColumn widget is a manager widget which lays out its children in a row and column
format. This widget is also used by the Motif toolkit to implement Popup Menus, Pulldown
Menus, etc.
The header file for this widget is <Xm/RowColumn.h>. And XmNrowColumnType controls how
a particular instance of RowColumn widget is used.
It can be used as follow:
• rowcol = XmCreateRowColumn (toplevel, "rowcolumn", NULL, 0)
Labels
Labels are one of those widgets which are not intended for user interaction. They are used to
display static graphics or texts that usually represent other GUI components. If there are non
 12

editable texts to be displayed, it is always wise to use Label against Text widget. Labels also
carry very little overhead compared to Text widget as Label does not need to handle event
processing to the same degree as Text widget.
The header file for Label widget is <Xm/Label.h>. Following is one way to create label widget:
• Widget label = XmCreateLabel ( parent, "name", resource-value-array,
resource-value-count);

Introduction to Dialogs
Applications cannot perform all the tasks in one single top-level window. There are specific
tasks that need to be dealt with a secondary window. This window performs specific tasks like
displaying messages or information mostly related to the preceding action/events. These
windows are called Dialogs.
There is no such thing as Dialog Widget in the Motif toolkit. Dialog is made up of DialogShell
widget and a manager widget child that implements the visible part of the dialog. The
DialogShell interacts with the window manager to provide the required behavior for the Dialog.
One of the Dialog is a message dialog and it can be created as follow:
• dialog = XmCreateMessageDialog (parent, "message", arg, n);

Selection Dialogs
The other type of Dialog box is Selection Dialog. It has something more than just the OK and
Cancel button of Message Dialogs. Selection Dialogs allows users to interact more than just
clicking a button. It provides option to select different values through a list.
The header file for Selection Dialog is <Xm/SelectioB.h>. One of the routines to create Selection
Dialog is
• Widget XmCreateSelectionDialog (Widget parent, char *name, ArgList args, Cardinal
num_args)
Custom Dialogs
There is a method to create our own dialogs when the dialog functionality provided by Motif is
limited or does not satisfy our requirements. We can either create completely new dialogs or
modify the existing dialogs. One way of customizing existing dialog is by treating the existing
dialog as manager widget and adding children to it that provides additional controls, buttons or
menu bars.
Containers and IconGadgets
The Container is a Constraint Manager Widget designed to work alongside with IconGadget.
IconGadgets are derived from Gadget class that are similar to LabelGadget and is used for
pictorial representation. The Container can layout IconGadgets or its children in Tree, Multi-
column Table, Grid, or Free-Floating formats.

The header file for Container is <Xm/Container.h>. It can be created by using either of the
following code:
 13

• Widget container = XmCreateContainer ( parent, name, resource-value-array,

resource-value-count)
• Widget container = XtCreateWidget ( "name", xmContainerWidgetClass, parent,
resource-value-list, NULL);
To create an IconGadget <Xm/IconG.h> is required. Either of the following block of code can
create IconGadget:
• Widget icon = XmCreateIconGadget ( parent, name, resource-value-array,
resource-value-count)
• Widget icon = XtCreateWidget ( "name", xmIconGadgetClass, parent,
resource-value-list, NULL);
Push Buttons
Push button is subclassed from Label. So, push button can do everything a label can do plus it
can interact with the user. In addition to that push button can invoke functions through callback
routines. The major callback routine associated with push button is the XmNactivateCallback.
This routine is called when the user presses the mouse button. The other routines are
XmNarmCallback and the XmNdisarmCallb which are called when pressing and releasing
respectively.
The header for push button is <Xm/PushB.h>
ToggleButtons
ToggleButton is also subclass of Label and hence inherits the property of Lable Gadget.
ToggleButton represents some kind of application state usually with a Boolean value.

The header file for ToggleButton is <Xm/ToggleB.h> and the code fragment to create it is:
• Widget toggle = XtVaCreateWidget ( "name", xmToggleButtonWidgetClass, parent,
resource-value-list, NULL);
• Widget toggle = XmCreateToggleButton ( parent, "name", resource-value-array,
resource-value-count);
ArrowButtons
ArrowButton is a directional push button. It is a push button but it displays a directional arrow.
There is both widget version and gadget version for ArrowButtons. The header files needed are
<Xm/ArrowB.h>and <Xm/ArrowBG.h> respectively.
 14

References:

http://www.centralconnector.com/GAMES/battleship.html

http://www.ist.co.uk/motif/books/vol6A/ch-11.fm.html

"TCP/IP Sockets in C: Practical Guide for Programmers" by Michael J. Donahoo and

Kenneth L. Calvert