1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
# Project Title
Team members:
- Freya Murphy <freya@freyacat.org>
- Audrey Fuller <alf9310@rit.edu>
- Yusif Elsharawy <yse2561@rit.edu>
- Ryan Symons <ras1178@rit.edu>
## Summary Description
Embark on a classic roguelike dungeon-crawling adventure. Players will explore
procedurally generated, tile-based dungeon floors crafted using a Wave Function
Collapse algorithm. Battle through waves of enemies with turn-based combat,
collect powerful items, and push your limits to see how deep you can delve
into the ever-changing depths.
## Additional Details
### Use Cases
#### Player Input
- Directional Movement: The player can move up, down, left, or right across a tile-based dungeon map using WASD or arrow keys.
- Combat Actions: On encountering an enemy, the player can choose to attack or use an item.
- Item Interaction: The player can pick up items, manage inventory, and use consumables like potions.
#### Gameplay Loop
- The player spawns on floor 1 of the dungeon.
- The map is procedurally generated using the Wave Function Collapse algorithm.
- Enemies and items are randomly spawned on valid tiles based on probabilities.
- The player explores and collects items until encountering an enemy.
- A turn-based battle begins where both player and enemy take alternating actions.
- After winning, the player collects loot and continues exploring until finding the staircase to the next floor.
- Difficulty increases as the player descends deeper.
One or more typical “use cases”. These might include “storyboards” explaining
how a user would interact with the program or some interesting “input/output”
examples.
### Components
**Dungeon**
- A sketch of intended components (key functions, key data structures, separate
modules).
### 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.
- 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.
***
***
The following should be deleted from the proposal document, but is included in the initial `Proposal.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\%)
|
