Open World ~ Designing approach for static integration into chiventure

Introduction

Last sprint (see wiki for more details), we decided to work on a static approach (as part of a multi-method approach) to integrate openworld into chiventure. The rationale for this is quite simple: it has the fewest working components and thus would be the fastest to implement.

Summary of needed changes

Autogeneration is simply the alteration of which room specifications are added to the game struct to create a unique map/environment. Chiventure already has a parser that allows it to load a game struct from a WDL file. Our static integration of openworld would merely provide an alternative way of loading the game.

The openworld module relies on a struct called gencontext_t to organize the information needed for generation. Currently, openworld relies on hardcoded defaults in default_rooms.c and default_items.c to create gencontexts. To allow openworld auto generation to occur during game setup, we need to be able to automatically generate a gencontext from the WDL file–– i.e. add more parser functionality.

Expanding parsing functionality

We compared the fields of gencontext and the objects that can be specified in WDL to see which data types need support.

typedef struct gencontext { path_t *open_paths; int num_open_paths; int level; speclist_t *speclist; } gencontext_t;

path_t *open_paths and int num_open_paths: …are actually not yet used by openworld functions, but we hope to use them to generalize path generation. We envision using open_paths as a set of all possible path values; future algorithms would then extract from this set to add paths to rooms.

Since open_paths is a set, we need a new parsing method that ignores repeated path instances in the WDL file. Alternatively we can create a new WDL format that allows us to specify this set of unique paths in file, which would more directly translate into open_paths.

int level: (player level) …can be accessed as a field in the player_t struct for which parsing is supported. We use it to generate maps of variable difficulty that correspond to player stats–– see level_oriented_generation issue for more info.

speclist_t *speclist …speclist_t, which is a list of roomspec_t structs, is essentially a verbatim copy of room specification in WDL. Parsing would be very similar to the existing method used for adding rooms.

Generation method specification

Besides initializing gencontext fields, we hope to be able to specify generation method in the WDL file in anticipation of new generation methods that we might add (e.g. dynamic generation, which allows the map to evolve throughout gameplay).

Conclusion

So far, we’ve provided a very general overview of our integration approach. Ideally, we would have looked more closely at the specifics of parsing to include more details (e.g. outline basic modules/functions).

However, we have been informed that game-loading is about to be revamped. Since the parsing implementation will likely change, we should postpone these considerations to a later sprint.