Encode types for the room and item modules.

[carolinaecalderon]

This week, the openworld team wants to hard code three rooms with unique characteristics to feed into the room module. Along with these rooms, I will hardcode item types to populate the rooms. These will act like templates for their respective categories.

[carolinaecalderon]

In my most recent commit (ff02494), I laid out the structure for the room and item modules. Originally, I was only supposed to hard code rooms for this week, but upon further inspection of the structures that I'm adapting from game-action, I had to include/modify an items module as well. The important change here is that the room_t and item_t structs are now umbrellas for different kinds of rooms and items. That is, room_t and item_t have an enumerated type with the room/item id and the room_type/item_type itself is a union of all their different options: room_type = {library, dungeon, OR open_field}, item_type = {apple, book, cow, door OR window}. All these specific room are then hard-coded with a fixed description and set of items you can find inside. The item types are hard-coded with a fixed description only. The attribute parameter (in items) and path parameter (in rooms) was included but not set because it is beyond the scope of this task.

I still need to make sure this compiles, but I'm working on integrating and including the right files first.

Progress can be found here: https://github.com/uchicago-cs/chiventure/tree/openworld/sample-generation

[carolinaecalderon]

In my most recent commit (f2abff7), I was able to integrate the openworld room and item modules into the CMakeLists that is used to compile the whole game. To do this, I had to create a CMakeLists.txt file in the src/openworld directory as well as modify the general one in the chiventure directory. This means that all the header files that I reference in the sample_rooms.c and sample_items.c files are referenced correctly, and the bare-bones design structure can now move forward. Before, I could not consider writing tests for code that I couldn't run/view its output.

I also restructured the rooms and items type. For the rooms, I deleted the different definitions of types for each room and instead added a single enumerated type parameter to room_t structure for the "room_type". With this tag, in the room_init function, I'm passing the room_type tag through a switch statement and filling the id/short description/long description fields of the room struct with set strings. I did something analogous for the item struct.

I did not consider paths or attributes this week during the sprint.

Progress can be found here: https://github.com/uchicago-cs/chiventure/tree/openworld/sample-generation

[carolinaecalderon]

In the final commit for this sprint (b637704), I made the code "pretty" by adding the appropriate comments, splitting up lines that were too long etc. -s The room module and item module for the openworld feature is now implemented (or at least the framework is now set-up). I based my work this week from code I found in game-state, and added an enumerated "tag" parameter so that when rooms and items are initialized, their "tag" will match them to a set of identifiers like descriptors, and in the future attributes and paths. These modules were also integrated into the CMakeLists for the whole project, and they can be compiled without breaking game play. (Obviously, they're not called on by anything in game play yet, but they're still generally included).

[dwahme]

Issue Score: ✔️++

Comments: Great job! Well done having consistent incremental progress updates.