CM10228 - Coursework 2 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. Networking: You will create a client-server version of the Dungeon of Dooom. 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: 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 may 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 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 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. 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. Change as little code as possible. Networking does not have to be hard, it is not that different from using streams like STDIN and STDOUT. We're not carefully reading your code this time. 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. Debug your new client & server. Be sure to do this in good time so you can take your code to lab if necessary & get help from the tutors. You will probably want to write some test code to make sure that your client & server are doing what you think they should. 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. 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! 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. Modify your bot to make sure it is playable (see earlier in the spec). Practice your demo in advance of the tutorial. 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 -coursework2.zip or -coursework2.tar.gz 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. 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. 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. If you don't get as far as the bot, you can still give a demo just with your own client. Your demo should be five minutes long, including starting up the server & clients. You should practice this. You will get a few marks for interacting with your bot in some way (see mark sheet.) 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%+) Basic networking functions: able to demo on lcpu connecting user client to server. Allows game play with at least all of the commands in the rules for CW1. Code is properly formatted & commented. Good Pass (~55%) Meets all the criteria of a threshold pass. Runs both user and AI clients, and this is clearly visible to a casual observer. Supports the full protocol, at least to pass from client to server, even if bots or game ignore some commands. Protocol is functional: tutor is able to connect an additional client with the standard protocol. Threading done correctly and safely. Distinction (70%+) All criteria of a good pass are met. Demo clearly shows interaction between the user & the bot. Demonstration is sophisticated and entertaining, and within requisite time limit. 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)
