Player Class ~ Loading Classes from WDL

Loading Classes from WDL

Subject to PR #1086, Classes can be stored and loaded from WDL files. At the time of writing, the only WDL file with classes in chiventure is tests/wdl/examples/wdl/classes.wdl

The code that converts a WDL file to a game with classes lives in the WDL module.

Only some class_t fields are currently supported

Supported class_t fields are:

• "prefab": Marks whether a prefab class should be loaded in.
• "short_desc"
• "long_desc"
• "attributes"
• "base_stats"

Note that the spelling (underscores) differs slightly between the WDL files and the class_t struct. I favored more consistency when designing the WDL file.

The following attributes are permitted, but they are ignored when the class is being loaded:

• "effects": The relationship between classes and effects is in an odd place. In their current implementation, effects have a limited duration, while a class probably only wants infinite duration effects. Until this is sorted out, effects will not be defined in WDL.
• "skill_tree" and "starting_skills": I feel that the skill trees team is more suited for designing the WDL form of these structs. As such, they are currently ignored for now.

Note that all other fields, including misspellings (case sensitive), are considered illegal and trigger an error message during loading. Additionally, it is ok for fields to be missing or null in the WDL format. If that is the case, they will be filled in with "" or NULL.

Example WDL file

This comes from tests/wdl/examples/wdl/classes.wdl. Unrelated sections of the file are omitted with { ... }:

{
    "GAME": { ... },
    "CLASSES": {
        "Knight": {
            "short_desc": "Knight's short description",
            "long_desc": "Knight's long description",
            "attributes": {
                "noble": true,
                "hot-headed": true
            },
            "base_stats": {
                "health": {
                    "current": 100,
                    "max": 200
                },
                "mana": {
                    "current": 20,
                    "max": 100
                }
            },
            "effects": null,
            "skill_tree": null,
            "starting_skills": null
        },
        "Lich": {
            "short_desc": "Lich's short description",
            "long_desc": "Lich's long description",
            "attributes": {
                "evil": true,
                "brittle": true
            },
            "base_stats": {
                "health": {
                    "current": 40,
                    "max": 200
                },
                "mana": {
                    "current": 80,
                    "max": 100
                },
                "spookiness": {
                    "current": 8,
                    "max": 10
                }
            },
            "effects": null,
            "skill_tree": null,
            "starting_skills": null
        },
        "Rogue": {
            "long_desc": "Rogue's long description"
        },
        "Monk": {
            "prefab": true
        },
        "Warrior": {
            "prefab": true,
            "long_desc": "Warrior's overwritten long description",
            "base_stats": {
                "health": {
                    "max": 200,
                    "current": 120
                },
                "mana": {
                    "max": 100,
                    "current": 5
                }
            }
        }
    },
    "ROOMS": { ... },
    "ITEMS": { ... }
}

This shows off a variety of types of classes that can currently be parsed:

• Fully defined classes, like Knight.
• Partially defined classes, like Rogue, which have missing fields filled in.
• Prefab classes, like Monk, which call code in class_prefabs.c to generate fields. These classes can have fields that are not yet supported by the WDL format, like skill trees.
• Overwritten Prefab classes, like Warrior, which are prefab classes that have some of their fields overwritten by the game author.