Edited and added own code to game

[jesse1234-cyber]

kindly review @Berritua

[jesse1234-cyber]

please review @Bartechnika

[moonlitlyra]

Pass Standard

Requirement	Review
The code compiles and runs	Code compiles and runs without error in Visual Studio 2022
The player can explore at least one room	Yes. Navigation is by an option menu within each individual room: actions include picking up an item and viewing the players status.
Object instantiation, method calls evident	Every Room is an instance of the Room class and a method is used to view the description and handle item management. The player class has methods covering different aspects of the brief including PickUpItem() and TakeDamage().
There is code review from two students	N/A
Handle invalid commands gracefully without crashing the program	The action menu is controlled using switch-case statement block and no exceptions are raised.

2:2 Standard

Requirement	Review
Rooms can contain multiple items or monsters	Currently each room contains a maximum of one item. Modifying the item field to be of type item[] and modifying the item handling methods slightly would allow each room to store more than one item.
The Testing class is used	No testing class is implemented, but user input is handled gracefully without exceptions.
The player can pick up items through an implementation of the Player.PickUpItem() method	Yes
The C# style guide is followed partially	1. Variable names follow camelCase convention and are both intuitive and simple, with PascalCase used for all primary constructors. 2. String interpolation via the $ special character is used successfully. 3. Concise object instantiation would improve code readability. (e.g. private List inventory = new() instead of private List inventory = new List ();) However, this feature is only available in the newest versions of C#. 4. Single line comments are descriptive. However, there is a minor error in the Player class. For both the player Name and Health the comment reads “Read-only property”. However, Name and Health are both public fields – so are not readonly.
At least one room has a description and can contain one item or one monster. These functionalities are given by Room.GetDescription() method	All rooms contain a description which is parsed at instantiation. All rooms contain at least 1 item.
Method calls from “Main” to methods in other classes	Yes

2:1 Standard

Requirement	Review
Pull Requests and code reviews are noted	N/A
You have taken account of reviews and merging your changes	N/A
There is a complete implementation of your code with no issues	Code compiles and runs without error in Visual Studio 2022 and no exceptions have been raised through testing.
Commenting is mostly through the code files	All methods and class fields are commented and as such the code is easy to understand. I particularly like the use of single line comments to explain the purpose of code. For example, the comment “Ensure health doesn't go below 0” in the player TakeDamage method states the use of a single-line statement to cap Health at 0.
There are at least one Game and Player objects	Yes
There is evidence of testing	There is evidence of testing in sections of code that are not called by the main program including the TakeDamage() method. The comment states it is an optional future feature, suggesting testing took place during the development of this section of code.
Error handling is performed well but there are still issues	No issues. The use of the ternary conditional operator ? in the InventoryContents() method is inventive and ensures an appropriate error message “Nothing yet” is displayed instead of an empty inventory.
There is clear evidence of object-oriented features such as classes, object instantiation, encapsulation and methods	Game, Player and Room classes are used appropriately to break down code into smaller modules. Use of private fields is made in the Room class on description and item which are only accessible through user-defined methods.

First Standard

Requirement	Review
You have taken effective account of the reviews by merging your changes or suggesting alternative approaches	N/A
The video demonstrates a critical reflection and that you learned from the assignment’s experience	N/A
The implementation is complete with excellent error handling	No exceptions are raised and user input is validated appropriately.
The C# style guide is shown to be adhered to. XML documenting comments are throughout the code	XML comments are not used to summarise class, method or property types. However, almost all sections of code are accompanied by a single-line commenting explaining their purpose. Code would benefit from XML comments for all class and method definitions.
The testing class uses ‘debug.assert’ to verify aspects of the code	The use of a testing class is not present but could easily be implemented.
The implementation of classes, object instantiation, encapsulation and methods are complete and with no issues	All object-oriented features are implemented flawlessly.

[moonlitlyra]

Notes on action menu interaction

• I particularly like the use of Console.Clear() to maintain minimal text display for the user and reduce sensory overload. However, this does cause an issue with cases “1” and “default” of the switch-case statement block. For example, in case 1,when the player picks up an item, the code is suppose to display “You picked up a {item}.” to the user. However, because the while loop immediately starts again the next statement executed is Console.Clear(), meaning all console output related to item pickup and invalid user input (managed by the default case) is cleared straight away and cannot be seen by the user. Adding Console.ReadKey() to the bottom of every case statement would solve this issue.
• The blocks of the case statements handling the action menu choice could be simplified with additional methods. For example, the case “3” handling player status could be moved to a separate method PlayerStatus() called by case “3”.

[Berritua]

                                                           **Implementation Overview**

The submitted implementation of the Dungeon Explorer project follows the basic requirements outlined in the assessment. The core game mechanics, including movement and interaction, are functional. However, there are some design choices that could be improved for better user experience and maintainability.

Strengths:

Basic Game Functionality Implemented:

The core game logic, including movement, object interaction, and exit handling, is implemented correctly.

The structure of the code follows object-oriented principles with a clear separation of concerns.

Consistent Input Handling:

The game effectively processes user input, correctly mapping numerical values (1, 2, 3) to respective actions such as picking up items, checking status, and exiting.

This simplifies user input validation and ensures fewer input errors.

Readable Code Structure:

Variable and method names are meaningful, making the code relatively easy to understand.

Code is organized into logical sections, enhancing readability.

Overall, the implementation meets the basic requirements effectively. Great job