Task 7.1 - Initial Setup

The assignment is to create a simple game where a player can hire champions and face challenges. The goal is to implement the Game interface in the Player class, using supplier classes to handle detailed implementation. The player should store champions and challenges using Java library collections/maps. Two private methods, setupChampions() and setupChallenges(), are required to load data into a Player object. The demonstration will take place on November 15th, and students must submit their code on Studynet by November 14th.

6COM1037 OO development Coursework 1 Nov 2016
Champions of Disc Earth - CODE
1. The Assignment
Produce a Netbeans project implementing the specified version of CODE by completing tasks described below. Your
project must be capable of running correctly using the software in UH labs.
Your CODE project should display the qualities associated with good program design. Your program code should:
 minimise code duplication and be modularised so that components have low coupling and high cohesion.
 use inheritance, abstract classes and interfaces, as appropriate.
 be reusable and easy to maintain.
 be well documented, displaying both agreed standards of internal documentation and good use of the facilities
available in Javadoc.
The project you submit must compile. If your project does not compile, you will not be able to perform in the
demo. You must attend the demonstration session. If you do not attend your designated demonstration session,
you will get ZERO marks
The project oodcwk-students contains the CODE interface , a Player class, a GameUI class to help with
testing, some enum classes, MyTester which can also be used for testing and a Teamwork class. GameIO
compiles, but will only provide results when you have implemented appropriate methods in Player and loaded some
data. You should not change the code provided (except as instructed).
2. Pair Programming
Complete this assignment by working in pairs. Submissions by single students, or larger groups will not be accepted.
For pair programming to be successful, members of a pair must be able to work together, at the same computer, for
suitably long periods of time. You should also vary who actually types in the code and who is observing/advising. This
technique works best if the skill levels of the pair are roughly equivalent. If there is a wide disparity between skill levels
there is a high probability that the weaker of the pair will not learn anything, while the stronger will do all of the work.
This will not prepare the weaker partner for the tasks in the demo session, or for future assessments.
 Before you start of the assignment please edit the Teamwork class by replacing the Strings in the array with
details appropriate for your pair. If you complete this incorrectly, you may receive ZERO marks.
 You must EACH submit the same project to Studynet by the deadline.
 Tasks in the demo session must be completed individually.
3. Test First Development
The code in this project is complicated to mark by inspection, so its functionality will be marked professionally by
running testing software. This software will be testing your implementation of the Game interface. However, in
order to implement the interface in line with OO design principles, you should add some lower level supplier classes. If
you try to just write everything in Player, the code will be horrendously complex and totally unmaintainable (and not
get good marks for design).
Since you don’t yet know how to do professional testing, you have been given a tester class MyTester and a text file
with the expected results of all tests. This tester class does not need to know anything about your implementation as it
is written to the Game interface. The software which we will use to test your code (and award marks) will perform the
similar tests, but use different data. When you have implemented some method in the interface, you would be wise to
test it using appropriate tests in MyTester to see whether it gives the same results. The essence of “test first
development” is that you write code to produce the expected results - so you should at least look at them.
You have also been given a user interface class GameUI, which you can use to test your code with keyboard input.
However, there is no point in testing if you don’t know the expected results. So you should use MyTester to see what
results are to be expected from the given test data.
NOTE: tests in MyTester are designed to be as independent as possible so that they don’t contaminate each other.
Each MyTester test starts by creating a fresh new Player object which is not contaminated by the results of any
Page 1

6COM1037 OO development Coursework 1 Nov 2016
previous tests. If you want to get similar results using GameUI, you must to “quit” and restart GameUI for each
test.
Page 2

6COM1037 OO development Coursework 1 Nov 2016
4. Game Description
“Champions of Disc Earth” (CODE) is a strategy game. The current prototype provides a very simplified version of the
game for one player. Here is the briefing provided for a player of this version of the game: You are the ruler of Disc
Earth. Your kingdom is assaulted by a variety of enemies who provide different types of challenges. To protect your
kingdom, you must assemble an army of champions who can meet (and hopefully win) these challenges from your
enemies. The game provides a collection of champions whom you can hire.
At the start of the game you have a fixed amount of money (1000 gulden) in your treasury which can be used to hire
champions. To add a champion to your army, you have to use the money in your treasury to pay their hire fee. Once
you have an army, you will be expected to meet some challenges. Winning a challenge will bring you rewards, and
increase your treasury. If you lose a challenge, you have to pay the reward money to your enemy and lose it from your
treasury. At any point in the game, you can hire or discharge champions. If you discharge a champion, you can get
them to pay you back half of their hire fee. So when you need money, you can discharge champions if they are in your
army, but not if they are dead or already available for hire. The skill in this version is in assembling your army in a way
which enables you to win challenges and increase your treasury.
Your enemies offer different types of challenges. Each challenge has a unique number, the name of the enemy, a type
(Magic, Fight or Mystery), a required skill level, and a reward. In this game prototype, you will need to select a
challenge by number (later versions will select challenges for you at random). Your game should then choose the first
available champion in your army who can meet the challenge and compare the skill levels. The results of meeting a
challenge will be one of the following:
 “Challenge won by...“ – add reward to treasury, return name of champion
 “Challenge lost as no suitable champion available” – deduct reward from treasury
 “Challenge lost on skill level” - deduct reward from treasury and set your champion to "dead"
Champions can be one of the following types: Wizard, Warrior or Dragon (more types to be added later). The table
below shows which type of challenge they can meet:
Magic Fight Mystery
Wizard yes yes yes
Warrior no yes no
Dragon no yes Only if they talk
Each champion has a unique name, a skill level, a hire fee. Wizards have a hire fee of 300 gulden, but if they are also
necromancers their fee is 400 gulden. They also have a speciality. Warriors set their own hire fee, and you also need to
store their preferred weapon. Dragons have a fixed hire fee of 500 gulden, and some of them can talk. Each champion
has a skill level recorded as a number from 1 to 10. All dragons have a skill level of 7. A warrior's skill level is their hire
fee divided by 100(ignoring remainders). Wizards have different skill levels. See Appendix A for sample data.
Champions are in one of the following states:
 for hire – is in the game’s collection of champions but not yet hired for your army
 active – has been hired for your army and is available to meet challenges
 dead – is not available for challenges, cannot be restored
Challenge numbers should be sequential from 1. Challenges can be met more than once
After losing a challenge, your treasury may be <0. You cannot buy any more champions. However, you can continue to
meet challenges with your remaining champions in the hope of winning some more money (even if your treasury goes
further into debt). You may also make money by discharging champions. However, if your treasury has no money or is
in debt, and you have no champions to discharge, then you have lost the game and a suitable message should be
output.
5. Scope
This early working version of the game requires the player to select the challenge (by number). This has been done to
make it possible to design a standard set of tests. Programs with "random" features are difficult to test because of their
unpredictability. Once the game is fully tested, a “random” element can be introduced. You are NOT required to do this.
In future, the condition for "winning" the game will be to meet all the challenges and still have money left in the treasury.
You are NOT required to implement this feature of the game.
In future, when a player has lost, the game will automatically terminate after displaying an appropriate message. You
are NOT required to ensure the game terminates, but will be expected to display a suitable message.
Page 3

6COM1037 OO development Coursework 1 Nov 2016
6. Functional Requirements
When a player starts the game, they will be asked for their name. The system will create an instance of the game and
automatically load all the sample data (see Appendix A) of champions and challenges into appropriate
variables/collections, and set the treasury to 1000 gulden.
The player should be able to create their army by hiring some of the available champions. On hiring a, appropriate
deductions should be made from treasury. If there is not enough money in the treasury or the champion not available,,
the champion cannot be hired. Appropriate messages about the outcomes should be displayed.
Once the player has some champions in their army, they can meet challenges. In this prototype, the player will be
required to provide the challenge number. The system will then select the first appropriate champion which can be used
to meet the challenge. The result of the challenge will be processed as described in the specification above and a
suitable message displayed. In this version, challenges may be used more than once, and the player may view any or
all of the challenges.
The player may hire or discharge champions at any point in the game. Note: champions who are dead cannot be
discharged. The player may also request to see: the state of the game, the state of their treasury, details of all
champions available for hire, details of all the champions in their army, details of all challenges, the state of one
champion or challenge.
These functional requirements have been specified in the Game interface
7. Assignment Tasks
By completing tasks described below, produce a Netbeans project implementing a version of CODE game. Your
project must be capable of running correctly using the software in UH labs.
Your CODE project should display the qualities associated with good program design. Your program code should:
 minimise code duplication and be modularised so that components have low coupling and high cohesion.
 use inheritance, abstract classes and interfaces, as appropriate.
 aim to be reusable and easy to maintain.
 be well documented, displaying both agreed standards of internal documentation and good use of the facilities
available in Javadoc.
The project you submit must compile. If your project does not compile, you will not be able to perform in the
demo and will get Zero marks. You must attend the demonstration session. If you do not attend your designated
demonstration session, you will get ZERO marks
The project oodcwk-students contains the package OODCwk, which contains the following classes:
interface Game , a Player , GameUI and MyTester to help with testing, some enum classes which you
can use and the Teamwork class. GameIO and MyTester compile, but will only provide results when you have
implemented appropriate methods in Player.
On Studynet you will also find TestResults.txt with the expected results of running all the tests in MyTester
You must NOT change interface Game, or you will be heavily penalised.
Task 7.0 – Getting started
 Download and save oodcwk-students. You should NOT change the code provided, but should add to it.
 Read the game description above and make a list of requirements
 Look at the Game and the GameUI classes, and recognise that they cover the functional requirement. Notice that
we have used copy/paste/edit to copy the methods in Game into the Player class, and provided you with
method “stubs” so that Player compiles. You must NOT change game, but can add appropriate private
methods in Player to improve the design of your code (e.g.methods to perform common, or well defined
subtasks)
Page 4

6COM1037 OO development Coursework 1 Nov 2016
 Now return to the specification and try to identify useful supplier classes which may be helpful in implementing
Game. For each class, identify suitable fields and methods.
 Look at your supplier classes and identify opportunities for using inheritance and polymorphism.
Task 7.1 – Initial setup `
 First, write the supplier classes identified in task 0. They don’t need to be complete, but you should have some of
the fields, at least one constructor, and you could attempt toString() methods . You can always add further
methods later. You can’t do anything in Player until you have done this
 In Player,you must decide how you want to store your champions and challenges. Your project will need to
provide lists of champions for hire, the player's army and challenges ..etc . You should consider using some useful
classes from the Java library to manage this. There are a number of ways to do this, but what you decide will
have an effect on how easy/difficult it will be to do the rest of the project.
 Once you have decided how you want to store champions & challenges, declare and create appropriate
collection/map variables (fields) in Player. Then complete the two private methods setupChampions()
and setupChallenges() which should add those champions and challenges listed in Appendix A to these
collections/maps. These two methods are called in the constructor to “load” the data into a Player object.
Creating and storing the data in Appendix A should be done only in these methods. (To check whether your code
works use GameUI options 3 & 8).
Until you get this working, GameUI & MyTester will have not have any data and so no sensible results
Note: actual data is not usually hard-coded into a class of this type. For maintainability, it is more usual to read it from a
data file (more about this later in the course)
Task 7.2 – Producing the basic CODE system
Your basic system should provide the functionality specified in the Game interface, by providing implementation code
for the methods in the Player class which currently exist only as “stubs”.
You MUST NOT change the interface Game.
ONLY the methods specified in the Game interface should be public in Player. However, you can provide
private methods in Player to improve readability & maintainability, reduce duplication or perform well-defined
tasks
Your design should include appropriate supplier classes to handle the detailed implementation of the system. You are
reminded that classes should not provide output directly to the Terminal window. Two class ChampionState and
ChallengeType have been provided. You are not required to use these classes, but not using them may cause
delays. Your system should also include some appropriate robustness checks.
7. 3 – Demonstration (Tues 15/11 at 9.00 and 10.00)
 The demonstration will take place during your designated practical session. You will be asked to demonstrate that
you have a good working knowledge of the code that you submitted. The main purpose of the demonstration is to
authenticate your code by showing that you know it well enough to use it and make changes.
 The demonstration must be completed INDIVIDUALLY.
 You will be given a written specification of the tasks to be completed for the demo. You will have a 50 mins to
complete the tasks
 You will be asked to download your submission from Studynet, complete the tasks and submit your amended code
to new assignment on Studynet.
 The tasks may ask you to:
 add new champions or challenges
 add new types of champions
 change some rules of the game
 add a simple tester class
Page 5

6COM1037 OO development Coursework 1 Nov 2016
 If you do not attend your designated demonstration session, your assignment will be given ZERO marks.
Students with a Learning Agreement entitled to extra time should attend the 9.00 session.
8. Submission Arrangements
8.1 Submit to Studynet by 14/11/2016 by 22.00
 A .zip Netbeans project which compiles and has a completed Teamwork class
 Each programmer in the pair should submit individually
If you do not submit your code to Studynet, you will be unable to do the demonstration
8.2. Demonstration session – 15/11/2016
 Upload your completed demo to the new Studynet Assignment at the end of your session time.
 Hand the demo briefing sheet which should have your name and student registration number (and those of
your pair) back to the supervisor.
9. Marking
Your code will be marked automatically testing software using out test data. See marking scheme on Studynet
There will also be design marks for appropriate use of classes/objects, collections, inheritance & enums, as well as the
maintainability of code.
Generic
Grading Criteria
no
merit
clear
fail
marginal
fail
satisfactory good very
good
excellent outstanding
Marks 0 - 19 20 - 39 30 - 39 40 - 49 50 - 59 60 - 69 70 - 79 80 - 100
The total mark will be scaled to count as % of the mark for the module.
Feedback will be by personalised feedback sheet posted to Studynet and can be discussed with tutors during practicals
Appendix A – Sample Data
Champions
Name Skill
level
Necromancer Hire fee Spell
Speciality
Weapon Talks
Ganfrank 7 yes 400 transmutatio
n
wizard
Rudolf 6 yes 400 invisibility wizard
Elblond 1 150 sword warrior
Flimsi 2 200 bow warrior
Drabina 7 500 no dragon
Golum 7 500 yes dragon
Argon 9 900 mace warrior
Neon 2 no 300 translocation wizard
Xenon 7 500 yes dragon
Challenges
Challenge No Type Enemy Skill
Required
Reward
1 Magic Borg 3 100
2 Fight Huns 3 120
3 Mystery Ferengi 3 150
4 Magic Vandals 9 200
Page 6

6COM1037 OO development Coursework 1 Nov 2016
5 Mystery Borg 7 90
6 Fight Goths 8 45
7 Magic Franks 10 400
8 Fight Sith 10 170
9 Mystery Cardashians 9 300
Page 7