Note: This Wiki is outdated, as we actually redesigned missions twice this quarter! The first time (documented here) was to fix the substantial flaws with the previous system to get it to actually function while the second redesign was to improve the modularity of the system to make adding new mission types and parsing mission types much easier.

Why Redesign Missions?

The current design for missions in the quest module is flawed. The missions struct is a union of 2 different structs, representing active and passive missions respectively, and thus holds one of the two values. However, as the two elements of a union have the same pointer, there is no way to tell which option is currently active, resulting in potentially incorrect output. For this reason, we needed to come up with an effective new design for missions within the rest of the quest module's framework.

For reference, here is the current completely-broken implementation:

typedef struct active_mission {
    item_t *item_to_collect;
    npc_t *npc_to_meet;
    npc_t *npc_to_kill;
    room_t *room_to_visit;
} active_mission_t;

typedef struct passive_mission{
    int xp;
    int levels;
    int health;
} passive_mission_t;

typedef union mission {
    active_mission_t *a_mission;
    passive_mission_t *p_mission;
} mission_t;

Changes

Explanation

The changes we plan to make are as follows: Firstly, we plan to remove the idea of passive missions. Since these involve ideas of xp, health, and levels, they are redundant when placed aside the prerequisite system that we have already developed. Without passive missions as an element of missions, the mission union is no longer necessary, and thus can be replaced entirely by the active mission struct, which will accordingly be named the mission struct. Secondly, we plan to more rigorously enforce certain restrictions on initializing missions. Although the active mission struct (soon to be repurposed as simply the mission struct) has 4 elements, the mission itself is not meant to involve all of these, due to the difficulty of the long-term storage of information regarding completion. To ensure that this is not an issue, we plan to impose testing restrictions, with documentation, preventing multiple of the elements from having non-NULL values. If a task needs to have multiple such elements, it should rather be split into multiple tasks which are all prerequisites for the next step.

These changes should increase the effectiveness of the quests module and its ability to be integrated properly into the rest of Chiventure.

Explicit Changes:

The passive mission struct should be deleted and the active mission struct should now become the new mission struct. Thus, the mission struct should now look as follows:

typedef struct mission {
    item_t *item_to_collect;
    npc_t *npc_to_meet;
    npc_t *npc_to_kill;
    room_t *room_to_visit;
} mission_t;

Function changes are extremely simple for this redesign, as all functions that begin with passive_mission need to be removed, and all functions that begin with active_mission need to be renamed to only begin with mission. After this is implemented, mission_init() needs to be reworked to include a check that only a single field in the mission struct is set and task_init similarly needs to add a check to make sure that a task with a mission doesn't have any other requirements. Other than that, the is_task_complete() function needs to be updated to actually check if tasks are complete now that that is possible. Similarly, the complete_task() function needs to complete the task no matter what (without checking if conditions are met) so it can be called by other modules (NPC, Battles, etc.) as a means of interacting with our quest system.

Lastly, new tests need to be added to test mission functionality and the test need to be comprehensive enough to make sure missions actually work (unlike before, where each mission test happened to set the mission pointer to NULL due to a misunderstanding about how unions work which caused every mission to pass). This includes explicitly testing each altered function for all possible outcomes and also whether mission_init() and task_init() fail when there are multiple missions inputted or multiple task requirements in addition to a mission.