Initial proposal doc finished

1 files changed, 22 insertions, 39 deletions

diff --git a/docs/Proposal.md b/docs/Proposal.md
index db1bbae..4738ab0 100644
--- a/docs/Proposal.md
+++ b/docs/Proposal.md
@@ -127,48 +127,31 @@ Core functionality for rendering using the `raylib` library. Independent from ga
 
 
 ## Testing 
-- Thoughts on testing. These might include critical functions or data structures
-  that will be given `#[test]` functions. Also consider using the
-  [`insta`](https://crates.io/crates/insta) crate,
-  [`mockall`](https://crates.io/crates/mockall) crate,
-  [`proptest`](https://crates.io/crates/proptest) crate,
-  [`quickcheck`](https://crates.io/crates/quickcheck) crate,
-  [`test_case`](https://crates.io/crates/test-case) crate, or [`cargo
-  fuzz`](https://rust-fuzz.github.io/book/cargo-fuzz.html) tool.
 
+For our test libraries, we'll be sticking with the #[test] built-in functionality. 
 
-- Thoughts on a “minimal viable product” and “stretch goals”. Be sure to review
-  the final project grading rubric and consider organizing the project around a
-  core deliverable that will almost certainly be achieved and then a number of
-  extensions and features that could be added to ensure that project is of
-  suitable size/scope/effort.
-- Expected functionality to be completed at the Checkpoint.
+**Critical Tests**
+- Map generation consistency (#[test] ensuring WFC produces valid connected maps).
+- Combat damage calculation and turn order validation.
+- Item effects and inventory behavior.
+- Player movement and boundary checking.
 
-***
-***
 
-The following should be deleted from the proposal document, but is included in the initial `Proposal.md` file for reference.
+## Development Plan
 
-## Final Project Rubric
+### Minimum Viable Product (MVP)
+- Single floor procedural dungeon generation using WFC.
+- Player movement and enemy spawning.
+- Turn-based combat with basic attack logic.
+- Simple boxes and circles as sprites
 
-- 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\%)
+### Stretch Goals
+- Multi-floor progression with increasing difficulty.
+- Expanded item system (weapons, armor, consumables).
+- Player stats and leveling.
+- Usage of pixel art sprite sheets.
+
+### Checkpoint Goals
+- Procedural map generation functional and debuggable.
+- Player movement implemented with basic collision detection.
+- At least one working enemy and combat loop.