RPG-openworld Integrate Design Doc and Existing Features

(draft 3)

Team: Nicole Avila, Carolina Calderon, Chanik Bryan Lee, Eddy Rose

---

This document outlines specific structs and implementations that already exist in chiventure, and how the rpg-openworld team may incorporate them in our room/world autogeneration module and item gather module. It also suggests things that may be added (e.g. item classes) to maintain continuity while randomly generating rooms.

Under our highest-layer module, autogeneration, we want a lower-level module that implements an autogeneration algorithm to create a new room based on a few parameters specifying things like level of difficulty, items in room, level of loot available, etc.

This algorithm will have to pull from the following three modules (mainly), and put them together in a quasi-random configuration that still makes sense, is random enough to be interesting to the user, and adheres to the few given parameters:

---

General goals

These are general goals for autogeneration that do not necessarily pertain to our immediate goals. It’s just good to have them down so we can reference them in the future. Scroll down to Immediate goals for our current goal of room autogeneration. (path: chiventure/include/game-state/)

• game_action.h Store actions done in autogenerated rooms so they don’t need to unnecessarily be repeated Infer history of actions so the room state and player inventory state are update accordingly
• player.h

1. Incorporate hashed structure to our design
2. Update player inventory based on actions
3. Update history of actions player_t->xp changes based on amount explored in random rooms (?)

• item.h

1. Incorporate hashed structure to our design
2. Update item location (player inventory or room) depending on performed action

• room.h

1. Incorporate hashed structure to our design
2. Incorporate direction of the room relative to the current room (e.g. right door always leads to a unique, randomly generated room which is different from the room behind left door)
3. Update room items according to performed actions by the user

As of now, we want to design and implement a way to solely autogenerate rooms. If we get this right, we can extend some of this logic to autogenerate open world elements and alter player data (inventory, xp, etc.). The rest of this doc suggests ways we may incorporate what we know about the game-state modules into our autogeneration design.

---

Immediate goals

Want to design random room autogeneration with:

• item.h
• room.h

---

What item.h interface offers:

• item.h has an item_t struct that is hashable and can be uniquely identified:

1. Hash_handle (makes struct hashable)
2. char* item_id - we need to identify items uniquely with a string
3. short_desc and long_desc
4. actions associated with this item
5. Hash table for all the item’s attributes

How we may use item.h interface:

• We need a way to interact with a hashtable or database of item_t structs and pull from it “randomly” in the gather module. Some things to consider:
  • How random do we want this to be? Would we prefer complete randomness of items? Not completely random but depends, in some part, to previously generated items (e.g. we don’t want, say a bunch of “flower” items to generate in a libarary - we’d want things like books)?
  • Give some items more value than others, like loot, resources (food for health regen), etc. Perhaps add item characteristics like weight, value, size, etc? Limited player inventory for more of a challenge? room.h has a room struct (room_t) for specifying the room, path struct (path_t) to specify how all rooms are connected (all hashable)

---

What room.h interface offers:

• Path struct (path_t)
  • Fields: hash handle, case-sensitive direction (string), the destination room, item that needs to be interacted with (e.g. door) to access path
• Room struct (room_t)
  • Fields: hash handle, room_id (string), short_desc and long_desc, list of hashed items (in the room), and list of hashed paths from that room

How we may use room.h interface:

• We want newly-generated rooms to connect to pre-existing rooms in some way, via paths. The path_t struct provides a way to do this.
  • Have autogenerated rooms extend from pre-existing paths, and possibly add this addition to a larger database or hashtable (see below).
  • Do we want some sort of overarching hashtable or database that provides information on how every room is connected overall (e.g. graphs, which may help in providing some sort of map in the future)?
• Room struct has a field containing information on the items it holds. We can use this as a configuration to our autogeneration algorithm, perhaps to generate rooms that are near each other to hold similar items.
  • This way, it represents more of a connected environment/world (e.g. the user may prefer to have, say, two rooms connected via a path to be connected rooms representing different rooms in a dungeon).
    • It’d make more sense to have similar randomly-generated items in both rooms to give a sense of continuity.
      • Perhaps assign classes to items as well (e.g. weapons, loot, resources, etc.)
    • This may make more sense than having items like flowers and books in the same room.
• To what degree of randomness do we want in our autogeneration?
  • Of course, variation to this should be optional so that things like bosses or maybe “teleporting” to a different area of the map can be allowed.

Additional considerations after team meeting (5/2/2020):

• Want NPC inclusion with random room generation as well. Communication with the NPC team.
• Want map view availability to make it easier for the user to keep track of newly-generated rooms.
  • Connect with graphics team to discuss this.
• Want item values to have a range (perhaps in accordance to the player-stat level?)
• Look into a library that implements some sort of random functionality to generate a random item from a set of items.
• Want items to be classified such that they are grouped into items based on type (e.g. item, loot, weapon) and value
  • How will we classify them? A database? Hash table use? We considered creating item module by class, and using a the random library on each module independently. This way, we generate items "semi-randomly" (e.g. same class, but random items within each class).
• Have a room generate with items that have values corresponding to the player level? (More valuable items with higher-level players, etc.)
  • How can we make item classifications general enough to give game authors freedom for their game, but specific enough to be grouped based on type?