||Labyrinth of Dooom: Exploring the Labyrinth|| 15%
||Labyrinth of Dooom: Networking and multiple concurrent agents in one dungeon||10%
Demoed in lab 22-2 March
||Labyrinth of Dooom: GUIs to show your friends & family|| 25%
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 (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. These rules can be found here. The primary objective of this coursework is to introduce you to networking and concurrency.
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.
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.
||complete (methods &
||Networking (1 Client
communicates with Server, 20)
|Concurrency (>1 Clients
communicate with 1 server, 10)
|Synchronisation or Semaphore (Present, No collisions, 10)||none
||some sensible things
||looks well protected
|Protocol (Tutor can connect and use their own client, 10)||none / can't connect /
||some things work
|AI||Bot moves at visible rate (10)||no attempt
|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
figure out unclear code); doesn't compile at all -20; easily
platform dependencies -10; weird failures of encapsulation
(Note to tutors: no further penalty for no encapsulation at
0 for networking above)
||(minimum 0, max 100)