Introduction

This documentation outlines the integration of rpg-specific npc functionalities into the current Chiventure framework. Additionally, we will outline overlaps and intrinsic dependencies between our team and other related teams specifically the rpg-battle team, the other npc-specific team, and potentially other teams depending on what rpg-features we hope to integrate.

Familiarization with Chiventure modules and opportunities for rpg-npc implementation

NPC battle feature

Aspects such as npc battle features would work closely with the wdl module to integrate the possibility of a battle object. Moreover, the actions module would need to be built upon to include battle actions. We may also integrate the possibility of saving and loading the current game state within a fight which would require work with the game_state module.

game.h

Game struct includes iteratable hash tables for players, rooms, and items.

item.h

Item struct includes hash handle, string id, string short description, string long description, hash table of actions, and hash table of attributes, attribute struct includes hash handle, string id, tag, and value (union of types to be loaded from WDL/used by action management).

player.h

Player struct includes hash handle, string id, int level, int health, int xp, hash table of items inventory.

Team Dependencies

NPC Team

One aspect we are naturally relying upon is the struct that the NPC team would create is a npc module wherein there is an npc struct containing the general characteristics of each npc.

See issue 429 (team-rpg).

WDL/WDL++

Currently, an NPC would be referred to as a 'component' in WDL. Though we will probably use the current documentation for an 'item' as a starting point, this must obviously evolve to reflect the more complicated nature of an NPC. Perhaps it is worth discussing this with the WDL++ team from the beginning so that this can be built into the new version of the language. This would most importantly involve collaboration on specifying the NPC dialogue.

Test games

If a new framework is indeed completed that allows the developers to create 'test games', we must ensure that support for testing the NPC interactions is also built-in.

Graphics and Sound

There will be minor dependencies with the new graphics and sound, and we must consider how we should be refactoring our code to support graphic and sound interface in the future. This can include leaving empty spaces in the relevant data struct (keep this in mind during design stage).