Dungeon Adventure 2.0: The Spoony Bard Returns

Click on the hamburger menu in the top left corner of the README.md cell.

Project Synopsis

Dungeon Adventure 2.0: The Spoony Bard Returns (bards not yet included) is an expansion of our original Dungeon Adventure game.

A pure python game dependent on TKinter.

  In this game, you play as a novice programmer who finds themselves trapped in a mysterious
  dungeon. Your task is to escape the dungeon by collecting the 4 pillars of object oriented
  programming: abstraction, encapsulation, inheritance, and polymorphism.The dungeon is filled with
  hidden dangers at every turn. Deadly traps and ferocious monsters lurk in the shadows, waiting for
  their next victim. You must use your programming skills to navigate the treacherous terrain and
  avoid these dangers.

  But beware - the dungeon is full of traps and enemies that will test your skills to the limit.
  You'll need to use all your wits and cunning to survive and make it to the end of the dungeon.

  Can you collect all four pillars of object oriented programming and escape the dungeon alive? Only
  time will tell. Good luck, adventurer!

Features

Game Start

Creating a new game, select one of three adventurers

Moving around the dungeon by using the navigation buttons

Fight monsters throughout the harrowing adventure

Use the in-game map to determine the location of the exit

Collect all the pillars to unlock hidden powers

Save your progress and pick up where you left off

Escape the dungeon alive with all 4 pillars to win

Functional Requirements

Classes stored in database.
Dungeon difficulty stored in database.
Pillar unique powers included in game (double health potion collection, double vision potion collection, reduced damage, improved potion potency that allows increasing maximum health).
Health potions usable in combat.
Really well documented, human-readable code.
Great test coverage and OOP implentation with mocks for abstract classes (app/unit_tests/character_tests/abstract_classes/tests)
Fleeing implemented in demo version!
Packages to assist with easy module import and not a giant file with all our game's files.
Turn order for each round completed in a single attack action in DungeonBrawler

Contributors:

Kevin Chung

Hours clocked: ~70 hours
Git history entries: 74

game_controller.py code
BaseFrame
DungeonCrawler(Dungeon traversal, inventory management, and item usage)
DungeonBrawler(Combat completed in turns, combat history log, and potion usage)
Turning in weekly deliverables
Software Requirements Sheet (SRS)
Unified Modeling Language (UML)

Xingguo Huang

Hours clocked: ~72 hours
Git history entries: 66

DungeonAdventureGUI(adventurer information from user)
Map display(3x3 grid) and map display(whole dungeon) for debugging
Colors adjustment on DungeonCrawler dungeon display to make the game more user-friendly
Win/lose window set up and game summary display

Stephanie Liu

Hours clocked: ~60 hours
Git history entries: 66

Model & DB code (including refactoring Kevin's adventurer code from last quarter to match the needs of this quarter)
app\view\load_view.py in all its ugly glory, and refactoring of views to call supers to allow load_view to be opened from relevant views.
Save and Load methods in controller/game_controller.py
Debugging of view / controller / model integration prior to project demo
README.md
UML
SRS

Dependencies:

Python 3.9+
PIP
TKinter
SQLite

How to play and run the project:

Verify Python 3.9+ is installed:
Verify PIP is installed:
Open a terminal in project root directory, run following commands:

python3 -m venv venv
source/bin/activate
pip install -e .

Verify TKinter installed:
Start the game with this command

python3 app/main.py

Project design docs and completed user stories

assignment_documents/the_spoony_bard_returns_uml.pdf
assignment_documents/SRS.pdf
assignment_documents/pivotal_tracker.pdf

Challenges

The project has some integration bugs that need to be addressed.
There have been challenges with tKinter to make it behave properly for gameplay, which requires further investigation.
The use of TKinter was not very intuitive and the documentation was inconsistent, leading to some unexpected limitations and challenges.

Lessons Learned

UI testing is done manually, which may result in missed issues or errors.
The room initialization code needs to be fully refactored to store all the generation information and logic within the dungeon_builder class, like other classes in the project.
The game could benefit from more descriptive information when entering rooms to improve the player experience.
In some instances throughout the project code, the view and controller components felt coupled together, which could be refactored to improve the overall design and architecture.
Refactoring the old code base to allow for easier integration with new features is needed. This requires a thoughtful design approach to ensure that the adjustment is modular and makes sense for the project's architecture.

kev-odin/dungeon-adventure