Team Project Development - Department of Computer Science and ...

secrettownpanamanianMobile - Wireless

Dec 10, 2013 (4 years and 6 months ago)


433‐652: Distributed Systems – Principles and Paradigms 
Assignment 2 – Team Project Development 
NOTE:  Please read carefully every section of the document. 
Problem Description 
Design and implement a small distributed system with team project development as a proof of concept 
of the topics discussed during the lectures. In this assignment you will be challenged in working in small 
team  and  coordinate  yourself  to  achieve  a  common  goal:  the  implementation  of  a  distributed 
Three different projects are available: 
• Distributed Ca
r Game Racing 
• Bomberman & Co 
• Distributed White‐board 
Your team has to pick one of these three projects and deliver a complete and working software project 
within the deadline published in this document. 
This  project  is  an  opportunity  for  you  and  your  colleague  students  to  work  collaboratively,  have  fun 
,  learn  about  some  areas  of  software  development  that  do  not  pertain  strictly  to 
distributed  system,  and  get  the  feeling  of  what  it  means  building  a  “software  system”  rather  than  a 
“software application”. 
What You Will Be Asked To Do… 
Applying the Concepts Learnt During the Subject 
Obviously, the main purpose of the Assignment 2 is to get some practical understanding and skills on the 
practice of distributed system development from several aspects: 
• System design and modularization / componentization 
• System implementation and deployment 
• Practical problems in distributed system development 
In  this  assignment  you  and  your  colleagues  are  asked  to  apply  the  concepts  introduced  during  the 
lectures  and  studied  at  home  with  a  real  software  system.  In  particular,  you  are  challenged  with  the 
solution  of  a  new  problem  by  proposing  an  effective  system  design  and  a  working  implementation. 
Particular attention should be given to how to design and develop a system that exposes the properties 
• Openness 
• Transparency 
• Scalability 
• Support for heterogeneity 
• Inherent concurrency 
Additional aspect might also be considered such as security and usability. Since the scope of the project 
is reduced to reasonably challenging distributed application, all these aspect might or might not be fully 
represented.  A  good  suggestion  is  to  take  example  and  guidance  from  the  systems  and  the 
infrastructures presented and discussed in  the  lectures. In particular considerably helpful  might be the 
content  of  Lecture  7  –  Programming  with  Distributed  Objects  where  the  following  technologies  have 
discussed and demonstrated with samples: 
• Java RMI 
• .NET Remoting 
• CORBA (no samples, only overview) 
• Web Services 
Java  RMI  and .NET  Remoting  might  be  for  example  the  candidate  infrastructures  for  designing  and 
implementing the communication component and devising a solution for distributed coordination. 
Moreover, it is expected that at the end of the Assignment you have obtain practical skills together with 
a solid under
standing of the main concepts of Distributed Systems programming. 
Work Collaboratively 
Assignment 2 is a team project. Team as reported by the Oxford English Dictionary is defined as: 
A number of persons associated in some joint action; now esp. a definite number of persons forming
a side in a match, in any team sport; hence, a group collaborating in their professional work or in
some enterprise or assignment.
Therefore  collaboration  is  an  important  component  of  the  assignment.  If  not  experienced  before  you 
will learn… 
• … how to coordinate your efforts with other people 
• … how to divide the set of task to accomplish in reasonable proportions 
• … to discuss the design of a software system with peers 
• … to review
 and develop software together 
• … to interact effectively with people to the things done (…with all that what implies) 
You  will  pick  your  own  team  mates.  This  will  be  the  first  opportunity  for  you  to  put  in  action  your 
organizational and coordination skills.  
One single person is not a team. A team has to be composed by at least two persons and it is expected 
that  there  will  be  an  equal  distribution  of  the  workload  among  the  team  mates.  Try  to  choose  the 
person  you  better  get  along  with  and  that  balances  your  weaknesses  and  completes  the  set  of  skills 
required to do the assignment. 
There  is  a  considerable  problem  solving  co
mponent  in  working  together  other  people,  different 
perspectives  and  positions  on  how  the  tasks  should  be  accomplished  are  quite  common.  You  are 
encouraged to address these issues internally in your team by discussing with your team mates before 
presenting the problem to the lecturer. The lecturer welcomes open discussion about both management 
and practical problems during the time allocated for the assignment. 
Having Fun Doing Your Work 
The  projects  picked  up  for  the  assignment  cover  two  areas  of  software  development:  gaming  and 
graphic programming. These two topics have been chosen because they offer the opportunity of doing 
something  exciting  while  developing  software.  The  overall  goal  of  the  assignment  is  not  to  deliver  a 
perfect,  professional,  and  flawless  software  system  but  a  reasonably  designed  and  implemented 
software system for the time allocated. 
A very important aspect of the assignment is to learn new things and discover how sometimes there is a 
lot of work to be done to make the user experience just “sufficient”.  Gaming and Graphic programming 
(Distributed  White  board)  are  interesting  and  variedly  composed  software  applications  which  expose 
several aspects: 
• User interface design 
• User interaction and feedback 
• Inter‐process communication 
• …. 
These aspects are rarely evaluated and explored in proof‐of‐concept assignment, but still constitute an 
important of the knowledge of a software developer.  
Innovate and Challenge Yourself 
As part of the “having fun” bit of  the  project, be creative:  provide smart designs, innovative solutions, 
and  challenge  yourself  in  doing  something  at  your  best.  In  this  specific  kind  of  assignment,  these 
components will be evaluated a lot and will also contribute to make the assignment more exciting. 
Communicate in Time!!! 
For  any  concern,  question,  aspect  not  completely  understood  feel  free  to  contact  the  lecturer  to  clear 
out  any  issue  in  advance  and  not  the  day  of  the  demonstration.  In  particular,  any  design  or 
implementation issue that you might face, once completely discussed in your team, if still unsolved, has 
to be presented to the lecturer that will do his best to provide appropriate guidance. 
It is also helpful to discuss about your project with other colleague students of other team to confront 
the different solutions devised to common problems. In order to facilitate this process the lecturer will 
open a forum section for Assignment 2 when all of you can post your questions, interact with the other 
students, and ask the lecturer for any issue related to the assignment. 
The lecturer encourages this form of communication in favor of the private mailing. The reason for this 
is  because  a  problem  you  are  facing  could  be  the  same  one  troubling  another  team.  By  having  a 
common space wh
ere to discuss these problems helps everyone and you first.  
In order to monitor the progress of the assignment the lecturer will dedicate time after the lectures to 
address any issue concerning the assignment in person. Make use of this opportunity rather than being 
Project Development & Phases 
Being a considerable amount of work, the project is not suited to be completed autonomously and you 
are  not  left  alone.  The  entire  process  has  been  divided  into  phases  that  allow  you  to  reach  important 
milestones for the successful completion of the assignment. For each of these phases an informal review 
process  will  assess  the  current  status  of  the  project  and  guidanc
e  on  how  to  reach  the  next  milestone 
will be given by the lecturer.  
Phase 0 – Project Opening 
This phase starts today (Friday, 17 September… before midnight). The project is published with all the 
required information to start. During this phase you need to: 
• pick up your team mate(s) … 
• decide what project that you and your team mates want to do in the assignment… 
By Monday 20 September each team has to be formed and the lecturer needs to know for each team 
the following information: 
• Team name 
• Name, email, student‐id of each of the team components 
• Selected project 
At the end of this initial setup phase the team can start developing the project. 
Phase 1 – Project Selection, Investigation, & Design 
In  this  phase  once  you  have  selected  the  project  you  will  initially  do  an  investigation  on  existing 
applications of the same kind to identify what are the features normally implemented in this system for 
their basic functioning.  
For example in the case of the car game, it might be useful to consider other games and see how they 
work (NOTE: you are not required to develop a professional car game, but having the feeling of what a 
distributed  car  game  implies  in  terms  of  usability  and  control  of  the  car  might  be  of  help,  other 
suggestions might come for example for implementing the selection of tracks, cars…), for example some 
car games might be the following: 
• Rural Racer ‐‐Racer_1.html
• Drift Runners ‐‐Runners_3628.html
• Raccoon ‐
• Speed Racer ‐‐Racer_3036.html
• The Need for the Speed 
• Lego Racers 
Obviously the last two games are much more advanced and you are not asked to design and implement 
something like that… unless you want to have fun with 3D engines ready and available to use. 
For what concerns the distributed whiteboard applications such as  
• Mi
crosoft Paint 
• XPaint ‐‐xpaint/
can  be  considered  as  references  in  terms  of  the  functionalities  of  the  application.  These  applications 
might guide you in what is the general user flow and interaction with the application and what are the 
application operations to support. 
At the end of this phase you should come up with a design document containing: 
• brief description of the analysis done (one page not more) describing the features of the existing 
and reviewed applications. 
• a feature sheet / requirement document in which you list all the features that the implemented 
project will support and possible hints on how to do them 
• an iden
tification of the major development tasks for your application. 
• a description of the role of each person in the team and what he/she will do. 
This  document  will  be  part  of  the  final  report  and  will  not  be  lost.  The  better  you  do  it,  the  more  you 
save it later in the redaction of the report. 
Phase 2 – System Design and Initial Development 
The design document will guide you in starting the initial development. The first step of the project will 
be  identifying  the  key  features  and  the  core  elements  of  the  system  from  the  perspective  of 
components building up the system.  
By discussing together with your team mates you will identify the following elements: 
• overall
  system  view  diagram:  it  shows  an  overall  view  of  the  system  and  the  how  the 
components are related (some of the diagrams in the lecture are quite representative for that); 
• collection  of  packages  composing  the  system:  these  can  be  both  your  own  code  modules  or 
external libraries you might want to rely on; 
• class  diagrams  of  the  significant  part  of  the  code:  these  diagrams  will  guide  you  in  the  coding 
phase  and  will  help  you  understanding  or  identifying  major  flaws  while  you  are  implementing 
the project. 
• interaction  diagrams  for  the  most  interesting  aspects:  by  doing  these  diagrams  you  will  be 
showing  the  flow  of  the  application  and  how  the  components  interact  with  each  other  at  a 
lower  level.  Again,  the  usefulness  of  these  diagrams  resides  in  ultimately  producing  a  better 
code and a more solid project. 
This  documentation  will  be  part  of  the  final  report  and  will  not  be  lost.  It  is  also  expected  that  at  this 
stage you will have a clear view of the difficulties of each part of the project and a rough estimation of 
the time need to implement it. Therefore, a roadmap sheet is an important document to produce at this 
stage.  The  document  simply  lists  the  tasks  that  are  required  to  accomplish  the  final  goal  (project 
completion) together with the following information: 
• time frame (start – end) 
• end result 
• person that is in charge of doing it (one or more) 
The  advantage  of  producing  this  document  is  to  help  you  in  continuing  in  a  disciplined  way,  to  keep 
track of the tasks to do, and to have a global view of the distribution of the workload among the team 
An  initial  implementation  of  the  system  might  start  at  this  phase  in  order  to  have  in  place  the  code 
infrastructure. The initial code implementation will help you in creating the above documents. 
Phase 3 – System Development – Stage 1 
In  this  and  the  next  phase  you  will  implement  the  entire  system.  Each  team  mate  will  be  in  charge  of 
doing a specific set of tasks. The documents prepared in Phase 1 and Phase 2 will help you in laying out 
the code and implement the components of the system. 
At  the  end  of  this  phase  the  major  components  of  the  system  are  implemented  and  the  basic 
functionalities as requested by the project specification should be implemented or in a good status.   A 
partially  working  system  should  be  already  available  to  have  a  preliminary  feeling  of  what  the  final 
system  will  look  like.    We  can  break  down  the  software  components  of  each  project  into  two  major 
• core  components:  they  implement  the  core  functionalities  of  the  system  and  characterize  the 
system for what it is. 
• accessory  components:  they  define  accessory  features,  with  perhaps  make  the  system  usable 
but do not define what the system is. 
With reference to the projects proposed we can classify the components as follows.  In the case of the 
car game and bomberman the core components refer to the management of the communication among 
the  computers,  the  control  on  each  application  of  the  various  events  that  change  the  evolution  of  the 
game, the management of collisions, and the basic drawing engine. What it is considered an accessory 
component  is  for  example  the  selection  of  the  car  (avatar),  the  selection  of  the  track  (world),  music, 
etc…. The system will still work even without these features but make the game more interesting. In the 
case  of  the  distributed  whiteboard  core  components  are:  the  management  of  the  sessions
,  the 
communication,  and  the  drawing  features  of  the  application.  Accessory  components  relate  to  any 
enhancement of these features such as advanced options in the application, settings for controlling the 
drawing session, and a chat among the users connected to the whiteboard. 
At  this  stage  the  core  components  should  be  implemented  almost  completely  (70%)  while  accessory 
components should not be there, unless required to enable the use of the distributed application. 
Phase 4 – System Development – Stage 2 
This phase completes the development for the project. This is the time frame in which you can introduce 
innovation  and  provide  the  fun  aspect  of  the  final  application.  Once  completed  the  implementation  of 
the core components and the required features of the system are working it is possible to enhance the 
graphics or so
lve user interaction quirks.  
In this part you have the chance of challenging yourself with improvement and trying to do something 
more  to  make  your  distributed  application  more  appealing.  Please  mind  that  the  core  functionality  of 
the  system  might  be  in  place.  As  an  example,  in  the  case  of  the  car  racing  game  there  it  is  not  a  wise 
choice to spend time in refining the textures used to draw the map if the problem of driving the car has 
not been completely solved yet. The same applies for the distributed whiteboard: if you are not still able 
to make appear the drawings of the remote user on your local screen, it does not make sense spending 
time in designing and fixing up the chat component. 
At the end of this phase the bulk of the code must be completed and fully functional, matching as close 
as possible the supported operation of the design document prepared in Phase 1. The remaining time of 
the project is left for testing completely the system and making it reliable. 
Phase 5 – Project Completion and Wrap Up 
This phase concludes the project and it is characterized by two major tasks: 
• system testing and polishing 
• report / user manual redaction 
The system needs to be tested and reasonably working as expected; ”working as expected” means that 
the  system  has  to  match  what  it  is  written  in  the  design  document  and  expose  the  basic  features  that 
have been listed in the project presentation section of this document. 
For  what  concerns  the  report  a  comprehensive  document  has  to  be  mailed  and  handed  during  the 
presentation that describes the work done and provides a minimal user manual for your application. All 
the  documen
ts  that  have  been  asked  during  the  development  of  the  project  will  be  part  of  the  final 
report/user manual.  
In particular the report has to have the following structure and organization: 
• Abstract:  usually  is  composed  by  one  or  two  paragraphs  with  a  total  of  150  ‐  200  words 
describing the content and the nature of the document. 
• Introduction: provides an overview of the problem context and its additional details about the 
existing  applic
ation  and  solution.  In  this  section  you  can  for  example  discuss  the  following 
aspects: how the application fits in the context of distributed system programming and what are 
the core features of the work done, and the organization of the rest of the document. 
• System Design: this is the most considerable part of the report in terms of content and size. This 
section should detail the organization and the structure of the system, and will make use of all 
the other documents produced during the development of the project: 
o Design document 
o System view 
o Class diagrams 
o Interaction dia
These  documents  can  be  easily  mapped  to  subsection  of  this  section  and  must  be  included  in 
the report.  
• Practical  Issues:  any  comment  and  consideration  about  the  system  implementation  should  be 
put  in  this  section  together  with  the  roadmap  document  that  has  to  be  filled  in  during  the 
evolution of the project. 
• Instruct
ion  for  Use /  Manual:  this  section  will  quickly  review  the  packaging  of  the  application 
and  provide  the  appropriate  amount  of  information  that  is  required  to  start  and  use  the 
application. The general idea is that once the reader has gone over this section is able not only 
to start the applica
tion and comfortably use it. If there are any strange errors that appear while 
executing  the  application  they  should  be  reported  here  together  with  their  meaning  and  a 
solution to them (if there is one). 
• Conclusion:  in  this  section  you  quickly  review  the  major  points  of  the  documents  and  provide 
your  own  th
oughts  on  the  work  done.  Be  critical,  for  example  list  the  major  difficulties 
encountered in doing the project and what can be improved. 
A final package with the entire source code of the application, the report, and all the libraries that have 
been used is the outcome of this phase and conclude
s project. 
It is important to put your details (name, surname, student id) in: 
• the head page of the report 
• as a header in each of the files of the software project 
This  will  help  to  avoid  any  mistakes  in  locating  the  assignment  and  its  components  on  both  sides.  In 
particular  for  concerns  the  report  a  front  matter  should  be  present  with  all  the  details  of  the  team 
member and the subject context. 
In  this  section  you  can  find  additional  details  and  information  that  can  help  you  in  selecting  the  right 
project  to  do  for  the  Assignment  2.  This  section  also  provides  the  information  about  the  expected 
outcomes and the minimal set of wanted features for each of the projects.  
Distributed Car Race Game 
Implement  a  minimal  version  of  a  distributed  car  racing  game.  You  can  think  at  games  like  “Need  for 
Speed” as reference scenario for this project. Obviously the final  outcome you are asked to produce is 
considerably smaller.  
Project Goal 
The ultimate goal of this project is to design a distributed application that enables two players located 
on different hosts to race against each other in real time.  
Each player should have a view of the racing track that is constantly updated with the position of its car 
and the position of the other of the other player. The movement of the cars should be controlled by the 
keyboard  of  the  corresponding  players  and  a  basic  collision  dete
ction  algorithm  should  be  in  place  in 
order to avoid that cars overlap each other or trespass other physical objects such as walls. 
Desired Features 
The following is a list of the required features that the final project should expose. 
• A two
 dimensional view of the car track is the minimum level of complexity required for  what 
concerns the graphical aspect of the project. At least the user interface should show a top view 
of the track together with the cars. If you feel comfortable with graphics programming you can 
 yourself with: 
o a different perspective still (scrolling view) 
o a  three‐dimensional  view  of  the  race  (from  one  perspective  camera)    by  using  a  3D 
engine freely available. 
• The  user  interface  of  the  game  should  show  a  view  of  the  track  and  provide  a  minimal  set  of 
controls such as: 
o start and stop game 
o timin
g, lap, and player information 
additional operations such as a side view of the car position with respect to the entire track (if 
we  use  a  partial  view)  or  the  ability  to  pause  the  game  are  considered  a  plus  not  explicitly 
required. It is expected tha
t is the user quits the game application the race will stop. 
• The cars should move smoothly and not tile‐by‐tile. Turns have to be properly implemented so 
that a realistic (more or less ☺) behavior is perceived by the user.  
• Each  player  should  control  its  own  car  by  means  of  the  keyboard.  The  minimum  functionality 
required is that the player should be able to operate on the car as follows: 
o turn right, turn left, go straight, move backwards (→←↑↓) 
o change speed (accelerate, decelerate) 
additionally it is possible to implement the following operations: 
o change gear (manual) 
o nitro  
and any other feature that can make the control of the car more realistic and exciting. It is not 
expected to have a completely realistic physical model of the car but it is expected that: when 
you press right the car tur
ns right, when you press left the car turns left, and if you do not press 
forward anymore the car decelerates rather than stopping suddenly. 
• A minimal collision detection algorithm should be designed to avoid the most common oddities 
such as: overlapping of cars and trespassing of walls. When the car hits a wall or the other car(s) 
it stops, this is a completely realistic behavior but it is enough for satisfying the requirements of 
the project. 
• The application should implement the ability of starting a race, waiting for at least one player to 
join, and compete. A race is composed by several laps and the applicat
ions should notify on the 
screen each player the outcome of the race (like: you loose! or you win!). 
These  features  cover  the  requirement  for  this  project  and  constitute  the  expected  outcome  of  the 
Design Guidelines 
The  following  points  might  help  you  in  starting  your  project.  They  provide  the  basic  guidelines  for  the 
implementation of the graphics and the architecture of the game. 
• Graphics.  One  of  the  most  challenging  aspects  for  what  concerns  the  graphics  is  the 
management of the movement. In the case of the two dimensional representation of the race it 
is  necessary  to  represent  the  car  in  different  positions  on  the  race  track.  More  precisely,  how 
can  we  make  turn  the  image  of  the  car?  The  easiest  way  for  doing  this  is  to  maintain  all  the 
possible positions of the car inside an array of bitmaps (ad es 16 images, each frame provides a 
rotation of 22.5 degrees of the previous bitmap) and displaying the bitmap of the car that better 
suits the case (which is determined by the input given by the user and the previous position of 
the car).  
• Architecture.  In  order  to  make  the  distributed  car  game  happen  a  simple  client‐server 
architecture  can  be  put  in  place.  A  game  server  will  be  listening  for  incoming  requests  from 
clients  that  actually  represent  the  players  of  the  race.  The  role  of  the  game  server  is  to  keep 
track  of  the  status  of  the  race(s)  and  the  respective  positions  of  players.  The  clients  will 
periodically poll the server on a very quick loop so that the player has the illusion of continuity in 
driving  the  car.  Please  keep  in  mind  that  the  appropriate  concurrency  management  has  to  be 
put  in  place  since  the  game  state  is  shared  among  different  players  and  there  are  concurrent 
connections towards the server. 
• Communication. The set of messages that need to exchanged among the clients and the server 
strictly  depends  on  the  implementation  of  the  protocol  used  to  control  the  game.  It  is 
reasonable  to  assume  that  the  protocol  will  have  at  least  two  classes  of  messages:  control 
messages  (start  –  stop  the  game)  and  data  messages  (position  of  the  car).  A  minimum  level  of 
security is expected to be implemented (for example user name and password). 
• User  experience.  In  order  to  make  the  user  experience  acceptable  a  minimum  level  of 
smoothness  has  to  be  considered.  In  order  to  manage  both  controls  and  real  time  drawing  of 
the racing area a simple loop can be implemented that repeatedly performs these operations: 
1. Get the car position from the server (if there is any race going on) 
2. Draw the background (main user interface, and car track) 
3. Draw the components of the UI that change over time (cars and dashboards) 
4. Collect the user input and if not done before any other command from the server 
5. Perform the operations triggered by the previous step (update car position data) 
6. Repeat the loop if the stop condition is not met. 
Please keep in mind that the clock speed of the computer is very high and as a result the proper 
increment in the position of the car has to be calculated so that the cars do not experience the 
speed light effect. 
By  following  these  guidelines  it  is  possible  to  provide  an  overall  architecture  of  the  distributed 
applications and having a starting point to work on. The review and the analysis of car games that can be 
easily  found  on  the  web  (there  are  various  on‐line  game  website  featuring  car  games  implemented  as 
flash movies) can help you in identifying what are  the other common features and how to enrich your 
 Creativity and Plus 
How can you enrich the car game project and challenge yourself in doing something very exciting? There 
are three different lines along with you can pro
• Introducing more features that make the game a real distributed system. For example a game 
that  can  scale  up  two  more  than  two  players  might  be  an  interesting  option.  Providing  a 
different organization of components of the system where the car models can be uploaded into 
and downloaded from a remote
 repository, which can be browsed on line. Keeping track of the 
scores and publish them with a different service.  
• Providing a more sophisticated user experience. Providing a more realistic model of the car for 
its management and contr
ol. Introducing goodies along the track and obstacles (people crossing 
the track or unwanted obstacles) or power ups. Realistic sound supporting the events occurring 
during the race might be another option. 
• Implementing a three‐dimensional view of the car race. This can be done by relying on one of 
the  several  3D  engines  that  are  freely  available  on  the  netw
ork,  fully  supported  with 
documentation,  and  backed  by  a  large  community  of  people  that  uploads  tutorials,  textures, 
and models. Some of these 3D engines for C# and Java include: 
o Irrlicht [C#,…] ‐
o Java Monkey Engine [Java] ‐
o OGRE [C/C++] ‐
A comprehensive list of the most popular and featured 3D game engines available can be found 
on the DevMaster website (
Distributed Bomberman 
Implement  the  game  bomberman  for  a  maximum  number  of  four  players.    You  don’t  know  what  is 
bomberman? Just google it! From Wikipedia:  
Bomberman  is  a  strategic,  maze‐based  computer  and  video  game  franchise  originally  developed  by  Hudson  Soft.  The  original 
game was published in 1983 and new games in the series are still being published to this day. Today, Bomberman is featured in 
over 60 different games. Being commercially successful, with over 10 million units of games sold, the series "has since become 
known as the first name in multiplayer games".  
The  general  goal  throughout  the  series  is  to  complete  the  levels  by  strategically  placing  bombs  in  order  to  kill  enemies  and 
destroy obstacles. Exploding bombs can set off other bombs, kill or injure enemies and destroy obstacles. However, they can also 
kill  or  injure  the  player  character,  destroy  power  ups,  and  sometimes "anger"  the  exit,  causing  it  to  generate  more  enemies. 
Most Bomberman games also feature a multiplayer mode, where other Bombermen act as opponents, and the last one standing 
is the winner. In this mode, power ups are plentiful.
In  order  to  get  the  feeling  of  the  game  the  plethora  of  on‐line  game  websites  featuring  bomberman 
clones  is  almost  endless.  To  name  just  a  reference  site  provides  a  reasonable  list  of 
bomberman‐like  games  (
)  that  can  be 
evaluated and compared for this purpose. 
Project Goal 
The  ultimate  goal  of  this  project  is  to  design  a  distributed  applications  that  allows  multiple  users  to 
play together a bomberman like maze adventure.  
Each  of  the  players  will  have  the  representation  of  the  game  and  the  position  of  the  other  players. 
 move within the maze tile by tile and can place bombs to break walls and clear out all the level. 
Bombs  are  also  dangerous  for  other  players  that  might  be  damaged  if  they  are  close  to  the  explosion. 
Randomly, in the evolution of the game power ups and goodies can be collected in order to restore the 
  of  the  player  and  accumulate  points.  At  the  end  of  each  level,  the  player  that  has  contributed 
more in clearing up the level is winner of the level. A number of different levels can be provided. 
Desired Features 
The following is a list of the required features that the final project should expose. 
• A user 2D user interface is required to display the game. The point of view might be the top or a 
perspective view as shown in the reference bomberman game  clones. The use of the top  view 
provides a simpler approach with respect to the perspective view. 
• The structure of the game
 level is based on a maze, which is a two dimensional world whose the 
space  is  organized  in  discrete  squares  (tiles).  Some  tiles  are  considered  free  and  other 
obstructed with objects or wall (or similar). The tiles obstructed with objects can be made free 
by dropping a bomb in the tiles nearby. 
• An  avatar  representing  a  player  can  move  along  the  cardinal  directions  (east,  south,  west,  and 
north)  and  proceeds  tile‐by‐tile.  Differently  from  the  previous  game,  the  movement  from  one 
tile to another is discrete from a logical point of view, but can be made continuous to provide a 
better  user experience. An avatar can only move on tiles that are not obstructed  by objects or 
occupied by other avatars. In order to free the obstructed tiles (only some of them) the avatar 
can drop bombs that have a specific “action range” and wipe out everything in the range except 
for  walls.  If  the  avatar  is  in  the  act
ion  range  of  a  bomb  its  life  points  decrease  of  a  specific 
amount.  When  the  amount  reaches  zero  one  life  is  lost.  A  fixed  number  of  lives  is  provided  at 
the beginning of the game when all the lives are lost the avatar cannot play anymore. 
• Bombs  can  be  of  different  nature  and  collected  along  the  way.  As  general  behavior  the  bom

has a timer that determines the countdown to the explosion. This avoids the condition in which 
the  bomb  explodes  as  it  gets  dropped  by  not  letting  the  bomberman  avatar  reach  a  safe 
• Along  the  path  it  is  possi
ble  collect  different  kinds  of  goodies:  bombs,  lives,  power‐ups.  These 
are  the  basic  goodies  that  have  to  be  implemented.  Besides  them,  the  more  goodies  you  add 
the better and exciting the game becomes. 
• The  initial  setup  of  a  game  is  constituted  by  a  condition  in  which  all  the  players  have  an  initial 
number  of  lives,  bombs,  and  points.  As  the  game  evolves  all  these  three  parameters  may 
change. The termination condition of the game for one player is one of the following: 
o The number of lives reaches zero. 
o The last level of the game has been completely cleared out. 
A game is composed by levels. Each level starts with a different maze design and a collection of 
obstacles  on  the  tiles.  When  all  the  removable  obstacles  have  been  cleared  out  the  level  is 
completed,  the  player  that  contributes  more  to  the  clearing  process  is  the  winner  of  the  level 
and gains extra points for starting the next level. 
These features describe the basic behavior of the game and the expected outcome for the project. 
Design Guidelines 
The  following  points  might  help  you  in  starting  your  project.  They  provide  the  basic  guidelines  for  the 
mentation of the graphics and the architecture of the game. 
• Graphics.  The  overall  setting  of  the  game  is  two‐dimensional.  It  is  possible  to  identify  several 
areas for the user interface of the application: 
o Scoreboard. The scoreboard will list the important information about the game such as 
the level number, the current status of all the players, and for the local player additional 
data such as the number of available bombs, the lives remaining, and the list of goodies 
o Level area. The level area is the one that gets refreshed more frequently and it is more 
sensible  of  changes  in  the  composition  because
  of  the  activities  of  all  the  players.  This 
area  is  composed  by  tiles  that  can  be  preloaded  in  memory  and  identified  with  a 
numerical  id.  Hence,  keeping  track  of  the  logical  composition  of  the  maze  at  any  time 
involves the update of a matrix of objects. 
o Other  areas.  Additional  areas  might  be  introduced
  in  the  game  according  to  the  initial 
analysis carried out on the sample games. For example a stats section. 
The  drawing  of  the  user  interface  is  a  repeated  and  timed  with  a  reasonable  clock  allowing 
performing all the operations required to update it. Of a particular interest is the movement of 
avatars  and  the  rendering  of  small  local  animations  that  are  generated  by  the  collection  of 
power  ups,  the  damage  made  by  the  explosion  of  bombs.  These  animations  are  an  additional 
task that is performed together with the whole drawing cycle of the UI and last more than one 
single cycle. 
• Architecture.  From  an  architectural  point  of  view  the  scenario  presented  with  bomberman  is 
quite similar to the case of the distributed car game. Hence, a simple client‐server architecture 
can  be  put  in  place.  A  game  server  will  be  listening  for  incoming  requests  from  clients  that 
actually represent the all the possible players. The role of the game server is to keep track of the 
status  of  the  game  and  the  respective  positions  of  players.  The  server  is  also  in  charge  of 
updating  the  maze  with  random  power‐ups  and  goodies  for  the  avatars.  The  clients  will 
periodically poll the server to get this data and update their local view. Differently from the car 
game  race,  in  this  case  the  client  push  more  information  that  the  simple  position.  In  fact,  the 
possibility of dropping bombs alters the composition of the maze and this information, together 
with  its  consequences,  needs  to  be  passed  to  all  the  clients.  Please  keep  in  mind  that  the 
appropriate  concurrency  management  has  to  be  put  in  place  since  the  game  state  is  shared 
among  different  players  and  there  are  concurrent  connections  towards  the  server.  Finally,  the 
general interaction for the game can be the following: the server opens a game session as soon 
as a first request is issued by one of the players and the system will start a waiting time in which 
other players might join the game. Once the waiting time expires, the game starts. 
• Communication.  With  respect  to  the  car  racing  game  the  set  of  messages  that  need  to  be 
exchanged between the client and the server is more varied and heterogeneous. It is reasonable 
to  assume  that  the  protocol  will  have  at  least  two  classes  of  messages:  control  messages  and 
data messages In this case the data messages will be more complex since not only the position 
and  the  status  of  the  player  has  to  be  updated  but  also  the  goodies  and  bombs  have  to  be 
• User  exp
erience.  In  order  to  make  the  user  experience  acceptable  a  minimum  level  of 
smoothness  has  to  be  considered.  In  order  to  manage  both  controls  and  real  time  drawing  of 
the  user  interfacea  simple  loop,  similar  to  the  previous  case,  can  be  implemented  and 
repeatedly perform
s these operations: 
1. Get the updated map from the server. 
2. If  there  are  new  objects  that  involve  any  animation  put  them  into  the  animation 
3. Draw the background (main user interface, maze according to the retrieved map) 
4. Draw  the  components  of  the  UI  that  change  over  time  (avatar  positions  and 
5. If  there  is  any  object  in  the  queue
  perform  one  step  of  the  animation  for  each  of 
them and remove those that have completed the animation cycle. 
6. Collect the user input and if not done before any other command from the server 
7. Perform the operations triggered by th
e previous step 
8. Repeat the loop if the stop condition is not met. 
Please keep in mind that the clock speed of the computer is very high and as a result the proper 
increment in the position of the car has to be calculated so that the avatars do not experience 
the speed light effect (unless wanted). 
By  following  these  gui
delines  it  is  possible  to  provide  an  overall  architecture  of  the  distributed 
applications and having a starting point to work on. The review and the analysis of bomberman clones 
and reference implementations can help you in refining this architecture. 
Creativity and Plus 
The  possibilities  of  improving  and  innovate  the  bomberman  application  might  be  picked  up  from  the 
huge variety of clones that can be found on the web. As happens for the previous project it is possible to 
innovate and explore new things along three dimensions: 
• Introducing more features that make the game a real distributed system. Keeping track of the 
scores and publish them with a different service. Providing a sort of market at the end of each 
level  where  the  players  can  trade  their  goodies.  Implementing  a  repository  of  the  stats  of  the 
players that gets updated as the game proceeds and exposed as a different service. These might 
be options that you want to investigate. 
• Providing  a  more  sophisticated  user  experience.  Providing  a  more  refined  rendering  of  the 
maze and the animations triggered by the collection of power ups and goodies or the explosion 
of bombs. Introducing a maze editor. Realistic sound supporting the events occurring during the 
race might be another option. 
• Implementing a three‐dimensional view of bomberman. This can be done by relying on one of 
the  several  3D  engines  that  are  freely  available  on  the  network,  fully  supported  with 
documentation,  and  backed  by  a  large  community  of  people  that  uploads  tutorials,  textures, 
and models. Some of these 3D engines for C# and Java include: 
o Irrlicht [C#,…] ‐
o Java Monkey Engine [Java] ‐
o OGRE [C/C++] ‐
A comprehensive list of the most popular and featured 3D game engines available can be found 
on the DevMaster website (
Please  note:  bomberman  is  essentially  a  2D  maze  adventure  that  requires 
you  to  have  always  available  a  view  of  the  entire  maze  in 
order  to  decide  the  best  move  to  make.  In  case  of  a  three 
dimensional  representation,  most  likely  a  partial  view  of  the 
system  is  give,  hence  a  miniaturized  and  simplified  two 
dimensional view of the system need always to be included in 
the layout. 
For what concerns the development of this and the previous project an interesting reference might be 
the following:
. The book is focused on Java but the concepts 
can be easily applicable in the .NET scenario since there is a strong similarity between the APIs and the 
programming languages supported. 
Full reference of the book: 
David Brackeen, Developing Games in Java, ISBN: 1592730051; Published: Aug 21, 2003, InfomIT Press. 
Distributed Whiteboard 
Implement  a  distributed  White‐board  allowing  user  located  on  different  host  to  share  a  common 
drawing area. The reference scenario in this case could be applications like Microsoft Paint or XPaint for 
what concerns the operations supported. 
Project Goal 
The ultimate goal of this project is to design a distributed application that enables a number of clients 
located on different hosts to visually interact on a shared whiteboard.  
The whiteboard is a common drawing pane on which all the users can perform the basic operations that 
can be done in the reference applications such as drawing lines, curves, circle and figures, filling regions, 
free  drawing,  and  edi
ting  text.  Each  client  should  be  updated  in  real  time  with  the  result  of  the 
operations of the other users so that the content of the whiteboard is the same for all the users. 
Desired Features 
The following is a list of the required features that the final project should expose. 
• The com
mon user interface of a drawing program should be implemented. MS Paint and XPaint 
) are good references for the main layout of the GUI. 
• There  should  be  two  different  roles  in  the  distributed  application:    whiteboard  administrator 
and whiteboard user. The former is the online that creates the whiteboard and therefore owns 
it,  the  latter  identifies  all  the  other  users  that  can  join  a  session  and  interact  through  the 
whiteboard  created  by  the  administrator.  The  administrator  has  complete  power  over  the 
whiteboard that has created and can limit the operations of each user and kick them out of the 
session. Users can leave  when they want, if the administrator leaves the whiteboard session is 
ed and all the users are notified. 
• The following operations need to be supported for what concerns the user interaction with the 
o Drawing of basic shapes such as: straight lines, rectangles, circles, points. 
o Using a empty and filled mode for shapes. 
o Support for colors: at least 16 colors should be supported. 
o Text edit
ing: the whiteboard should support the ability of entering text and selecting the 
font (it might be that different clients can have different installed fonts, it is ok to limit 
the set of selectable fonts to the most common ones). 
o Freehand drawing. 
o Erase tool. 
Advanced operations that
 are considered a plus are the following: 
o Support for image embedding. 
o Advanced color management (using gradients). 
o Cut and paste features. 
o Selection tool. 
Applications such as Microsoft Paint can provide you with other drawing operations you might 
want to include. 
• A File Menu should be present allowing you to perform the following operations: 
o New – creates a new whiteboard 
o Open – open an existing whiteboard (a project file, or an image) 
o Save / Save as – saves the current whiteboard 
o Close – close the whiteboard session 
o Exit – exit from the application 
There  might  be  other  menus  of  use.  Again,  having  a  look  at  what  is  implemented  in  the 
reference programs can be of helps in identifying the overall set of features that are needed. For 
what concerns the behavior of the operations exposed in the menu a different behavior has to 
be  implemented  if  the  whiteboard  is  in  “user  mode”  or  “administrator  mode”.  Only  the 
administrator  can  close  a  whiteboard  session,  and  if  he
  or  she  exits  from  the  application  the 
session  gets  closed  (all  the  open  sessions  controlled  by  him  or  her).  If  the  user  exits  the 
application simply leaves the session. 
• A user list needs to be maintained in the user interface so that each of the user contributing in 
the whiteboard can see who are the peers. The administrator needs to be clearly identified and 
he is the only one that has administrative capabilities on the user list and the whiteboard. 
These  features  cover  the  requirement  for  this  project  and  constitute  the  expected  outcome  of  the 
Design Guidelines 
The  following  points  might  help  you  in  starting  your  project.  They  provide  the  basic  guidelines  for  the 
implementation of the graphics and the architecture of the game. 
• Graphics.  Even  in  this  project  the  graphical  aspect  covers  an  important  part  of  the  entire 
project. A general infrastructure for laying out GUi applications is given by different toolkits. In 
particular for the Java programming  language we can mention: 
o Pivot ‐
o Thinlet ‐
o SWT ‐
o Swing – (Java distribution)  
In case of C# based applications you can consider the following GUI toolkits: 
o Windows Forms – (.NET & Mono distribution) 
o GTK# ‐ http://www.mono‐
These  frameworks  provide  complete  support  for  GUI  design  with  a  huge  collection  of  widgets 
ready to use for building user interfaces.  
• Whiteboard management. The most important aspect of the graphic component of the project 
is the management of the rectangular surface that represents the whiteboard. Both the Java and 
the .NET  framework  provide  developers  with  all  the  basic  features  for  developing  the  basic  2D 
operations  (lines,  curves,  circle,  ovals,  rectangles,  paths,  filled  regions,  and  gradients),  these 
primitives provide an straight mapping for the operations that are required by the whiteboard. 
A  particular  attention  has  to  be  given  to  the  synchronization  of  the  operations  on  the 
whiteboard  and  a  specific  policy  on  how  the  whiteboard  and  the  corresponding  surface  has  to 
be  drawn  needs  to  be  implemented.  A  naïve  implementation  that  solves  the  problem  is  for 
example the introduction of a policy for obtaining the right of modifying the whiteboard before 
drawing. Another option is simply scheduling the different operations on the fly. 
• Architecture.  The  specific  architecture  for  the  distributed  whiteboard  can  vary.  Both  the  peer 
and  the  client‐
server  model  are  allowed.  The  peer  model  provides  a  decentralized  approach, 
while the client‐server model identifies one distinctive role that in this case can be played by the 
host that administers the whiteboard or a separate server. The case of using a separate server 
for  managing  all
  the  sessions  provides  a  more  symmetric  approach  for  what  concerns  the 
development of the administrator and user roles. 
• Communication.  Similarly  to  the  previous  two  projects  it  is  possible  to  identify  two  different 
classes of messages: management and control operation that are concerned with the users and 
the  whiteboa
rd  session,  and  drawing  operations  that  will  constitute  the  bulk  of  the 
communication.  In  each  client  will  at  least  have  two  threads:  one  for  the  communication  and 
the  other  one  for  the  user  interface,  as  discussed  in  the  previous  point  a  minimum  level  of 
synchronization is required to properly update the whiteboard (the producer consumer case can 
be  considered  as  a  good  starting  point).  Differently  from  the  previous  examples  there  is  no 
synchronous  virtual  clock  to  rely  on  for  controlling  the  entire  set  of  interactions.  Hence  an 
event‐based  mechanism  for  communication  might  be  more  suitable.  Moreover,  a  minimum 
 of security needs to be present. 
By  following  these  guidelines  it  is  possible  to  provide  an  overall  architecture  of  the  distributed 
application  and  having  a  starting  point  to  work  on.  Again,  to  consider  how  to  develop  a  better 
application, consider evaluating tools like Microsoft Paint and XPaint. 
Creativity and Plus 
How can you enrich the distributed whiteboard application? How can you make it more interesting? It is 
possible to introduce advanced features on two major aspects of the system: 
• Focusing  on  the  distributed  nature  of  the  whiteboard.  For  example  strengthening  the 
management of conflicting updates of the whiteboard more nicely without requiring the user to 
hold a lock for drawing on the whiteboard. If you want
 to provide a stackable undo operation for 
all the operations performed on the whiteboard the management of conflicting updates become 
really important and also constitutes a good exercise in the practice of managing concurrency in 
distributed systems. Moreover, more than in the previous two cases, security is a major concern 
here because the whiteboard might contain sensitive content that need to be secured. Specific 
policies controlling the access to the whiteboard might be put in place. 
• Enhancing the user experience and supporting additional features. The guidelines given in the 
desired  features  section  just  provide  an  implementation  that  covers  what  it  is  expected  as 
outcome. You can think about adding other features such as: 
o Support for undo operations and keeping track of the history. 
o Introducing a chat associated to the whiteboard allowing all the peers to communicate 
with  each  other  and  also  the  ability  of  create  private  sessions  with  one  peer  or  more 
(chat rooms). 
o Supporting multiple whiteboards within the same applications in both administrator and 
user mode. 
These are just simple ideas but your creativity is welcome to innovate the project and challenge 
yourself individually and as a team. 
Project Timing & Deadline   
This  section  sums  up  the  milestones  that  have  been  identified  in  the  Section  2  together  with  the 
outcome at each of the phases and the soft deadlines for each phase. The term soft deadline identifies 
the  fact  that  the  milestone  is  expected  to  be  completed  by  that  date;  any  exceptional  condition  that 
might delay the in
termediate assessment will not be marked down.  
Date Due 
Status and Deliverables 
0 – Opening 
20 Sept 2010 
Team formation and project selection 
1 – Investigate 
30 Sept 2010 
Background formation, sample analysis, and requirements 
2 – Design 
7 Oct 2010 
System design, component, class, and interaction diagrams 
3 – Devel : S1 
14 Oct 2010 
Implement the bulk of the system, core components 
4  – Devel : S2 
21 Oct 2010 
Finish up implementation, core and accessory components 
5 – Completion 
28 Oct 2010 
Testing completed, code completed, report completed 
4‐5 Nov 2010 
Show your work. 
Table 1. Milestones and Deliverables. 
The deadline for submitting the assignment is: 15 November 2010. This is a hard  deadline. It identifies the 
deadline  of  the  project.  Failure  to  submit  the  project  by  the  date  specified
  above  will  incur  in  a 
deduction of marks as specified by the marking scheme. 
Final Packaging & Delivery 
The assignment must be handed to the lecturer at the following email address: ( 
A zipped file containing the following directory structure is expected: 
• <directory>  src (containing all the source code and eventually instruction on how to compile it) 
• <directory>  report (containing a pdf file) 
• <directory> build (containing an executable version of the software, compiled and ready to use) 
• <file> readme.txt (if you need to give additional instruction information) 
The zip file must be named with the team name. (<team‐name>.zip). 
If  the  project  appears  to  be  too  big  for  the  email  it  is  possible  to  hand  in  the  zip  file  directly  to  the 
The  marking  process  will  be  structured  in  two  major  areas  that  summed  together  will  give  the  final 
mark. The two areas cover what is expected as final outcome and what can be done as a plus. 
1. Core – 24 Points. 
The  core  section  covers  what  is  expected  and  defined  in  the  “Desired  Features”  section  of  each 
project  plus  the  specification  given  in  the  Project  Development  &  Phases ,  Final  Packaging  & 
Delivery, and Project Timing & Deadline sections. More precisely the elements that will be evaluated 
in the overall score for this section are the following: 
• Code – 14 Point

The  code  section  includes  several  aspects  that  have  to  be  kept  in  mind.  The  lecturer  will 
evaluate the following components as part of the code section:  
o working prototype
 in all of its requested aspects; 
o quality of code
 in terms of design of classes and algorithms, components used; 
o code  documentation
  (in  methods,  and  as  part  of  the  process  automatic  help  file 
generation by using javadoc (Java), doxygen (C++/C#/Java), or sandcastle (C#)); 
The  code  section  scores  up  to  more  of  the  50%  of  the  entire  core  value,  this  reflects  the 
importance  of  having  an  application  working  and  well  designed  from  the  perspective  of 
distributed systems progra
mming and software engineering. 
• Report – 7 Points 
The report section is another fundamental component of the work team project work. With 
the  report  the  team  will  show  its  capability  as  a  group  in  providing  an  organic  document 
addressing  all  the  aspect  of  the  collaborative  development  undertaken  during  the  project. 
The  report  also  shows  your  understanding  of  the  problem  and  it  is  the  first  interface  to 
evaluate the work done. What it is helpful in making a good report is documenting with the 
appropriate  diagrams  and  as  indicated  the  work  done.  In  particular,  the  following  aspects 
will be considered: 
o use  of  the  appropriate  and  requested  structure
  (does  the  report  have  all  the 
sections that have been requested?); 
o use  of  the  appropriate  diagrams  to  document  the  design
  (component?  class?  and 
o quality of the content
 in term of organization of the diagram and sections; 
o usefulness
  (is  the  Manual/  Instruction  for  Use  section  enough  for  autonomously 
using the software system?); 
A well written report including addressing all the features above will score all the marks. 
• Timeliness – 2 Points. 
Has been the assignment handed in time? “In time” means before the deadline. If there is 
deadline extension that applies to every team the new deadline becomes the new time limit 
for considering the assignment handed in time. The marks deducted for not submitting the 
assignment  in  time  increase  the  more  the  time  passes:  within  one  day  late  0.5  marks  are 
deducted; between 1 and 2 days late 1 mark; and so on. 
• Compliance – 1 Points. 
The  compliance  score  component  is  intended  to  evaluate  minor  but  still  important  aspect 
for successfully completing the assignment. In particular, has been the  project handed in a 
zip  file  as  requested  and  with  the  requested  structure  and  file  format?  Meeting  the 
compliance requirements is a very simple task and it is a good way to balance some lacks in 
other sections. 
These  four  features  allow  you  to  score  up  to  24  points,  if  successfully  completed  and  perfectly 
matching th
e criteria defined. 
2. Plus – 6 Points. 
The  plus  part  covers  the  innovation  aspect  and  the  implementation  of  the  additional 
features  not  included  in  the  core  but  suggested  in  the  presentation  lecture  and  reported 
here  in  the  document  for  each  of  the  projects  presented.  The  breakdown  of  this  score 
component is not defined yet and will be finalized before time.  
By  summing
  the  two  major  sections  of  the  marking  scheme  the  total  points  that  can  be 
obtained with a perfect, flawless, and innovative project is 30 points.  
Few helpful hints 
1 ‐ Core 
Did we do all that was requested as mandatory? 
1.a – Code 
It is a working system? What about documentation? 
1.b – Report 

It is complete and organized as asked? 
1.c – Timeliness 

Within the agreed deadline with all the teams? 
1.d  – Compliance 

Does the deliverable have the appropriate file format and organization? 
2 – Plus 
Did we challenge ourselves in introducing the suggested additional features? 
Total Score 
Did we do all that was asked and more? 
Table 2. Marking Scheme Breakdown.
The  table  above  reports  a  sum  up  of  the  marking  scheme.  The  question  asides  the  score  components 
will  quickly  help  you  in  reviewing  the  entire  project  (code,  documentation,  and  other  aspects)  before 
submitting and check if everything has been carried out as expected. 
Demonstration Schedule and Venue  
The  team  is  required  to  provide  a  demonstration  of  the  working  application  and  will  discuss  with  the 
lecturer  the  design  and  implementation  choices  made  during  the  demo.  By  that  time  the  lecturer  has 
already read the report and the student will have 15‐20 minutes to provide a complete demonstration 
of the working system.  
You  are  not  allowed  to  make  any  change  to  the  report  and  the  code  in  the  period  of  time  lasting 
between the submission of the assignment and the demonstration day.  
Two days will be sc
heduled for demonstrations in order to accommodate everyone: 
The venue is Lab 2.17 (level 2, at the right corner of the building entering from the main entrance). The 
team  members  are  free  to  develop  their  system  where  they  feel  more  comfortable  with  (at  home,  on 
one pc, on your laptop, in the labs...) but the project is meant to be a distributed system that works on 
at least two different machines in order to separate the client from the server. PLEASE, once you have 
completed  the  assignment  (at  least  the  first  60%)  come  to  the  university  labs  and  check  it  there.  Lab 
2.11 is accessible for this purpose. 
After the submission of the assignment, a schedule for the demonstration will be published on the LMS 
website.  And  a  booking  process  for  a slot  will  start  in  order  to  have  a  complete  schedule.  The  lecturer 
will start filling the first day and then proceed to the second one if someone is not able to come on the 
first day. Please note that all the team members have to be present at the demonstration since they 
will be asked questions about the components developed. 
Rules and Tips 
This  section  describes  practical  aspects  of  projects  development  together  with  some  major  rules  that 
need  to  be  followed  for  successfully  completing  the  project.  The  section  is  organized  in  common 
questions that you might ask yourself or the lecturer. 
1. What language/technology should I use? 
The assignment can be implemented in one of the following languages: 
• Java 
• C# 
• C++ 
There is no privileged choice of language, please use the one you are more proficient and comfortable 
with. Mind that in the lectures I have shown examples with Java and C# (more will be posted on the LMS 
for C# and Java). This does not make
 Java or C# preferred, but the fundamentals for these two languages 
have been given so that the assignment can be accomplished. 
Regarding  the  technology  or  the  specific  infrastructure  to  use,  you  are  free  to  use  any  of  the 
technologies  and  paradigms  introduced  in  the  lectures.  In  particular,  for  what  concerns  inter‐process 
communication  the  following  have  been  discussed  in  the  lectures,  together  with  working  samples  for 
you  to  start  on:  Sockets,  RMI,  Remoting,  and  Web  Services.  It  is  expected  that  you  use  one  of  these 
technologies and not a fancy framework that does everything for you. At the same time you are free of 
using  any  other  library  that  might  simplify  the  developmen
t  of  those  aspects  that  are  not  relevant  to 
distributed  systems  programming.  For  example  you  are  free  to  use  a  3D  engine  to  enhance  the  user 
interface of the application if you want.  
Should any concern about whether to use a specific technology arise, please contact the lecturer and 
ask him whether that specific technology is allowed. 
2. To which extent should I leverage libraries and third party software? 
The  project  has  to  be  mostly  composed  by  the  software  components  developed  for  the  project. 
Additional  libraries  can  be  used  as  long  as  they  do  not  simplify  and  completely  manage  the  important 
aspects of a distributed system. Any other framework and technology that can be used to enhance and 
provide non‐core features can be used. 
 good example is the case of the car game: using a 3D engine for enhancing the user experience of the 
car  driving  is  an  option  that  you  may  want  to  consider  and  not  prohibited.  Using  an  infrastructure  for 
inter‐process communication that is not in the one listed above is not allowed. 
3.  Will the lecturer help me during the project? 
Yes the lecturer will help you. Keep in mind that the project has to be the production of you and your 
team. This means that 
• the overall design needs to be done by the team 
• solutions to the problems have to be provided by the team 
• the code must be developed by the team 
The  role  of  the  lecturer  in  the  team  project  is  limited  to  supervision  of  the  work  and  guidance.  The 
lecturer can help you in seeing the things from a different perspective, avoid that the team takes a dead 
path,  and  give  you  hints  for  solving  specific  and  practical  issues.  Ultimately  the  responsibility  for  what 
decision to take and what to do belongs to the team. 
4. How the intermediate assessment will take place? 
At the end of each of the phases discussed in this document an informal meeting will take place with the 
lecturer  and  a  brief  overview  of  the  work  done  will  be  done.  The  intermediate  assessment  is  not 
intended to be of support of the final marking but has been introduced in order to provide guidance and 
support for the teams during the project. The main purpose is to avoid that a team takes a direction that 
is too complicated or a dead end and this is discovered too late. 
5. Can I change team during the evolution of the project? 
Teaming up for the Assignment 2 is like marriage, divorce is just the last thing you want. Once you have 
chosen your team mates you are not allowed to switch team or leave unless very serious concerns arise 
with your team mates. 
Leaving  a  team  involves  several  issues:  relocating  the  student  with  another  team,  dealing  with  the 
intellectual  property  that  is  transferred  from  one  team  to  another,  etc.,  etc..  In  order  to  avoid  these 
issues the change of team is not allowed. 
6. How long the report should be? 
There  is  no  fixed  length  for  the  report.  A  general  rule  of  thumb  is  the  following:  as  long  as  the  report 
contains all the information that have has asked with the reasonable degree of detail, the lecturer will 
be satisfied with that. A report structured and containing the information requested will easily fill up 10 
to 15
 pages considering the fact that diagrams and screenshots could take some space. Again, this is not 
a strong requirement: a good report containing all that is needed and nicely written with shorter than 10 
pages is appropriate.  
The  report  will  be  read  by  the  lecturer  and  it  is  part  of  the  final  evaluation.  Since  all  the  reports  are 
carefully read and time is dedicated to it, please consider the right amount of time in writing it. 
7. What about code documentation? 
Code  documentation  is  an  important  part  of  the  project.  It  is  what  actually  makes  the  project  usable 
without  your  support  and  potentially  extendible  with  additional  features  in  the  future.  The  samples 
posted  on  the  LMS  provide  a  clear  example  of  what  is  the  expected  documentation  for  the  software. 
Source  code  without  documentation  will  be  considered  incomplete.  It  is  you  option  whether  to 
produce  the  javadoc  files  or  the  equivalent  documentation  in  C#/C++,  the  lecturer  strongly 
recommends it. 
8. We have lost X marks for this banal thing… it is unfair! 
There are some elements in the marking scheme that allow the team to easily get few marks. The tasks 
associated  to  these  elements  are  banal  and  do  not  require  any  intellectual  effort.  These  marks  can 
balance some flaws and lack in other elements, and they ultimately help you rather then penalize you. 
Examples are: providing
 the proper structure of the report (filled with names, and all the listed sections), 
the  structure  of  the  final  package  to  deliver  (directory  structure,  and  organization  of  content),  and 
providing the documents discussed in the proper format. These tasks can be easily done.  
9. We  have  implemented  several  cool  features,  but  the  project  lacks  in  the 
major features listed in the project presentation section…. 
As  discussed  in  the  earlier  section  the  core  functionalities  need  to  be  implemented  in  order  to  move 
forward  and  provide  the  additional  features.  A  project  very  good  looking  but  lacking  in  the  core 
functionalities will not be evaluated as successful. 
10. I have done a good job but my team mate has brought my marks down.. 
The reason why each member of the team is asked to state its contribution in the report is to allow the 
lecturer  to  assess  the  work  done  by  each  student  as  most  effectively  as  possible.  On  the  other  hand, 
since  the  teams  have  been  decided  by  the  student  themselves  it  is  your  responsibility  to  choose  team 
mates who you can rely on and that
 are helpful to successful completion of the project. 
Final Observations 
This  document  provides  a  comprehensive  overview  of  what  it  is  asked  and  required  to  perform 
successfully Assignment 2. In preparing this document a particular attention has been given in trying to 
cover all the possible issues that the team might face during the development of the project both from a 
practical and organizational point of view.  
These  specifi
cations  provide  you  with  guidance  on  how  to  structure  the  project,  organize  the  time 
allocated  to  it,  and  what  to  consider  more  important.  With  respect  to  Assignment  1,  this  assignment 
requires  considerably  more  effort,  but  it  also  cover  a  more  interesting  and  exciting  aspect  of  software 
t than the simple creation of a proof‐of‐concept exercise.  
A  final  recommendation  is  to  try  to  take  out  the  most  from  it  in  terms  of  what  you  can  learn  about 
working in team, new areas of software not covered during the lectures, and time management. 
FINAL NOTE:  This document might be subject to change in some of its parts 
as  a  follow  up  of  the  meeting  with  the  teams.  The  changes  introduced 
might  mostly  cover  the  relaxation  of  some  constraints  as  a  result  of  an 
overall  slow progress  in  carrying  out  the  work  for  the  project  and  meeting 
the milestones. These changes are meant to help you and not damage you. 
These  specifications  are  available  on‐line  in  the  LMS  under  the  content 
section  allocated  for  the  652  subject  (folder  Assignment  2).  Updated 
version  of  the  document  will  be  published  as  revisions  of  the  document 
(different version number, automatically generated by the LMS). Therefore, 
it  is  YOUR  RESPONSIBILITY  to  constantly  check  the  LMS  (652  subject)  for 
updated  versions  of  this  document  and  listen  to  the  lecturer  during  the 
lectures, so that you can take advantage of these changes. 
The document has been published on Friday, 17 September 2010.  
Christian Vecchiola