Legend of Zelda First Dungeon Remake

Coders: Gabrielle Michaille, Rose Hoelzel, Max Vargas, Ivana Barac, Sam Halsey, Alexander Durbin



Sprint 2: Due Date of Sept 30th
  - Currently working on enemies, items, blocks, projectiles, and Link. 
  - Redesign using better design patterns. 

  So far:
    - ICommand: with all currently working needed ones (u/i for items, o/p for enemies, wasd for Link, z/n to attack, etc)
    - State machine for Link
    - Factories for creation of all major objects (ie Link, enemies, items, etc)
  
  Bugs/Things to fix:
    - Coloring of the sprints
    - Movement of enemies to fix 
    - Some refactoring for better cohesion, coupling, use of code patterns
  
  Code Reviews:
    - REALLY NEED TO GET ON WITH THAT
  
  Code Metrics:
    - Really need to get on that as well 



Sprint 3: Due Date of Oct 21st
  - Currently working on implementing further dungeon implementation 
  - Big focus on collisions, rooms, movement between roosm, refactoring

  So far:
    - Collisions for most things
    - Keyboard refactored successfully, and all controls work
    - Different rooms, and good json files to load all rooms in from 
    - Keyboard Coupling is so much farther down!
  
  Bugs/Things to Fix for Next Sprint:
    - Continuing refactoring (ie command class, eliminating magic numbers, etc)
    - Implement dungeon manager for less game1 coupling
    - Attack draw is a bit weird from spritesheet (but functionality is there)
    - Fix boomerang angle for up movement direction of link
  
  Code Reviews:
    - Much better! A review for every PR, but perhaps should add additional info.
  
  Code Metrics:
    - Have the metrics and graphs - but will try to add a graph for every single metric, rather than just maintainability and coupling



Sprint 4: Due Date of Nov 13th
  - Currently working on finishing dungeon implementation
  - Big focus on refactoring (collisions, txt file, magic numbers), game state, full dungeon implementation, HUD, music

  So far:
    - Game states all work
    - Full HUD, music, and link health work
    - Full dungeon implemented through json file
    - Major refactors sucessfully done 
    - Brainstormed ideas for Sprint 5

  Bugs/Things to Fix for Next Sprint:
    - Finally do dungeon manager
    - Fix bug where reset only works except when you see game over 
    - Positions of some objects a bit innacurate 

  Code Reviews:
    - Much better! There were comments for every PR, and a lot more commenting of changes that could be good to do (things we previously would discuss in person/in text but not write down)

  Code Metrics:
    - Have the metrics and graphs pretty well done + paragraph giving an overview of it.

  Key Bindings:
    - Mouse to navigate between each room
    - ASWD/UP DOWN LEFT RIGHT keys for movement
    - M for muting music
    - Q for quit
    - P to pause
    - U to unpause 
    - X to game over (for testing purposes)
    - D2, D3 for switching between weapons
    - D1 to shoot 
    - R for reset 
    - N, Z to attack with sword 
    - I for inventory



Sprint 5: Due Date of Dec 8th 
  - Most sprint was focused on fixing issues from Sprint 4 (broken functionality such as reset, incorrect functionality such as item switching, missing functionality such as blocks and doors/keys.
  - Refactoring was also a big focus, with a tiny bit of new functionality 

  So far:
    - Inventory/HUD fixed better, more accurate implementation, more complete
    - Smooth transitions between rooms finally implemented
    - Overhaul of item creation (many were not using factories) + individual classes sound manager and load content manager created to better take care of sound effects and textures 
    - Lots of debugging from code of sprint 4 (i.e. fixed crash that would happen when inventory was accessed)
    - Refactoring of Game1 into dungeon and room manager functionality
    - More blocks, more accurate enemies, and items actually fully added into JSON
    - Better enemy movement + enemy collision bug fixes
    - Collision functionality further refactored
    - More items (i.e. full map and compass) and additional extra enemies (such as goriyas) added
    
  Bugs/Things to Fix for future work potentially if it was a thing:
    - Further refactor to have overall better code quality (i.e. better decoupling of Game1, more use of patterns)
    - Fully adding + better drawing of blocks - i.e. for prettier graphics
    - More testing 
    - Get rid of spacing between each room 
    - Better task management (currently mainly managed by 3 people only)
    - More research

  Code Reviews:
    - Pretty good! Each PR went through group reviews, especially with the recent bigger focus on code quality
    - Every PR had a comment reviewing either code readability or code quality -- some a recap of subjects discussed as a group at meetings or in a chat

  Code Metrics:
    - Have the metrics and graphs pretty well done + paragraph giving an overview of it.

  Tasks use:
    - Honestly not the best; despite trying to make more of a focus on it, they were not tracked as well as they should have been (in terms of timeliness and giving useful updates on them)

  Key Bindings:
    - Mouse to navigate between each room
    - ASWD/UP DOWN LEFT RIGHT keys for movement
    - M for muting music
    - P to pause
    - U to unpause 
    - X to game over (for testing purposes)
    - Q for quit
    - R for reset 
    - D2, D3 for switching between Link items
    - D1 to shoot/use items
    - N, Z to attack with sword 
    - I to open inventory

  Overall overview of entire project:
    - A decent recreation of The Legend of Zelda (1986)
    - Lots of learning in terms of code design, code quality, software design patterns, git, and group dynamics
    - Some struggles along the way, but we managed as a team to get through everything and create a decent game! 



Sprint 3 Paragraph reviews based on graphs:
  - Coupling for our five classes (EnemySprite, ItemSprite, KeyboardContr, Game1, Sprite) have gone down or stayed level.
    - This means that even additional functionality has not highly impacted our coupling (although perhaps the other new classes, such as collisionDetector, is experiencing a lot lot more coupling).
    - Keyboard Controller first went up with the beginning of Sprint 3, but decreased after we refactored, which is a great sign that our refactoring was helpful.
    - Game1 was the only exception to the decreased coupling trend, as its coupling increased (which should have been the opposite during Sprint 3).
       - We were going to refactor Game1, and specifically implement dungeon manager, and that would indeed have helped lower coupling, but we did not have the time to actually get around to it. This will be something to look at and do especially in Sprint 4.
  - Maintainability luckily seems to have stayed steady or gotten better (the latter especially in regards to keyboard controller), which is a good sign for us; it seems like our new code and refactoring is helping to keep this project pretty neat and easy to understand.

Sprint 4 Paragraph reviews based on graphs:
  - Coupling for four of our classes (EnemySprite, Sprite, KeyboardContr, ItemSprite) either decreased or stayed constant from previous sprints.
    - This means that even as we were adding more functionality (additional collisions, health, music) did not impact our coupling
    - Keyboard Controller staying down was good to see too, since we added new keys bindings for the additional functionality we added 
    - The only exception to the coupling trend was the game1 class, which greatly increased :(
        - This makes sense we added a lot of new functionality (such as music or hud) and initialized them in Game1, thus increasing our coupling. Dungeon manager would have helped with this, which is why it is one of our bigger goals of sprint 5.
  - For maintainability, interestingly enough, it largely remained the same or slightly increased or decreased
        - We were expecting a large decrease in maintainability for game 1, but it only decreased a little bit (and never got as worse as keyboard controller once was)
        - This means that we did pretty good with maintainability over this sprint, though we could still definitely do more for game 1
  - Thus, overall, the code metrics show us that we def still have work to do, but we also did pretty well this sprint

Sprint 5 Paragraph reviews based off of code metrics graphs:
TO DOOOO

