CM10228 / Programming Ib:   Assignment 3  (2015)

Graphical User Interfaces:  Decorating the Dungeon of Dooom

Assignment Date:  Tuesday,  25 March  Due date:  Friday, 25 April at 11:00 PM


This assignment is the third and final 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 assignments are:


Courseworks

Mark
Handed Out
Due
1
Dungeon of Dooom: Exploring the Dungeon 15%
11th February 27 February
2
Dungeon of Dooom:  Networking and multiple concurrent agents in one dungeon 10%
6 March
21 March
Demoed & fixed in lab 23-27 March
3
Dungeon of Dooom:  GUIs to show your friends & family 25%
25 March
25 April
Demoed in lab 28 April-2 May

Exam
50%
May


Objectives:

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.

For most students, we expect that you will be expanding from Coursework 2.  However, if you would prefer not to extend your Coursework 2, you can also extend from your coursework 1 and still pass.  In fact, you might extend your Coursework 1 as per Coursework 2 if you like.  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.  Whichever coursework you choose to edit, you can change anything you want.

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.  Marks will be capped, we will only mark 100 points worth of attempted contributions, any other code or features will be ignored by the markers.  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 19 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.7.  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.7).

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 and the first two weeks after break on this assignment, in addition to the two hours per week 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.

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 an informal specification / architecture for your application before you start.  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 User Client GUI application with some labels, a large pane for showing feedback from the server, 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 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. 
    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 User 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:

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

  1. Your informal description 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. 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
                       
5

Test Plan

5




Code
Commenting, Formatting & Clarity of Code

15

Basic User Client GUI

[15]

Other Features Chosen [marks in your own table]

[30]

Total from Feature Table / 2

45




Results & Analysis Documentation / Instructions

10

Analysis & Suggested improvements

5

Demo in lab

15




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


(30)




Total


100

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
Criteria
2
turned up (note: not turning up is a 20 point PENALTY)
7
explained code well
10
explained code and demo ran
12
demo ran correctly
15
demo was really impressive

Marks 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
24 March 2015 (checked by RH 25 March 2015).