COMP 155 Object-Oriented Programming 2

COMP 155 Object-Oriented Programming 2 Nov 2019
|Text Adventure Game Project|
Objectives
1. work with class inheritance
2. work with packages to organize classes
3. use polymorphism to reduce redundancy and write more generalized code
4. practice writing your own classes and using them
5. work with user input and validate it, making use of exception handling
You are expected to submit something very different from each other for this assignment.
The code for the TextAdventureProject is available on Blackboard in the same place this assignment
document is posted. We have written quite a bit of code already involving very basic concepts for graphics
(using chars as \pixels”). You must write your own classes to complete a game with some simple graphics.
There are around 30 classes altogether within the packages provided, and it is essential for you to be able
to stay organized while making sense of what is already given. Generate the documentation with the
following command:
javadoc -package -noqualifier java.util:java.lang -sourcepath src src/*.java -d doc
,! -subpackages .
. . . and note the period at the end of the above command (ask me for help understanding the options).
When you download the TextAdventureProject folder, place it inside a workspace folder, and open Eclipse
using your workspace folder. Create a new Java Project and make sure now to select \Create separate
folders for sources and class files,” and name the project TextAdventureProject. You should
see the doc folder, a src folder with package folders inside it, and source code inside the package folders.
Having a src folder for your source code is good organization for larger projects with lots of classes and
packages. Eclipse will continue to take care of compiling for you, but it is still good to know how to
deal with compiling your source code on the command line. Make sure you can compile and run on the
command line from within the project folder:
javadoc -package -noqualifier java.util:java.lang -sourcepath src src/*.java -d doc
,! -subpackages .
The command above will generate the bytecode files in the bin folder automatically. When there are many
source code files, it is much more organized to have a separate folder for *.class bytecode files.
You should never move or rename any files within the project yourself from a File Explorer program, as
otherwise Eclipse will lose track of where your files are and not be able to compile or execute your project.
Always look for the options to do these things inside Eclipse menus.
Use Javadoc to document any new classes you write. Use doc comments to describe each class, and each
COMP 155 Object-Oriented Programming 2 Nov 2019
method in the class. It is highly recommended that you do not leave writing documentation until after
you are done writing your code. Use the index.html file as a reference and update it frequently to help
you stay organized. This is essential for larger projects.
Having a concise UML of some of the classes can be helpful. Symbols to represent access modifiers:
+ means public # means protected ~ means package-private – means private
The above access modifiers are listed in order of most accessible, to least accessible.

BorderBox (format package)
– Chars2D buffer
– Point2D topLeft
– Point2D bottomRight
– char stroke
+ setBuffer
~ shiftCorners
~ draw
Chars2D (format)
– char DEFAULT CHAR = ’
– StringBuilder output
– int width
– int height
– char[][] pixels
+ clear
+ get
+ set
+ getFormattedString
+ drawLine
Player (performers)
# int MAX HIT POINTS = 70
# int hitPoints
# int strength
# int wisdom
+ getMaxHitPoints
+ getHitPoints
+ damageHitPoints
+ getStrength
+ getWisdom
+ setHitPoints
+ setStrength
+ setWisdom
+ isDead
+ attack
+ castSpell
Billboard (format)
– int MAX WIDTH = 70
– int MAX HEIGT = 30
– Chars2D buffer
– int width
– int height
+ getFormattedMessage
– setWidth
– setHeight
– placeBorderAndFill
– placeMessage
– centrePlace
(enum) PlayerType (performers)
+ WARRIOR
+ WIZARD
+ getValues
+ size
Point2D (graphics)
+ int x
+ int y
+ translate

The above UML is meant to be a short introduction to what is available, and index.html should be your
main source of documentation. Please give yourself enough time to read the code that is already given.
You will not be able to do your work properly otherwise.
Without modification, the source code given will compile and execute a basic and unfinished interactive
game. The functionality provided is meant to help see at least one way to design a slightly larger project.
You may need to exit endless loops while executing on command line|remember, you can press CTRL-C
to stop.
COMP 155 Object-Oriented Programming 2 Nov 2019
Most of the code you write should make use of the code already provided. Making a game involves creativity
and imagination. There is no \perfect” solution, and your marks will be based off of how you decide to
create code that uses the superclass, subclass, and interface concepts.
Each package organizes source code that together provides some single major functionality in the project.
You could decide to reorganize the packages into a different design of your choice, but please keep the
story and format packages close to their original design. You can add classes to any package you like,
except for the default top-level src package folder|do not change it at all.
You must at least (read my code; some examples already exist; your completions must be different):
• complete the methods of Player and Monster subclasses
• use your brainstorming from labs to write an interactive story: an introduction (plot points 1{3),
multiple middle chapters (plot points 4{6), and at least 3 different endings (plot points 7{8).
• interactive choices for the user should be given throughout plot points 1{6, but not for plot points
7{8. The choices for the user must not be confusing. The choices should change how the story
progresses.
• the places you need to code your story:
{ descriptions in Narrator class
{ interaction in Game class that uses the logic.InputManager to prompt the user
{ GUI output using the logic.OutputManager methods (read their documentation):
∗ printFancyIO
∗ printInfoIO
∗ printInfoStats
{ GUI input from the user by writing your own logic.InputManager methods, similar to:
∗ getPlayerChoice
∗ getActionChoice
• design graphics in the graphics package so that its animation is of your own design to match with
your story in at least one chapter.
• Create a superclass of your own design, and its subclasses must be used in your story. Some ideas
for you:
{ weapons, potions (temporary advantages), or money to buy items.
{ locations (but not rooms printed with graphics), such as shops to buy items or weapons.
There are MANY different ways you could write more functionality into the project, by adding your own
packages, adding methods to the classes already given, or adding variables to keep track of different things
in your game (shared data is kept in the DataManager class).
Develop the following to fit with the context of your story:
• create at least three of your own Monster subclasses (and delete my versions);
• create at least three of your own Player subclasses (and delete my versions);
• create a Bag class for your main character to use that can collect different items they can choose to
use (use the concept of an interface);
COMP 155 Object-Oriented Programming 2 Nov 2019
• change the attack events in the game as part of the climactic battle of plot point 6 in your story.
You are welcome to create your own ideas as part of your game as an alternative to the above work, but you
must describe and ask for approval to do so before November 9. We can discuss ways to make ambitious
ideas more reasonable. For example, some things you might enjoy:
• Redesign the GUI (textbook Chapter 11) to change the game interaction|this would be difficult,
but not impossible;
• one or two animations to go with your story;
• more significant branching in your story to make it more interesting;
• making graphical rooms for the player to explore.
Some things to keep in mind:
• if you change a class significantly, then make yourself the author of the class
• any feedback output to the player as a result of their choices during play should use the
OutputManager printInfo method.
• validate user input so that the player can only enter values for the choices you give them. You could
deal with this in a few different ways, but when interacting with a user it is best to:
{ have the user re-enter values, until they enter a value that can be used without errors
{ example is in InputManager validateUserChoice method, but you must complete writing it
{ test playing your game so that it does not crash; you must handle exceptions
(printStackTrace is a very helpful common method available for any exception object)
Submit Instructions and Marking
You will be asked on the final exam how you used the steps of the Programming Cycle to break down your
work for this project.
The deadline is listed on Blackboard under Project, and you need to submit your work there. Compress
(it must be zip) your TextAdventureProject folder, which contains the src, bin, and doc folders, and
upload only the one TextAdventureProject zipped file.
The assignment is out of 40 marks and will generally be distributed as follows:
• 0{10: your source code is not organized correctly, does not compile, or the game does not show a
reasonable unique effort.
• 10{20: project compiles, but there are bugs that stop play as a complete game, or your code is
written in a grossly unreadable way.
• 20{30: project compiles, the final story goal is clear, perhaps some output bugs that do not stop the
play as a complete game, or your code is organized or written in a way that is difficult to read, or
your Javadoc does not describe your classes and methods correctly.
• 30{40: project compiles, plays as a game, minimal confusion issues, easy to follow instructions,
elegant code style, and maybe only some minor bugs. Documentation also compiles and describes
code in an organized, accurate, and concise way.
COMP 155 Object-Oriented Programming 2 Nov 2019
Further Thought
If you want to learn more about writing narrative for interactive stories, the best thing to do is simply
practice writing as often as you can. Then keep watch for any help you find as you go.
A great open-source program to write interactive stories is called Twine:
http://twinery.org/
In general, I save my writing within a huge directory tree inside Google Docs over time, organizing it
by topics and project ideas. If you collect your writing in bits every day, then you minimize having to
worry about generating ideas under a deadline for future writing work, and you will be more likely to write
about topics that have deeper meaning to you (and therefore, others). Even if you are not an author,
this collecting habit is extremely useful. You do not have to be a famous author to get contract work, for
example writing interactive game narrative, or pitching an idea for a game, even to AAA studios.
It can help to have a few general-purpose files where you only record unedited ideas to sort into separate
and more specific files later for future editing.
Some things I try to keep track of:
• other writers advice, and work (books, TV, movies, video games, graphic novels,. . . )
• reference books on writing style, writing courses, and writing conferences
• vocabulary, voice, character design, and world building
• plot design, and logical reasoning for the meaning of writing
• it still surprises me that most screenplays are free online, even for movies currently IN the theatre!
• editing, publishing, and much more. . .

Leave a Reply

Your email address will not be published. Required fields are marked *