CM10228 / Programming Ib:   Assignment 3 (2010)

Graphical User Interfaces:  Decorating the Labyrinth of Dooom

Assignment Date:  Tuesday,  23 March  Due date:  Friday,  16 April at 4:00 PM

This assignment is the third of four you will have in this course.  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 assignment schedule is still:

Handed Out
Labyrinth of Dooom:  Reading & using maps 10%
23 February
9 March
Labyrinth of Dooom:  Networking and multiple concurrent agents in one dungeon 10%
9 March
23 March
Labyrinth of Dooom:  GUIs to show your friends & family 25%
23 March
16 April
demoed in lab 19-23 April
Back on the surface:  Databases & The Web 5%
20 April
done in lab 26-19 April
demoed in lab & lecture 4-7 May



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

For most students, we expect that you will be expanding from your own previous coursework.  However, if you have not been able to get Coursework 2 to work, then we will provide a model solution for coursework 2 which you can expand instead.  This will not include an AI client, so unless they make a client with their own AI client, students using the model solution will not be able to choose the AI options below.

The most basic objective which must be completed for a passing mark is:
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.  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 20 April.  Your tutor will check to make sure you undestand 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

This assignment is expected to take the average student (one who got about 58 in Programming I) about 32 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 10 self-study hours a week for the next three weeks (yes, including break!) 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 32 hours on this assignment.

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 windowing 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!  I don't want you to spend too much time on just this coursework.

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.
  1. Remember to write an informal specification / architecture for your application before you start.  You will probably want to draw the window(s) you want to build, and specify some classes.
  2. First, you want to build a User Client GUI application with some labels, a large pane for showing feedback from the server, and a number of buttons.
    1. The buttons (or other widgets of your choice) should let you control a character in your dungeon.
    2. Use labels to make it clear how to use your application.
    3. One button should let you quit the application.  If you want to use your client 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.
    4. Your GUI should use your networking code to talk to your own LoD server; although you may use the model solution's cleint & server code if necessary.
    5. This part is mandatory, and is worth 15 points.
  3. Once you have completed the User Client GUI above, 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:

  1. Your informal description of your classes & algorithms.
  2. Your fully-commented code. 
  3. A short (2 to 4 pages) write-up documenting your program.
    1. Include a screenshot of your GUI.
    2. Be sure anyone (try your non-CS friends, or family if they are online!) could run your program from this documentation.
    3. Some 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 are checking a lot of projects!
  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.
  5. Please also put a printed out copy of your code & documents in the box by the department office.  If you do this, some tutors will give you more feedback.  But you must still submit everything on Moodle; that is your real submission.
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 20% 
  2. Fully commented, working program implementing your design 60% 
  3. Documentation and Analysis 15%
  4. Demo (in lab) 5%
Total 100%

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. You demonstrate 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 coherantly.  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.
  6. Demonstration is well-planned and engaging.

Marks Table:

Specific Criteria Marks
Out Of
Informal Specification
Requirements / Architecture

Test Plan


Commenting, Formatting & Clarity of Code


Basic User 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





page author: Joanna Bryson
assigned 20 March 2010 (checked by MDV 22 March).

In-lab mark sheet translation:

turned up
explained code
demo ran
demo ran correctly
demo was really impressive