Checkpoint writeup started

2 files changed, 80 insertions, 31 deletions

diff --git a/docs/Checkpoint.md b/docs/Checkpoint.md
index f6d87f3..1f10548 100644
--- a/docs/Checkpoint.md
+++ b/docs/Checkpoint.md
@@ -9,13 +9,91 @@ Team members:
 
 ## Summary Description
 
-Reiterate the summary description of the overall goal of the project (updated as
-necessary from the Proposal document).
+Embark on a classic roguelike dungeon-crawling adventure. Players will explore 
+procedurally generated, tile-based dungeon floors crafted using Binary Space Partitioning. 
+Battle through waves of enemies with real-time combat, collect powerful items, and 
+push your limits to see how deep you can delve into the ever-changing depths.
 
 ## Checkpoint Progress Summary
 
 Give a summary of the progress made and lessons learned thus far.
 
+So far, our group has been able to achieve most of our MVP functionalities, including:
+- Dunegon floor procedural dungeon generation
+- Player movement and enemy spawning
+- Collision Logic
+We've even managed to achieve some stretch goals and additional features:
+- Usage of pixel art sprite sheets
+- Item/Inventory system
+However, we still have yet to implement a full enemy/player combat loop (attacking and defending).
+
+## Lessons Learned
+With the work completed so far, we've gained a greater understanding of creating Rust 
+programs from the ground-up, however this came with some roadblocks.
+
+### Goodbye Wave Function Collapse 
+The nixing of the Wave Function Collapse Algoritm for dungeon generation was an unfortunate 
+but nessesary step in the development of this project. After fully writing a generic 
+implementation of the algorithm and testing it, we learned that tragically WFC does not 
+guarantee it's constraints are imposed globally, only in small local patches. This means 
+that it doesn't guarantee every dunegon room will be accessable from the player's start location.
+While there are workarounds for this, it usually involves pairing WFC as a post-processing step 
+on a complely different generation algorithm that does guarantee connectivity. So ultimately
+after more thourough research, we switched to Binary Space Partitioning for generating the 
+map instead. 
+
+### Float vs u64 vs usize
+Another issue during development was the standardizarion of our data types for dungeon structure, 
+traversal and generation. With several of us working on differnent but interconnected components, 
+there were some instances where we would define our type fields for storing location information.
+This lead to refactoring later to standardize most of our dungeon-related types into u64, as placing
+expect(clippy::cast_possible_truncation) every few lines isn't what I would call "good practice". 
+
+### Raylib Double Free
+TODO
+
+### Windows HATES Default Features
+TODO
+
+
+## Structure
+
+### **Game Crate**
+Initializes the game state and handles the Model-View-Controller loop and player movement.
+
+### **Dungeon Crate**
+Contains the core functionality for interacting with a dungeon and it's components.
+- **[astar](dungeon\src\astar.rs)** -  Generic A* Pathfinding Algorithm Implemented for Player Movement.
+- **[bsp](dungeon\src\bsp.rs)** -  Binary-Space Partitioning Algorithm for Dungeon Tile Generation.
+Recurively splits the dungeon into randomly sized rooms, then collapses the tree upwards connecting each root node.
+- **[bsp_tests](dungeon\tests\bsp_tests.rs)** - Integration tests to verify all moveable tiles are connected. 
+- **[entity](dungeon\src\bsp.rs)** -  Contains the structures for all entities, including the player, items and enemies.
+  Implemented features:
+  - Enemy movement
+  - Inventory
+- **[map](dungeon\src\map.rs)** -  Structures for the dungeon game map including the current `Floor`, and map `Tile`.
+- **[player_input](dungeon\src\player_input.rs)** -  Carries information about player inputs, including mpve direction.
+- **[pos](dungeon\src\pos.rs)** -  Representation of a position and direction inside the dungeon grid.
+- **[wfc](dungeon\src\wfs.rs)** -  **Not Used** Wave Function Collapse Algorithm for Dungeon Generation.
+
+### **Graphics Crate**
+Core functionality for 
+- **[audio](graphics\src\render.rs)** -  Framework for loading audio assets during runtime. 
+- **[render](graphics\src\render.rs)** -  Defines wrappers for calling the raylib library for sprite displaying.
+Implemented Features:
+  - UI 
+  - Text
+  - Texture loading
+  - Debug view
+  - Tilemap with foreground and background
+  - Minimap
+  - Stats
+  - Camera locked to player
+
+
+## Work To Do For the Final
+TODO
+
 ## Additional Details
 
 - List any external Rust crates required for the project (i.e., what
@@ -26,31 +104,3 @@ Give a summary of the progress made and lessons learned thus far.
   feedback on specific aspects of the project.
 
 
-***
-***
-
-The following should be deleted from the checkpoint document, but is included in the initial `Checkpoint.md` file for reference.
-
-## Final Project Rubric
-
-- Correctness (15%)
-  - Free of compilation errors and warnings.
-  - Correctly accomplishes the goals of the project.
-  - Correctness is supported by suitable testing.
-- Style/Design (15%)
-  - Project applies one or more elements of Rust design:
-    - Uses traits.  Minimally, makes use of traits from the Rust Standard Library (e.g., `PartialEq` and `Iterator`).  Better, implements appropriate traits for the types defined for the project.  Best, defines and   uses novel traits for the project.
-    - Uses `struct` and `enum` definitions appropriately.
-    - Uses types to capture invariants.
-    - Uses modules appropriately (e.g., place distinct data structures in distinct modules).
-- Effort/Accomplishment (30%)
-  - How “big” is the project?
-    - A “small” project will have at least 500 Lines of Rust Code per team member.  (Significantly less than that corresponds to a “tiny” project and would not be acceptable for this activity.)  A “medium” or “large” project may have significantly more and would likely also correspond to a more “difficult” project (see below).
-  - How “difficult” was the project?
-    - An “easy” project that required trivial data structures and algorithms. Feedback about how to extend the project was ignored.  (Projects falling into this category are likely to lose points in Style/Design as well.)
-    - A “moderate” project that applied basic course concepts, but did not require the group members to significantly challenge themselves or to learn something new.
-    - A “challenging” project that demonstrates significant thought in design and implementation.  Clear that the group members challenged themselves and learned something new by undertaking the project.
-  - What work was done for the project?  (This includes both the work embodied by the final submission and work not obvious from the final submission (e.g., approaches attempted but then abandoned, suitably described).)
-  - Did the project require learning advanced features?
-  - Did all team members contribute to the project?
-- Presentation (10\%)
diff --git a/docs/Proposal.md b/docs/Proposal.md
index 39d5100..aaff431 100644
--- a/docs/Proposal.md
+++ b/docs/Proposal.md
@@ -145,7 +145,6 @@ For our test libraries, we'll be sticking with the #[test] built-in functionalit
 - Item effects and inventory behavior.
 - Player movement and boundary checking.
 
-
 ## Development Plan
 
 ### Minimum Viable Product (MVP)