CM10228 / Programming Ib:   Assignment 3  (2014)

Graphical User Interfaces:  Decorating the Dungeon of Dooom

Assignment Date:  Thursday,  27 February.  Due date:  Friday, 13 April at 11:00 PM

This assignment is the third and final you will submit for this course (though the second one we are handing out, see below).  Your mark in Programming Ib is composed of 50% coursework, 50% exam. This assignment is worth 25% of your final mark for the unit. The assignments are:


Handed Out
Dungeon of Dooom: Exploring the Dungeon 15%
11th February
24 Feb
Dungeon of Dooom:  Networking and multiple concurrent agents in one dungeon 10%
18 March
28 March
Demoed in lab 1-4 April
Dungeon of Dooom:  GUIs to show your friends & family 25%
27 February 13 April
Demoed in special labs 14-17 April



This assignment brings you further adventures in the Dungeon of Dooom.  The third coursework helps you learn to build your own GUI.  To pass, you should make at least one GUI interface so that your users can enjoy a more contemporary Human-Computer Interaction with your dungeon.  For high marks, you can either make this GUI elaborate, build several different GUIs for different tasks, or make your AI more elaborate.

Why have you given me CW3 before CW2?

Short answer:   Because we think it's a good idea for you to work on the GUI component of this one over reading week.   This needs to be in its own objects, don't just hack it into your CW1.

More details:  CM10228 counts on students having a spare week to practice programming during term.  Normally that week is late in term during the two-week Spring Break.  Unfortunately, to date Spring Break has not been fixed in the academic calendar, but rather follows the date of a religious holiday which is determined partly by the moon.  This year that holiday falls after term, so the computer science department has inserted a reading week early in term so students can catch up on their coursework.  Unfortunately, there's not enough time to finish CW2, which is about networking and client-server architectures, before reading week.  Also, we want to give you more support in tutorial for CW2.  So we are giving you CW3 early so you can spend reading week doing one part of it, the Player GUI. (And maybe hack on more AI if you want to, though those lectures come much later).  This is also an experiment to see if this helps you do CW2 more easily.  It may be that in the future we will always do the coursework this way.

It's very important that you write your GUIs as separate modules, with their own objects.  Don't just stick some GUI elements into your CW1.  You will get new code for CW2, and you may want to use your own GUI on the new version of the game.

Objectives (continued):

The most basic objective for CW3 which must be completed for a passing mark is:
For most students, we expect that you will start out writing the GUI for your CW1, but then may swap over to using the version of the dungeon you build in CW2.  This is why it's important to conform to the rules of the game given out in CW1, so that your GUI will work with either.  However, if you had trouble with coursework 1, we can use the version of the Dungeon distributed with CW2.  As mentioned in lecture, a big part of CW3 is showing that you can browse libraries of code and incorporate code examples into your own design. If you are editing CW2 for CW3, you can change anything you want.

In order to get full marks on the coursework, you will need to add a number of other features.  There is a menu of possible tasks and associated credit to choose from below.  You should not try to do everything!  You will only be marked out of 100 possible points, no matter how many features you decide to add.  Marks will be capped, we will only mark 100 points worth of attempted contributions, any other code or features will be ignored.  So please, do save some time for your other courses.

You will get detailed feedback on this coursework by the end of revision week.  You will also get a chance to demo Coursework 3 in lab on the week of 14 April.  Your tutor will be checking to make sure you understand all the library code you have incorporated into your program.

The Standard Section of the Specification

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 unix 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 23 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 7.5 self-study hours a week this week & the first two weeks of April 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 23 hours on this assignment.  In particular, students having trouble with programming or trying to get full marks may want to use some of their consolidation week getting ahead on this assignment by finishing the basic GUI.

An important note on plagiarism:  Plagiarism occurs any time that you use someone else's ideas without acknowledging them.  Asking for help is fine, but not acknowledging where you've received or found help is a form of theft.  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:

There are many possible things to do once you get the basic GUI working.  Please do choose whatever you think will be the most fun to work on, though you may also want to think about demoing this program for someone who might give you a summer job.

Everyone should pick 45 points worth of ideas from the below list (really, 30 in addition to the mandatory 15 for the GUI).  If you do more than 45 points worth, you won't get any extra credit for this!  We don't want you to spend too much time on just this one course.

All point values below are maximum.  To get full points, you must write clear code with good comments, good exception handling, good testing and write good documentation as specified below.

Also note that these sections are marked differently to one another, e.g. it's easy to get 15 out of 15 for the mandatory GUI by following the instructions here, but for the other features, we're expecting you to go over and above what's in the spec. Creativity will be rewarded!
  1. Write two informal specifications / architectures for your application, one before you start, and a revised one after CW2.  In particular, you will probably want to draw the UI for the window(s) you want to build, and specify some classes.
    1. This specification must include a test plan.
  2. First, you want to build a GUI for your application with some labels, a large pane for showing feedback from the game engine, and a number of buttons.  In the rest of the instructions below, this will be called the "Player GUI", because you may choose to build a second GUI later.
    1. Buttons (or other widgets of your choice) should generate signals that will let you control a character in your dungeon.  Before you have done CW2, just have them pop up the commands you will send the game engine in a dialog, or write them to the command line.
    2. Use labels to make it clear how to use your application.
    3. One button should let you quit the application. 
    4. Ideally this window should be for a client.  If it is and you want it to connect with other people's servers, you should also provide editable text fields so that your user can enter IP addresses and port numbers for connecting to them.
    5. This part is mandatory, and is worth 15 points.

  3. Once you have completed the Player GUI above, and completed CW2, choose 30 more points from the list below.
Remember: functionality alone doesn't get you high marks!  There should be good code layout, good comments, good documentation, good testing and good exception handling. 

When you are filling in the Feature Table as part of your specification (see below) remember that you can also get some marks for things even if you haven't got them working in time for the hand in.  This is particularly true in the specification and analysis sections.  So be optimistic in your initial specification.  Have fun!

What to hand in:

Submit on Moodle a file named <yourUsername> or <yourUsername>-coursework3.tar.gz file containing:

  1. Both of your informal descriptions of your classes & algorithms.
  2. Your fully-commented code. 
  3. A short (2 to 3 pages) write-up documenting your program.
    1. Include a screenshot of your GUI.
    2. Program documentation / HOWTO.  Make sure anyone could run your program from your documentation.  Try your non-CS friends, or family if they are online.
    3. Your test plan and results.
    4. Include critical analysis of your program: 
      1. What did you do right?  What did you do wrong? 
      2. What would you do differently if you did it over?
      3. Be sure to draw attention to any work that you think was particularly clever or difficult ? we have to check a lot of projects, but we don't want to miss out on giving you credit for something cool.
  4. Zip (or tar) everything, including uncompiled versions of your code, and post it on Moodle. The person marking your program will be compiling & running your program.
Remember: marks are not given just because a program compiles or runs!  It should run robustly, and it should be well commented, tested &  documented as specified above.

How you will be marked:

NB:  This coursework must run on the Java on the BUCS unix servers, which is not necessarily the most recent one.  Check this before you submit!

The marks allocation for this assignment is as follows:
  1. Informal specification & test plan 10% 
  2. Fully commented, working program implementing your design 60% 
  3. Documentation and analysis 15%
  4. Demo (in lab) 15%
Total 100%

Marks Table:

Specific Criteria Marks
Out Of
Informal Specification
Requirements / Architecture

Test Plan


Commenting, Formatting & Clarity of Code


Basic Player Client GUI


Other Features Chosen [marks in your own table]


Total from Feature Table / 2


Results & Analysis Documentation / Instructions


Analysis & Suggested improvements


Demo in lab


e.g. doesn't compile,
difficult to test,
didn't show up to demo (-20)




In-lab mark sheet translation.  Note you lose 35 points total if you don't turn up to demo.  15 marks you don't get, plus a 20 mark penalty.

Total Points
turned up (note: not turning up is a 20 point PENALTY)
explained code well
explained code and demo ran
demo ran correctly
demo was really impressive

Mark Guidance

The below are a rough guide to how you might expect to be marked by an indicative description of what might achieve particular degree categories.

Threshold for Pass (40%+)
  1. Brief discussion of requirements, design. A test plan.
  2. Simple program. Basic level of commenting. Code layout is mostly correct. Minimal exception handling necessary for a compile.
  3. Minimal functionality: 
  4. Minimal documentation so that the system can be run without making the marker hack it.
  5. Demo demonstrating knowledge about all your code & how it is structured.
Good Pass (~55%)
  1. Specification covers all aspects of the problem at an appropriate level of detail.  Good program design.  Good plan for implementation that includes sensible testing.
  2. Program is a good implementation of design, or possibly better than the design. Code is concise and comprehensible.  Layout of code is correct and clear.  Some reasonable exception handling, e.g. reasonable messages or steps taken on likely exceptions.
  3. The GUI or GUIs are clean and make the way they should be used apparent.
  4. Basic functionality: 
  5. Documentation clear, concise and helpful. Sensible criticism of your work, and good ideas for improvement.
  6. The demo works correctly.
Distinction Pass (70%+)
  1. Specification describes the system coherently.  Design description starts with a high level design and showing refinement to appropriate levels. Algorithms and implementation plan are given at an appropriate level of detail and are well explained.  Sophistication in testing approach e.g. automation, unit testing.
  2. A sophisticated program showing good use of Java, but not overly complex. Commenting is appropriate and gives sufficient information, but is not overly verbose.  Layout of code is correct and clear.  Fully appropriate use of exception handling.
  3. GUIs are attractive, their functionality / usability is apparent without much documentation.
  4. All or nearly all 30 points of chosen additional functionality works well.
  5. Documentation clear, concise, attractive and informative.   Detailed and thoughtful criticism of your work, and well-thought-out ideas for improvement, possibly including descriptions of alternate implementations.  No pagelengths are exceeded.
  6. Demonstration is well-planned and engaging.

page author: Joanna Bryson, with Andrew Ridge, Andrew Chinery
revised 27 February 2013 (written 18 Feb, checked by RH 24 Feb 2014).