Open World ~ Feature Wishlist

RPG-Openworld's Feature Wishlist

Team (2021): Justin Shin, Mingyan Wang, Sumaiya Ahmed

---

The RPG-Openworld team this quarter achieved a lot. Unfortunately, Openworld is still currently a very isolated module. We hope that future openworld developers will prioritize 1) doing joint projects with other RPG teams to incorporate diverse functionality into our module–– there are countless ways (e.g. effects, NPCs, battles) in which we can expand–– as well as 2) implementing static/dynamic integration (which would need WDL support for openworld structs/types).

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

---

This quarter the RPG-Openworld team was able to accomplish a lot and got a great start to the feature as a whole. This wiki page will go over what was done and what we have in mind for future openworld developers to work on if they would like. This wishlist consists of both things we think are a necessity to the openworld feature and things that may not be completely necessary.

Team (2022): Jesse Ssengonzi, Rohan Deme, Helena Chen, William Hu, Lukas Grunzke

What Is Wished For:

Static Generation:

• Def. An approach for integrating the module into chiventure which loads everything on game startup, before game execution, and thus remains 'static' throughout gameplay
• See issue
• Adding WDL support for openworld types/structs (e.g. gencontext_t, roomspecs) so that they can be directly parsed into the game during game startup

Dynamic Generation:

• Def. An approach for integrating the module into chiventure which generates/modifies the map 'dynamically' throughout gameplay, e.g.:
  • Loading new rooms when the player/NPC reaches the edge of generated space
  • Modifying existing rooms (like a shifting labyrinth)
  • Periodically spawning more NPCs/enemies
  • Locking off escape paths when you walk into a trap
• Subtasks:
  • gencontext needs to be saved “in-memory” so it can be periodically accessed during game execution; the only way to do this is to add it as a field to game_t (other specialized gen structs like levelspec may need to be wrapped inside gencontext)

Environmental Effects:

• Def. Effects that are associated with the room.
• e.g. temperature, humidity, magical concentration, etc. Certain themes (see below) could be organized based on common effects.

Documentation For README.me

• Current README has only one line of text
• We should update it so that it gives a brief description of each module and its functions/data structures

Team 2021

What Was Finished:

Level-Oriented Room Generation:

• Only generates rooms which correspond the player's level (see issue #882)

Autogeneration Of Rooms Within A Radius – aka Recursive Generation:

• Given an integer radius 'n' and an array of direction strings, recursive_generate() generates n layers of rooms around the given room in a recursive fashion (see issue #925)

Item-Room Association Structs:

• Item generation which allows game authors to customize an item's probability of appearing in a certain room(spec) with a random quantity (see issue #1035)

Refactoring:

• Refactor level-oriented generation code by creating a speclist-filtering helper (see issue #982)
• Convert room_generate() into a general purpose, single-room loading + connecting function (see issue #1033)
• Reorganize level-oriented generation structs into a new levelspec_t struct (see issue #1034)

What We Wished For:

"Map Structures/Buildings" Structs:

• Def. Collections of rooms that spawn together, but in random variations (that could be customized)–– variations as in different numbers and configurations of rooms, e.g.:
  • A ‘dungeon’ map structure could consist of an entrance, prison cells, staircase, etc.
  • A nether fortress can be thought of as a “map structure” in minecraft. It has component ‘rooms’ like a netherwart farm, long open battlements, blaze spawner sections, rooms with loot etc.
• Map structures could have a minimum distance or distance-dependent occurrence probability so they don't tend to spawn clumped together or too often:
  • Distance could be measured in number of paths
  • After you go past the minimum distance, you have an increasing probability of generating another room (although this probability could be capped at some maximum)

Quest-Specific Item Generation:

• Def. Random specific items in the map that would generate once and be helpful for quests, weapons etc; for this, you would collaborate with the RPG teams to think about how to work item generation in with the features they’re developing
• Credit to Dr. Sotomayor

Static Generation:

• Def. An approach for integrating the module into chiventure which loads everything on game startup, before game execution, and thus remains 'static' throughout gameplay
• See issue
• Adding WDL support for openworld types/structs (e.g. gencontext_t, roomspecs) so that they can be directly parsed into the game during game startup

Dynamic Generation:

• Def. An approach for integrating the module into chiventure which generates/modifies the map 'dynamically' throughout gameplay, e.g.:
  • Loading new rooms when the player/NPC reaches the edge of generated space
  • Modifying existing rooms (like a shifting labyrinth)
  • Periodically spawning more NPCs/enemies
  • Locking off escape paths when you walk into a trap
• Subtasks:
  • gencontext needs to be saved “in-memory” so it can be periodically accessed during game execution; the only way to do this is to add it as a field to game_t (other specialized gen structs like levelspec may need to be wrapped inside gencontext)

"Cheats":

• Def. CLI commands for generating items, rooms, npcs, effects, paths etc.
  • e.g. in minecraft, there are commands like give <target> <item> [<count>]
  • There could be an int field in the game that toggles cheats

Environmental Effects:

• Def. Effects that are associated with the room.
• e.g. temperature, humidity, magical concentration, etc. Certain themes (see below) could be organized based on common effects.

Theme Structs:

• Def. A number of specific map structures/roomspecs/items that are grouped together for any reason that the game author decides, e.g. dungeon, castle, hospital, arctic, modern, magical, woodland etc.
• Theme-wide properties and associated helpers: These helpers apply properties to each room in the theme, automating much of the tedious manual specification for shared properties, e.g. Item/NPC and room associations, environmental effects

NPC:

• Def. Implement NPC generation in openworld (see issue)

Square-Grid Recursive Generation:

• Def. In a square-grid map, each room (except for those on the map edges) is connected to four other rooms at the compass directions (NESW)
  • Square grid maps are generally better than the tree-branching maps (the latter is currently generated by recursive_generate) since they allow greater mobility. If you go down a branch in a tree, you can't cross over without going back to the start/parent node.
  • In some weird edge cases, we suppose that this inability to cross to a different branch could be desirable. Each branch could simulate very distant locations that cannot connect to each other
    • We could create a tree where each branch continues only in one direction (rather than continuously making multiple branches at each node)
• For a radius of 1, it creates a 3x3 grid of rooms with the given pivot at the center. Any already loaded rooms are not replaced with new rooms. For a radius of 2, it creates a 5x5 grid.

Checkpoints:

• Def. Fixed points/rooms that are guaranteed to generate (like in Hades, boss fight rooms); the rooms/paths that link these checkpoints could be random
  • Checkpoints could also be abstract locations on the map that confer certain effects/properties as you get closer e.g. increasingly difficult rooms/mobs could spawn as you approach a certain zone that is denoted as an 'evil stronghold'

Map visualization*

• Def. Some way to visualize the structure of the already explored map (like a map button/key/CLI command that can be toggle from the chiventure GUI); it would be basically a graph depicting the connections between already explored rooms.
• If we stick with the default six directions "UP" "DOWN" (Z directions) and NESW (X and Y directions) then the graphs could be depicted in a layerwise fashion. Each page of the map would depict all rooms on the same Z layer. UP = Z+, DOWN Z-.
• The game Dwarf Fortress functions in this manner (encourage you to check it out); player can look at only Z layer on the map at a time but can change his Z layer by using.

Documentation For recursive_generate:

• Title.

Direction structs

• Def. A new direction_t struct that maps each direction to its reverse and enables the specification of custom directions like "above" and "below"
• May need to ask on devcore if we could/should make it a core feature
• As of now, in openworld, directions are all hardcoded in each generation function like multi_room_generate() and recursive_generate()
  • Make a
    • char* direction;
    • int reverse_dir_index;
  • then we’ll have an array of these structs to demarcate the possible set of directions, e.g.

“NORTH”	“EAST”	“SOUTH”	“WEST”	“UP”	“DOWN”
2	3	0	1	5	4

• This would mean a helper to add new directions in forward-reverse pairs to the array
  • add_forward_reverse_dir_pair(struct *arr, char *dir, char *reverse_dir)
• Alternatively, we can have directions_t struct organized like:
  • char** directions;
  • int* reverse_dir_indices;
  • int num_dirs;

Team 2020

What Was Finished:

Generating a Room Into Chiventure:

We were able to come up with a way to generate a room into chiventure. You can generate multiple rooms as well. The generation design is pretty basic at the moment but it works which is most important. You can read more about exactly how we accomplished this on our source document.

Building a default list of roomspec_t's:

We needed a file to grab rooms from. We decided upon hardcoding these from a file that would automatically make the rooms for us. This allowed the generation algorithm to just grab the roomspec_t's to make rooms from.

The Intial Structs:

The foundation of openworld was made. There may be a need in the future to change what these are doing (especially gencontext_t) but as of right now these structs hold tight what is necessary.

What We Wished For:

Level Oriented Generation:

UPDATE: Team 2021 has begun work on this feature. Relevant issues: #882, #982. The source document wiki page has also been updated.

As stated above, the current generation algorithm is, needless to say, somewhat simple. It generates based on only how many rooms you want and by randomly picking a room. In the future, if the generation algorithm could pull from the player's level and pick roomspec_t's based on that, it would flow much smoother and generate much nicer for more complex chiventure games.

Better Roomspec Groupings and Automation:

Roomspec_t's at the moment are organized by a few hardcoded groupings such as a hallway, closet and school. These groupings can be expanded on to include dungeons and other typical game rooms. Furthermore, many of these rooms are hardcoded. It would be preferable if the rooms could be filled with items and npcs that are based on the player's level. This would greatly aid the generation as well.

Lazy or Eager Generation:

As of right now, chiventure can only use the openworld module if it is "monkey-patched" in, meaning it has no true way of connecting to chiventure at the moment. This was decided since a lazy or eager implementation could potentially backfire at this stage of the project and the design would require more implementation and connection to other chiventure features such as: cli, actionmanagement and npc.

There are a few approaches that come to mind:

1. Autogenerating when a player enters a room. (lazy)
2. Triggering autogeneration on chiventure startup (eager)
3. A WDL trigger to autogeneration (parsing)

These two implementations would greatly increase the possibility and ease of use of openworld in chiventure.

WDL and Speclist_t's:

Right now, there is only a single, hardcoded speclist in default_rooms. It would be nice if there was a way for game authors to make there own speclist_t's. That would help diversify options for what rooms the author would like to generate and would help more complex games flow more smoothly.

---

All in all, openworld is a complex feature that has a lot of implementation ahead in its future and its limits are somewhat endless. Its autogeneration can be as completed as machine learning or as simple as it is now. There are many ways it can be build upon (and we really hope you do build on it C: ) because we believe its a great feature! -RPG-Openworld Bryan Lee, Nicole Avila, Carolina Calderon, Eddy Rose