in dr racket construct a simple text$-$based $$adventure$$ game. These games have a long history and were a common feature of college computing installations from the earliest days.

In these games, the player$$s character $($often unnamed or simply $$you$)$ is presented with a series of choices about where to go and what to do$.$ There are typically areas to be explored, items that can be picked up or dropped, creatures to fight, and puzzles to solve. We$$re not going to do a full$-$featured game, and our text interface will be quite limited$,$ but this will be enough to present an interesting programming challenge.

The classic scenario is an underground dungeon full of monsters $($a rather unrealistic ecosystem$),$ but you can set your game in any setting you want. It should be something fairly limited$$we$$re not doing a full open$-$world game here. But if you$$d rather do an exploration of Martian canals, or a trip to the grocery store, that$$s fine. Whatever you do$,$ your game must have several features:

There must be at least $4$ locations for the player to explore, and there must be a path from any of them to any of the others$$in other words, they must all be accessible. They cannot all be in a straight line with only one path through.

Whether one of the states provides a way to finish directly $($exit from the dungeon, whatever$),$ or the only way out is $$back the way you came,$$ is a design decision for you to make.

There must be at least $4$inventory$$ items that the character can take or drop. They can$$t all be in the same area at the start of the game. The player starts with no items in inventory.

It must be possible to complete the goal$$exit the dungeon with the gold, board the ship for the Grey Havens, exit Home Depot with the hard$-$to$-$find part, sneak the cookie jar past Grandma, etc.

Your game should provide user commands for the following:

Movement: Whether these are compass directions $($north$,$ south, east, west$)$ or relative directions $($ahead$,$ left, right, upstairs, downstairs, etc$)$ is up to you.

Inventory: Commands to pick up an item from an area, or drop an item from inventory into an area. Note that these will affect the player state and game state. Some items may not be available until the player searches the area. This requires tracking, for each item, whether it is visible. Once an item has been uncovered via search, it remains visible the rest of the game.

Report player$$s current location

List all items in player inventory

Describe current area

Search current area

Help: This should describe the total game state: Where the player is$,$ what items are in inventory, and what actions are available.

Deliverables:

Source file$($s$)$ constituting a runnable game

A documentation file containing:

An overview of the game:

Setting

Locations

Inventory items with starting locations for each

Goal state

Sources used

Title, author, URL for articles, posts, internet resources, etc

Brief description of generative AI use, if any

Comment: Any other useful or interesting information, thoughts on the project or the course, etc.

Programming issues

Here are some tasks your program will need to carry out.

$1.$ Game Setup:

Define a set of scenarios, each consisting of a narrative description and a set of choices that the player can make.

Represent the game state using functional data structures, such as immutable maps or records, to store information like the current scenario, player inventory, and any other relevant data.

$2.$ Game Loop:

Implement a game loop that repeatedly prompts the player for input and updates the game state accordingly.

Display the current scenario narrative and the available choices to the player.

Read player input and determine the next course of action based on their choice.

$3.$ Choice Handling:

Define functions to handle each choice made by the player.

Each choice may lead to a different scenario or have consequences that affect the game state.

Use pattern matching or conditionals to determine the outcome of each choice and update the game state accordingly.

$4.$ Game State Management:

Use functional programming techniques to manage the game state immutably.

Instead of mutating the game state directly, create new versions of the game state with the necessary changes applied.

This approach ensures that the game remains pure and facilitates easier testing and debugging.

$5.$ Ending Conditions:

Define conditions under which the game can end, such as reaching a specific scenario or achieving certain objectives.

Handle game endings gracefully by displaying appropriate messages to the player and possibly offering the option to restart or quit the game.

$6.$ Optional Features:

You may want to implement additional features to enhance the gameplay experience, such as:

Random events: Introduce randomness into the game with events that can occur unpredictably and affect the game state.

Multiple endings: Design the game with multiple possible outcomes based on the player's choices