CM10228 / Programming Ib:   Assignment 2  (2011)

Networking and Multiple Clients in the Dungeon

Assignment Date:  Tuesday,  1 March  Due date:  Thursday,  22 March at 10:00 AM (Moodle) Also demoed in Lab 22-25th March

This assignment is the second of four you will have in this course.  Your mark in Programming Ib is composed of 50% coursework, 50% exam.  This assignment is worth 10% of your final mark for the unit (but should take you less time than CW1, see below). The assignments are:


Handed Out
Labyrinth of Dooom: Exploring the Labyrinth 15%
14th February
6 March
Labyrinth of Dooom:  Networking and multiple concurrent agents in one dungeon 10%
8 March
22 March
Demoed in lab 22-2 March
Labyrinth of Dooom:  GUIs to show your friends & family 25%
20 March
17 April
Demoed in lab 17-23 April



This assignment brings you further adventures in the Labyrinth of Dooom. The second coursework emphasises networking and concurrency, as well as being able to read and adapt other people's code.

You will be given the code for a working, single player version of the Labyrinth of Dooom. Your task will be to connect the command line interface ( to the game logic ( over a network. The objective of the game is still to gather enough gold that you are able to exit the dungeon, and then to exit it. However, now there will be multiple players in one dungeon, so there may be some competition for that gold. Note that the rules of this game are slightly more complicated than those of your first coursework. These rules can be found here. The primary objective of this coursework is to introduce you to networking and concurrency.

  1. Networking: You will create a client-server version of the Labyrinth of Dooom.
  2. Concurrency: You will be able to play either with or against your bot in the same dungeon. You should also be able to support your friends and their bots joining you in the dungeon.

This coursework is meant only to ensure that you are competent at networking, concurrency and also error checking, in advance of your third and most significant coursework, which will use GUIs. However, there is one minor AI goal of this coursework:

This coursework will be marked entirely in the laboratory. There you will provide a demo, and if your networking & concurrency work, we will ask you to find your bot in the dungeon. You will have an opportunity to demonstrate an interaction with your bot (e.g. hurting it or helping it), but this must be quick. The demo should be just 5 minutes total, including starting up the server and clients.

You will not get detailed feedback on your code in this coursework. You will be demoing your coursework in lab on the week of 22th March, and will receive your mark then. Note that we are not asking for any documentation of your requirements-gathering & design phase for this coursework, but you may find that doing these properly still helps you perform your task, regardless of whether anyone looks at the output. You may also want to show a spec to the tutors in lab in the early stages of development, just to get feedback about whether you are on the right track.

Warning: If you are assigned to Monday's lab, you will be reallocated to another laboratory for marking the week of 22th March only. You should attend laboratory on 14th March to receive your allocation.

You are encouraged to use the eclipse IDE in programming and debugging your code. However, your code must run from the command line. This is how we will be marking it. The code should be platform and operating-system independent. It should run in Java 1.6. To be safe, you should probably test that your code works on one of the BUCS servers (At time of writing LCPU has Java 1.6 and Amos, Mary, Midge have Java 1.5)

This assignment is expected to take the average student (one who got about 58 in Programming I) about 15 hours. As mentioned in class, this is a double unit, so it is expected you spend at least 12 hours a week of self-study on the course, besides the two hours in lab and the two hours in lecture. We expect you will spend about 7.5 self-study hours a week for the next two weeks on this assignment, in addition to the two hours you have in lab. (Notice this still leaves you plenty of time for lecture preparation.) Because programming takes different people radically different amounts of time, some students will spend something more or less than 15 hours on this assignment.

An important note on plagiarism: Plagiarism occurs any time that you use someone else's ideas without acknowledging them. Plagiarism is much, much worse than asking for help -- in fact, asking for help isn't bad at all. If you get help on any part of your assignment you should acknowledge this in the comments. This includes asking coursemates, tutors, or other staff questions, and of course any code or ideas you get from books or the Internet. Say exactly where your ideas came from, and exactly how much of the code you hand in is your own.

What to do:

Note: You need to do all these steps to make sure you get full marks. You can probably pass this coursework if you only get as far as 3 or 4, but do a very good job on these. See below on how you will be marked.

  1. Seperate out the code that you have been provided with into a server and a client. the networking code should be created in a class that is separate from the files you have been provided with.
    1. See the lecture notes on networking -- you are free to copy code from them, provided the source is properly acknowledged.
    2. Change as little code as possible.
      1. Networking does not have to be hard -- it is not that different from using streams like STDIN and STDOUT.
      2. We're not carefully reading your code this time.
  2. Create a client using PlayGame. The client & server should communicate using the strings provided in the protocol document. Be sure to have the client also print things out to your terminal screen, so you can see what you are doing when you play the game.
  3. Debug your new client & server.
    1. This may be hard -- be sure to do this in good time so you can take your code to lab if necessary & get help from the tutors.
    2. You will probably want to write some test code to make sure that your client & server are doing what you think they should.
  4. Improve your server to take multiple clients. Note that you will want to protect access to your map (and any other shared data) via either sychronize or using semaphores.
  5. Make your Robot from CW1 (or the one that we have provided if you prefer) into a client too.  This should be easy if you have already made your other working client, as you can reuse code.
  6. Modify your bot to make sure it is playable (see earlier in the spec).
  7. Practice your demo in advance of the tutorial.
  8. Invite some of your coursemates to try their clients on your dungeon, so you can be certain that you got the protocol right.

What to hand in:

Submit on Moodle a file named <yourUsername> or <yourUsername>-coursework2.tar.gz
  1. Note: For this coursework you do not need to physically hand anything in. You need to upload your code to Moodle in order to demonstrate that you have met the deadline. You should also bring your code to the lab you have been assigned marking in so that tutors can help you debug it.
  2. You should upload a zip (or tarball) containing uncompiled versions of your code
  3. In your demonstration, you should be able to connect your bot to your dungeon, leave it running, and enter the dungeon yourself through your client.
    1. If you don't get as far as the bot, you can still give a demo just with your own client.
    2. Your demo should be five minutes long, including starting up the server & clients. You should practice this.
    3. You will get a few marks for interacting with your bot in some way (see mark sheet.)
    4. The tutor will also be connecting a client to your server, so you must maintain the standard protocol.
Upload the file to Moodle by the time specified. Failure to name your submission file correctly will incur a penalty. Remember, marks are not given just because your code compiles and runs. It should run robustly, and it should be well commented and well documented.

How you will be marked:

Threshold for Pass (40%+)

  1. Basic networking functions: able to demo on lcpu connecting user client to server, playing the game.
  2. Code is properly formatted & commented.

Good Pass (~55%)

  1. Meets all the criteria of a threshold pass.
  2. Runs both user and AI clients, and this is clearly visible to a casual observer.
  3. Basic protocol functions:  tutor able to connect an additional client with the standard protocol.
  4. Threading done correctly and safely.

Distinction (70%+)

  1. All criteria of a good pass are met.
  2. Demonstrates interaction between the user & the bot.
  3. Demonstration is sophisticated and entertaining, and within requisite time limit.
  4. Code structure is clear & easily comprehensible in a quick overview.

Marks Table:

Note: Because this coursework is marked in lab, all marks will be to the nearest 5 points (e.g. for Protocol you can get 0, 5 or 10 marks)  This is the table the tutors will use (though they'll do this in moodle).  They will put an X in the box indicating how many marks you get for each criteria.  It is easy to get a negative total mark for this coursework if you do not turn up for the demonstration.

Specific Criteria (max score)
Code Legibility
Formatting (10)

Commenting (10)
complete (methods & algorithms)

Networking (1 Client communicates with Server, 20)

Concurrency (>1 Clients communicate with 1 server, 10)
works somewhat
works completely

Synchronisation or Semaphore (Present, No collisions, 10) none
some sensible things protected
looks well protected

Protocol (Tutor can connect and use their own client, 10) none / can't connect / nothing happens
some things work
everything works

AI Bot moves at visible rate (10) no attempt
sensible attempt
works well

User & AI bot interact and/or nice demo (20)
some kind of demo, no AI
unclear demo with AI, or good demo with no AI
clear demo with AI
AI demo is impressive
e.g. no instructions, does not compile,
difficult to test, failure to encapsulate
the game engine map from
the AIbot, platform dependencies

Student doesn't come to lab -40 (also, marker is not obliged to figure out unclear code); doesn't compile at all -20; easily fixable platform dependencies -10; weird failures of encapsulation -10.  (Note to tutors: no further penalty for no encapsulation at all beyond 0 for networking above)
Explanation: (copy & paste from left column)

(minimum 0, max 100)

page author: Joanna Bryson
27 February 2011 (checked by MDV 28 Feb 2011)
fixed (some inconsistent) demo dates 9 March