CM10228 / Programming Ib:   Assignment 1  (2010)

Manipulating Memory:  Maps in the Labyrinth of Dooom

Assignment Date:  Tuesday,  23 February  Due date:  Tuesday,  9 March at 10:00 AM


This assignment is the first of four you will have in this course.  Your mark in Programming Ib is composed of 50% coursework, 50% exam.  This assignment is worth 10% of your final mark for the unit. The assignments for:




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

Exam
50%
May

Objectives:

This assignment will introduce you to the Labyrinth of Dooom, the game environment for most of this year's coursework.  The first coursework emphasises reading and writing to Streams and manipulating memory and data structures.

On Moodle you can find the code and instructions for a simple game which you can play from the command line.  The game takes place in a two-dimensional space, but as a user you can see only part of that space and need to explore the rest.  The objective of the game is to gather enough gold that you are able to exit the dungeon, and then of course you must find the exit.  When there are multiple players, it will come to a bit more than that, but for coursework one the objectives are relatively simple.

This coursework has two code objectives which you can pursue in any order:
  1. The game comes with a small default map hard-coded into it.  You will add functionality to the program so that you can read ASCII-art maps from a file & convert them into a two-dimensional array suitable for game play.
  2. The game comes with a class that allows you to play the game from the command line.  You will add a second class which is an "intelligent" program -- an AIbot -- which can play the game for you.  This program is not allowed to use the map the game has, but, like you, should only `look' at the information the game engine gives it.  Note that this program does not need to be very smart in order for you to pass -- it just needs to be able to wander around the dungeon until it has gathered enough gold, then to wander around the dungeon until it finds the exit, then exit.

Warning:  Do not edit the class LODGame.  This is the game logic, and will change in Coursework II, so your edits would be lost.


We have developed the software to make sure you can use the eclipse IDE to help you with your programming and debugging.  However, your code must run from the command line.  This is how we will be marking it.  We want to know that you can compile your code on your own, and that you know what the main function of your program is.  The code should be platform and operating-system independent.  It should run in Java 1.5.  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 20 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 two weeks on this assignment, in addition to the two hours you have in lab.  (Notice this still leaves you two hours a week for lecture preparation.)   Because programming takes different people radically different amounts of time, some students will spend something more or less than 20 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. 

What to hand in:

  1. An informal specification for at least two classes you have written, one for reading maps, the other for the AIbot.
  2. A printout of your fully-commented code for all the classes you wrote or altered.
  3. Brief instructions about how to demonstrate your AIbot, and how to load your maps.
    1. Notice that the maps should be in the specified format, so that you can load your friend's maps etc.
    2. The instructions are for your tutor. Be sure that someone who does not know you or the project can quickly get your code working.
  4. A brief report / analysis of the performance of your classes.  Include a discussion of how well they conform to your spec, and explain any deviations. About 0.75-1.5 pages.
  5. A zip file containing uncompiled versions of your code.
Remember, marks are not given just because a program compiles or runs.  It should run robustly, and it should be well commented and well documented as specified above.

How you will be marked:

The marks allocation for this assignment is as follows:
  1. Informal Specification 20% 
  2. Fully commented, working programs implementing your design 60% 
  3. Results and analysis 20 % 
Total 100%

Threshold for Pass (40%+)
  1. Brief discussion of requirements and program design.
  2. Simple program. Basic level of commenting. Code layout is mostly correct.  Code does only the minimum necessary.  It is possible a program will pass if exceptionally well commented & analyzed):
    1. Reads in a map & can use it.
    2. Bot wanders randomly, will pick up gold, will eventually exit.
  3. Basic testing; Basic error checking; Little or no analysis.
Good Pass (~55%)
  1. Specification covers all aspects of problem. Good program design. Algorithms are given at an appropriate level of detail and are well explained.
  2. Program is a good implementation of design, or possibly better than the design. Layout of code is correct and clear. Code is generally concise but comprehensible, identifiers well named.
  3. More efficient AI for the bot.  Examples might include but are not limited to:
    1. Not walking into walls.
    2. Going towards interesting things seen in nearby squares when there are no walls in the way.
    3. Getting to interesting things seen in nearby squares when there are walls in the way.
  4. Description of testing and development; Good Error Checking in the code; Good analysis & Reflection.
    1. Reflection might include a discussion of the program and the development process you undertook, ideas for improvement. 
Distinction (70%+)
  1. Specification covers all aspects of the problem. Algorithms are given at an appropriate level of detail and are well explained. 
  2. A sophisticated program showing good use of Java, but not overly complex. Commenting is appropriate and gives sufficient information. Layout of code is correct and clear.
  3. A more intelligent AIbot, which should include a memory that stores locations of interest to return to later (e.g. health, exit).
    1. Note that the bot should not exactly replicate the 2-D array that is the real map -- it should not know its starting location.  The data structure you use should store & compute path information from the bot's history.
    2. Note that to use its internal map, the bot must recognise things about its internal state such as that it is injured (an unlikely event in the current version of the game), or that it has enough gold to go out of the exit, and then change its behaviour as a consequence.
  4. Results are clear and presented in an interesting way. Testing & analysis of the impact of the bot's intelligence on its efficiency. Analysis of the complexity of the bot's search. 
  5. Excellent reflection on results, possibly considering alternative implementations.  Shows a thoughtful discussion of the program and the development process you undertook. Detailed and thoughtful criticism of your work, and well-thought-out ideas for improvement.

Marks Table:



Specific Criteria Marks
Out Of
Specification
Requirements
                       
10

Test plan

10




Code
Formatting

10

Commenting

10

Correctness of Map Reading

10

Bot Intelligence

30




Results & Analysis Testing & Report

10

Analysis of Bot algorithm

10




Penalties
e.g. no instructions, does not compile,
difficult to test, failure to encapsulate
the game engine map from
the AIbot, platform dependencies

Explanation:


(20)




Total


100


page author: Joanna Bryson
22 February 2010 (checked by MDV 22 Feb 2010)