CM10228 / Programming Ib:   Assignment 2  (2015)

Networking and Multiple Clients in the Dungeon

Assignment Date:  Tuesday,  6 March  Due date:  Friday,  20 March at 11:00 PM (Moodle) Marked entirely in Lab 23-27 March

Objectives

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

You have been given (on Moodle) 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 may 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. However, there is one minor AI goal of this coursework:

• Playability: Your bot should not be so much smarter, faster & better than you that it is no fun to play against. You will probably want to use sleep() commands in order to make the bot run at such a speed that you are able to interact with it (whether positively or negatively.)  For your own personal satisfaction, you may want to have your bot learn (e.g. set its own delay between actions). You won't get any credit for this directly, but it might make your demo nicer.

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 listed above, 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, and should work if you run it from two different computers. This is how we will be marking it. The code should be platform and operating-system independent. It should run in Java 1.7. 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.7).

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.

Please note there is also a special lab to practice networking & threading, see the course schedule for dates.  Attending this should help you very much with this coursework.

1. First, examine the code and make sure you understand it.  Feel free to improve it, but that is not the point of this coursework and won't get you any marks.
   
2. 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.  Copying without giving acknowledgement is plagiarism and will be penalised if caught.
   2. Change as little code for the networking 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, though you may want to use this code for your CW3 (rather than your own code from CW1; it's up to you.)
      
3. Create a Server class.
   
1. You probably want to use code for accepting multiple clients, but a single client is enough to pass the coursework.
2. For now, the server should start the game when it starts up.  In CW3 you may want to have a "start game" button so that the first client(s) that join don't have an unfair advantage, but don't worry about this now. 
   
3. Be sure to shut down the server cleanly when the game ends.
4. You may want to check your server works now using telnet as the client.
   
4. Create a ClientThread class which inherits your new abstract class for either AI or human players.
5. Create a client using PlayGame from the code distributed with this assignment. The client & server should communicate using the strings provided in the protocol document.
   
1. 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.
6. 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.
   3. You will probably want to use telnet so that you can debug the client and server one at a time.
   4. If you get this far you should pass the coursework; the remaining steps are just for better marks.
      
7. 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 synchronize or using semaphores.
• One client might want to look at the map while another is moving around on it, or picking up an item. These things shouldn't be able to happen at the same time!
8. 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 client, as you can reuse the client code.
9. Modify your bot to make sure it is playable (see earlier in the spec).
   
10. Practice your demo in advance of the tutorial.
11. 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:

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.  That is the code you should use in lab for your demo, though if you improve your code have that available with you too, since after you are marked the tutors will be making sure your networking really works.
   
2. You should upload a zip (or tarball) containing uncompiled versions of your code
   • The person marking your program will compile and run it, though you will be there with them. They may not use the same operating system that you do
   • Upload your code to Moodle by the time specified above.
3. In your demonstration, you should be able to connect your bot to your dungeon, leave it running, and then enter the dungeon yourself with your player 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 below.)
      
   4. The tutor will also be connecting a client to your server, so you must maintain the standard protocol.

How you will be marked:

This coursework is marked entirely in lab.  If you do not attend lab, you will lose most if not all of your marks.

The details of the marking scheme can be read from the marks table.

Marks Table:

Mark Guidance

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.