Dungeon Crawler Game, Part 2
Design Due: November 12
Program Due: November 26
To work on the design and implementation of large, collaborative
For this stage of the assignment, you will be adding some new features to
your dungeon crawler game. The teams will remain the same, but now you will be
using Git to share your work. Some of the new things will be game features,
and some will be taking advantage of some of the more advanced features of
Java we have learned.
In addition to the requirements for part 1, your game should add the following
- You should provide at least three different rooms instead of just one.
They also should be linked together. This would be done by having a specific
place in the rooms that takes you to a different room. For example, you can
include a doorway or stairs to travel between the rooms. When the player steps
on these, you should tell them there is portal and ask them if they want to
take it. I would suggest having a "Room" class for handling one particular
room, and a "World" class for storing all three+ and handling which one the
player is in.
- You should add a "Save" command which will save the state of the entire
game into a file. This should include the room the player is in, their
position in it, their inventory, the position of any enemies and items, the
player's health, and anything else needed for the game. There are a few ways
you can do this. You can use the same file always (which will only allow for
one saved game at a time), ask them which of a fixed number of slots they want
to save into, or ask them for a name for the save (which will allow unlimited
- You should also add a "Restore" command to pull this state out of the file.
When starting a new game and then restoring it, the player should be exactly
where they left off.
- You should make the Character and the Enemy classes derived classes from a
common base class (or implement a common interface). This base class will contain the things both have in
common, such as a position, being able to move and having some way of being
displayed on the screen. The code that makes them different should be the only
thing in the derived classes.
- Your project should be stored in a GitHub repository. As you work on the
project with your team, you should commit and push your changes to this
repository. It can be a public repository. When you turn in your code, you
will just email me the GitHub link.
- I may also ask your team to modify things you did in part 1 of the project.
This could be either to improve the quality of your code, to improve the
usability of your game, or to clarify requirements from part 1.
For this project, you will again turn in a class diagram first, and then the
full project later. The design should include all of the classes, with their
methods, and the relationships between them, as discussed in class and the
You should update the design you turned in for project 2 in light of two things:
- The code you actually wrote for project 2 (in cases when you had to modify things as you worked on it).
- The new things for this version of the project.
When writing your program, also be sure to:
- Put each class/enum in its own file.
- Your code should include comments — at least one
for each class explaining its purpose, and one for each method
explaining what its job is.
- All member variables should be private.
- Your code should be consistently indented.
To submit your program, email the GitHub link of your repository to firstname.lastname@example.org.
Copyright © 2019 Ian Finlayson | Licensed under a Creative Commons Attribution 4.0 International License.