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:
- Creating
a
GUI
for human users. At a minimum, this must:
- operate in a window,
- have a control panel consisting of buttons
- have a pane that shows the user the outcome of their
actions.
Note that if more than one person is playing in the dungeon, or an
AI is also playing in the dungeon, then some things might happen
without the user doing anything. However, you can pass this
coursework if you just make a window allowing a single human user
to play the game by themselves.
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!
- 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.
- This specification must include a
test plan.
- 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.
- Buttons (or other widgets of your choice) should let you
control a character in your dungeon.
- Use labels to make it clear how to use your application.
- One button should let you quit the application.
- 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.
- This part is mandatory, and is
worth 15 points.
- Once you have completed
the User GUI above, choose 30 more points from the list below.
- A) Add a graphic pane to your Player GUI to display
what is going on in a better-looking way than just scrolling
text.
- B) Have your Player GUI display update in response to
events from the server. That is, let the server send an
event to the Player GUI and have that GUI update even though
the player hasn't done anything. For example, an AI bot
may have walked into the room.
- You can only do this if you use a client / server
architecture, which you will know about after doing CW2.
- The events will come from AI or other people's
clients. But your GUI should only be hearing about
the world from the sever that contains the game engine.
- 10 points.
- C) Add a chat capacity to your Player GUI
- Again, you can only do this if you are using a client /
server architecture.
- Add an editable text pane that allows you to type words to
other players, and another that reports what they type.
- You will want to have names to identify different
participants.
- Note the text will have to go through a server.
- 15 points (A
basic chat will get you 5 points ? to get the full 15 you
will need to add more features).
- D i) Create another GUI (the Game Engine GUI) for the
game engine when it's a server (requires
client / server architecture).
- Create a "god's eye view" pane that lets you watch
everything that happens in the dungeon. This is unlike
the player's view, which only shows what the player can
know. Note that this can help you debug your AI, so if
you are going to work on AI you should probably do this
first.
- Report the IP address for your server.
- Use radio buttons to turn the actual serving for clients
(the listening) on and off. Allow a new port to be
selected, but disable this if the server is currently
serving / listening.
- 10 points.
- OR
- D ii) Create another GUI
(the Game Engine GUI) that allows you to watch what is going
on in your dungeon when it's not a server (not using client / server).
- Create a "god's eye view" pane that lets you watch
everything that happens in the dungeon. This is unlike
the player's view, which only shows what the player can
know. Note that this can help you debug your AI, so if
you are going to work on AI you should probably do this
first.
- Make this GUI the main GUI that launches when you start
the program.
- Make sure it allows you to open & close the GUI for
the human user.
- Make sure you allow the user to "blank" the "god's eye
view" panel so they can play the game without cheating if
they want to.
- 10 points.
- E i) Add more types of interactions for players and/or
bots.
- The stereotypical thing for the game genre is to let the
bots fight, but you can make them helpful (e.g. donate each
other gold, guide each other.) Or you could make some
helpful and some harmful bots.
- You may want to add more possible items into the dungeon
too (e.g. weapons, cameras, mobile phones).
- 10 points.
- OR
- E ii) Make multiple kinds of bots for your dungeon
that don't interact (only one bot plays in the dungeon at a
time).
- Create two or three different bot types with different
strategies.
- In your write up, show that these bots work differently,
e.g. that one strategy can win the game faster than another.
- 5 points for a
variety of simple bots, or 10 points for substantially different
planning systems or representations and experiments to
show they are different.
- F) Make another GUI for launching AI bots, or add a
pane to your Game Engine GUI to do this.
- If you have more than one type of bot, this should let you
pick which one to launch.
- You may want to add a slider for each bot to control how
fast or slow it goes (the "sleep" statement introduced in CW
2).
- Report how many bots are currently alive in the dungeon.
- This may be combined with the Server GUI if you want to,
or it can be its own application / window.
- 5 points.
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:
- Your informal description of your classes & algorithms.
- This will almost certainly contain drawings.
- This must contain a Feature
Table, which explains which 45 points you are trying
to achieve.
- The table should look like this (leave the gray squares
blank! the markers will fill them in):
Intended Features
|
points
|
works? (self
evaluation)
|
works? &marks
(checker evaluation)
|
special instructions
|
Basic Client GUI
|
15
|
yes
|
|
none
|
Herd of AI elephants
[for a silly
example]
|
5
|
yes, pretty much
|
|
er... you have to
pass a weird command line argument in a special way
to get them running, here's how...
|
and
|
so
|
on
|
|
...
|
total points:
|
45
|
|
|
|
This table
will be used by the markers.
- Note that we expect the description to have been written before
you have done the coding, so it may have bugs &
inconsistencies in it. That's fine, you can write about
that in your critical analysis.
- One page of text, up to one more for the table and up to one
more for drawings. Max 4 pages total.
- Your fully-commented code.
- Poor program layout will lose marks.
- Poor commenting will lose marks.
- A short (2 to 3 pages) write-up documenting your
program.
- Include a screenshot of your GUI.
- Program documentation / HOWTO. Make sure anyone could
run your program from your documentation. Try your
non-CS friends, or family if they are online.
- Include critical analysis of your program:
- What did you do right? What did you do wrong?
- What would you do differently if you did it over?
- 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.
- 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:
- Informal specification & test plan 10%
- Fully commented, working program implementing your design
60%
- Documentation and analysis 15%
- 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%+)
- Brief discussion of requirements, design. A test plan.
- Simple program. Basic level of commenting. Code layout is
mostly correct. Minimal exception handling necessary for a
compile.
- Minimal functionality:
- A basic GUI for a user playing the Dungeon of
Dooom.
- Minimal documentation so that the system can be run without
making the marker hack it.
- Demo demonstrating knowledge about all your code & how it
is structured.
Good Pass
(~55%)
- Specification covers all aspects of the problem at an
appropriate level of detail. Good program design.
Good plan for implementation that includes sensible testing.
- 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.
- The GUI or GUIs are clean and make the way they should be used
apparent.
- Basic functionality:
- Everything in the threshold pass, and
- Has at least 10 points worth of extra features working
correctly.
- Documentation clear, concise and helpful. Sensible criticism
of your work, and good ideas for improvement.
- The demo works correctly.
Distinction
Pass
(70%+)
- 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.
- 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.
- GUIs are attractive, their functionality / usability is
apparent without much documentation.
- All or nearly all 30 points of chosen additional functionality
works well.
- 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.
- Demonstration is well-planned and engaging.
page author: Joanna
Bryson, with Andrew Ridge, Andrew Chinery
24 March 2015 (checked by RH 25 March 2015).