CM10228 / Programming Ib:   Assignment 2  (2013)

Networking and Multiple Clients in the Dungeon

Assignment Date:  Tuesday,  5 March  Due date:  Friday,  15 March at 11:00 PM (Moodle) Also demoed in Lab 18th-22nd 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:


Courseworks

Mark
Handed Out
Due
1
Dungeon of Dooom: Exploring the Dungeon 15%
12th February
1 March
2
Dungeon of Dooom:  Networking and multiple concurrent agents in one dungeon 10%
5 March
15 March
Demoed in lab 18-22 March
3
Dungeon of Dooom:  GUIs to show your friends & family 25%
20 March
19 April
Demoed in lab 22-26 April

Exam
50%
May


Objectives

This assignment brings you further adventures in the Dungeon 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 Dungeon of Dooom. Your task will be to connect the command line interface (PlayGame.java) to the game logic (LODGame.java) 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. The code we're giving you provides a lot of this new functionality, other of it is optional extensions you may do in CW3.  The new 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 Dungeon 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.

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.

If at any point during this coursework you are stuck, there is a lab session to help you start off with networking and concurrency, which should hopefully give you a better idea of how to proceed

  1. Separate 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 and the lab 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 prints 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. 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>-coursework2.zip 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 to be marked in, so that tutors can help you debug it if there are any problems.
  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.
  2. Allows game play with at least all of the commands in the rules for CW1.
  3. 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. Supports the full protocol, at least to pass from client to server, even if bots or game ignore some commands.
  4. Protocol is functional:  tutor is able to connect an additional client with the standard protocol.
  5. Threading done correctly and safely.

Distinction (70%+)

  1. All criteria of a good pass are met.
  2. Demo clearly shows 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)
0
5
10
15
20
Code Legibility
Formatting (10)
illegible
legible
pretty



Commenting (10)
none
some
complete (methods & algorithms)


Functionality
Networking (1 Client communicates with Server, 20)
none
attempt
compiles
runs
elegant

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



Synchronisation or Semaphore (Present, No collisions, 10) none
done naïvely
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)
none
some kind of demo, no AI
unclear demo with AI, or good demo with no AI
clear demo with AI
AI demo is impressive
Penalties
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)



Total
(minimum 0, max 100)



page author: Joanna Bryson, with Andy Ridge & Andy Chinery
1 March (checked by MDV 1 March)