ITEC 3860 Group Project Fall, 2015

advertisement
ITEC 3860 Group Project
Fall, 2015
This semester long project is designed to take you through the
different stages of the Software Development Life Cycle. You will
submit multiple assignments (as a group) throughout the semester
which added together will result in your Group Project Grade.
Each of the following will be a graded event in the group project:
• Requirements
• System and Object Design
• Unit test
• Implementation
• Presentation
• Peer/customer reviews
Project Description:
 Your project this semester is to build an adventure game.
 This can be a text based adventure game or if the implementing
team choose to go beyond text and create a graphic game that is
the team’s option.
 Each team will be responsible for not only developing their own
game, but act as a customer for another team.
If you haven’t played a text based adventure game before, there are
several at:
– http://textadventures.co.uk/games/tag/rpg
– http://www.web-adventures.org/
– http://www.freearcade.com/textadventures.html
Project Requirements:
1. Each team will discuss discuss and develop a game with a set
of rooms.
a. This will become the requirements document for another
team.
b. You will be the customer for the development of these
requirements.
c. The requirements will map out at least 30 different rooms.
d. There must be at least 7 puzzles to solve
e. There must be 8 monsters to fight.
f. Each room should have a random chance of a monster or
puzzle. They don’t have to be in the same room.
g. Puzzles should be presented as part of the description and
not have a specific puzzles designation for the user.
h. Each puzzle should have an acceptable solution provided.
2. Once the rooms, puzzles and monsters are decided upon.
The team will develop a set of requirements for their
implementing team and document it in a software
requirements specification. The following implementation
requirements must also be detailed:
a. Each room will have a description, defined exits, fixed
monsters to fight if applicable and if desired, a puzzle for
the user to solve.
b. Random monsters should be a possibility for each room.
Each room may have a unique probability for having a
monster.
c. The user must be able to request a list of commands as
part of a help system.
d. Players will be required to solve puzzles, fight monsters,
take and inflict damage, equip and use items like armor,
portions, scrolls and weapons
e. Player will be able to save and return to the game where
they left off.
f. The game will recognize different users and keep track of
their place in the game.
g. The game will track each player’s score and rooms that
have been visited. Once a puzzle is solved or monster
defeated, we should not see that puzzle or monster again.
h. The game will track player inventory. There should be an
upper limit of the amount of items a player can carry.
3. Once complete, each team will give their requirement
document to the implementing team and allow the
implementing team to ask questions in a requirements
meeting. (Class time will be given to allow each team to serve
as customer and implementers).
4. Each team will produce a System Design. This should be a
high level technical design. Large interfaces and high level
components should be identified. This will be included in a
software design specification along with Object design.
5. A unit test plan will be produced prior to beginning code.
When appropriate, these should be Junit tests. The classes
which involve user interface should have manual tests planned
and developed. Each team member should develop tests for
the code they will be implementing so this will be graded
individually.
6. The Object Design will use UML to show the system
decomposed into classes. This should include any inheritance
and relationships between classes in your system.
7. Implementation will be done and graded individually. Each
team will have their own Git-hub repository and will check all
code into the repository. Code not submitted to the repository
will not be counted in each individual’s grade.
8. If we have enough time, each team will then test the code of
the team they are serving as customer’s for. Teams should
deliver the code to their customer in an easy to run format. ( jar
file with instructions)
9. Each team will present the game they developed to the class
at the end of the semester. Presentations should be around
25 minutes including 5 to 10 minutes for questions. All team
members should be present for the presentation. This is not
just a demo, but should include brief info on all stages of
development using PowerPoint or equivalent and a demo of
the game.
Download