CM10228 / Programming Ib:   Assignment 1  (2015)

Exploring the Dungeon of Dooom



Assignment Date:  Tuesday,  3 February  Due date:  Friday,  27 February at 11:00 PM


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


Courseworks

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

Exam
50%
May




Objectives

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

The game takes place in a two-dimensional space (a dungeon). The objective of the game is to gather a set amount of gold, and then find the exit of the dungeon. The rules of the game that you will need to follow (along with this coursework spec) can be found here. When there are multiple players, it becomes a bit more complicated, but for Coursework 1 the objectives are relatively simple.

This coursework has the following code objectives:

  1. We have provided you with some sample ASCII-art maps. You will need to read a map like one of these in from a file & convert them into a two-dimensional array suitable for game play (int[][] or char[][]).
    1. Simple map
    2. More complicated map
  2. You will need to create a command-line interface that allows a user to control a player in the game using the commands provided in the description document.
  3. You will need to create a bot that can play the game for you. The bot is not allowed to use the map that the game has, but, like you, should only `look' at the information the game engine gives it.  Note that the bot 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.  (Note: this objective is not necessary to pass the coursework.)

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.7.  To be safe, you should probably test that your code works on one of the BUCS 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 15 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 for the next two weeks on this assignment, in addition to the two hours you have in lab.  (Note that 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 15 hours on this assignment (Coursework 1).

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. Attribution magically changes plagiarism (evil) into citation (good).

What to do:

We strongly suggest you get each item of the below working in the order suggested,  & then test it before moving to the next step.  Note in particular that you can pass the coursework without ever building a bot, and you can get decent marks with a truly stupid bot that walks into walls.
  1. Create a class Map that:
    1. Reads one of the sample ASCII-art map files (your code should be able to load any map written in the same format).
    2. Stores the map information in a 2D array (int[][] or char[][]).
  2. Create a class GameLogic that:
    1. Uses Map to load a map from file.
    2. Randomly positions a player within a map (on a non-wall space).
    3. Supports methods which fulfil the game rules.
  3. Create a class PlayGame, which uses the Command-line Interface (CLI) to interact with the user (this is where your main method should be), which:
    1. Reads & writes to STDIN and STDOUT (the command line).
    2. Allows a user to control a player in the world using the commands listed in the game rules (calls the appropriate methods in GameLogic).
  4. Create a Bot class that:
    1. Can play the game (as a drop-in replacement for PlayGame, with its own main function).
    2. Basic bot should:
      1. Escape if it happens to be standing on the exit.
      2. Move, at least randomly.
      3. It's better if it doesn't try to walk through walls.
      4. Pick up items that it lands on (currently only gold.)
    3. For higher marks, the bot should be more advanced.  For details of this, see later in this coursework spec under "distinction."

A note on class organisation

For this coursework, your program(s) should have two entry points (main methods). Your primary classes could be laid out as follows:

Of course, you can write other classes to help with the work of these classes.  The important point is that humans and bots play the same game -- bots don't have special access to GameLogic. 

What to hand in:

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

  1. A brief specification you should write when you design your program.  About half a page.
  2. Your fully-commented uncompiled code for all the classes you wrote.
  3. Brief instructions about how to demonstrate your bot, 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 code.  Include a discussion of what you did, why you did what you did, and what you would do if you did it again. About one page.

Upload the file to moodle by the time specified. Failure to name your submission file correctly will incur a penalty. 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. Fully commented, working programs implementing your design: 80% 
  2. A report of no more than one and a half pages including the program design (half page), testing and analysis: 20% 

Total 100%

Threshold for Pass (40%+)

  1. Simple program. Basic level of commenting. Code layout is mostly correct.  Code contains core functionality:
    1. Reads in a map & can use it.
    2. Command Line Interface allows control of the player on the map that has been read.
  2. (It is possible a program will pass if exceptionally well commented & analysed but does not work correctly.)
  3. Basic testing; Basic error checking; Little or no analysis.

Good Pass (~55%+)

  1. 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. Bot able to move around randomly, will eventually exit. The bot should also:
    1. Not try to walk through walls
    2. Pick up any items that it lands on
  4. Description of testing and development; Good Error Checking in the code; Good analysis & reflection on your work.
    1. Reflection might include a discussion of the program and the development process you undertook, ideas for improvement. 

Distinction (70%+)

  1. Clear, well-communicated program design.
  2. A sophisticated program showing good use of Java, but not overly complex. Commenting is appropriate and gives sufficient information but does not clutter. Layout of code is correct and clear.
  3. Results are clear and presented in an interesting way. Testing & analysis of the impact of the bot's intelligence on its efficiency escaping the dungeon. Analysis of the complexity of the bot's search for the exit. 
  4. Excellent reflection on results, possibly considering alternative implementations.  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.  Entire write up is no more than 1.5 pages of text.
  5. A more intelligent bot, including behaviour such as (but not limited to!) the following:
    1. Going towards interesting things it sees in nearby squares.
    2. Going around walls if it sees interesting things on the other side of a wall.
    Note that this is the area where to get full marks you need to go over and above what is specified here.

Marks Table:


Specific Criteria Marks
Out Of
Code
Map Reading & Storage

20

Game Interface (Command Line)

20

Basic Bot

10

Bot Cleverness

30




Results & Analysis Testing & Report

20




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

Explanation:
(10)

Poor/No Commenting
(20)

Poor Code Layout
(20)




Total


100


page author: Joanna Bryson, with Andy Ridge & Andy Chinery
 2 February 2015 (checked by RH 3 Feb 2015)  updated to clarify "brief spec" 5 February