Written in response to Issue #486 to discuss the lack of a "player" in the current implementation of chiventure. This document will investigate the progress of implementing a player into the current chiventure, and will be used in thinking about if/how WDL++ should integrate these capabilities.

Why is having a player important?

For RPGs, player stats are essential. Health points, experience points, and even mana points can heavily impact the user's in-game abilities, and allows more complex game design (e.g., what happens when a player dies). Additionally, if we want to support player-specific information, such as "level", "class," or "race," having a defined place to store this information is crucial.

Currently, the RPG teams' goals include:

• Player class (monk, knight, healer, ninja, etc.) with different skills/stats
• Player race (human, orc, elf, etc.)
• Player stats, such as health, experience, speed, attack, mana, stamina, charisma, etc.
• Skill trees (unlock spells like teleportation, lock-picking, or magic light sources for some random underwater room that would put a normal torch out)
• Player statuses: these would be effects that modify a player's stats for a given amount of time or until a condition is fulfilled

(Taken from the Feature Wishlist)

All of these would require a basic integration of a player into WDL, not to mention potential future features, like multiplayer support.

Current support

game-state

In game state, there does exist a player module. A player is currently defined as:

/* A player in game */
typedef struct player {
    /* hh is used for hashtable, as provided in uthash.h*/
    UT_hash_handle hh;
    char *player_id;
    int level;
    int health;
    int xp;
    item_hash_t *inventory;
} player_t;

(from player.h)

The player module contains all the necessary functions to initialize and update the struct.

wdl/wdl++

In the example files thus far, operations involving a player have not been used. The parse module does have an extract_objects function that: "extracts the a list of objects associated with an attribute of the primary object; used to get a list of rooms, items, and players." However, there is no load module associated with the player struct.

Thoughts & Conclusion

For defining which attributes exist and/or updating the player struct, it makes more sense for other teams (e.g. action management) to take the lead. In terms of representing a player in WDL++, the WDL team has tentatively decided to categorize a player as a sort of "special object," such that it can be acted upon and have attributes updated. More discussion is needed to fully flesh out details, but it will introduced in WDL++.