top of page
  • Writer's pictureJesse Toyota

Quest System

In order to further develop player-to-NPC relationships, we decided that we would implement a quest system into Lil Tribals. It would behave similarly to our NPC Events, but require the player to fulfill a task with an attached reward/consequence.


The Current Way

Because we had deadlines to meet, I had originally developed a quest system that does the job, but was severely limited in its design. Quests were defined by their quest info and id (represented as an enum) and were handled using static lists and methods within the Quest class.


📷

📷


Quests were fetched using their id and checked against a generated quest info. If the quest was fetched and the info was relevant, it would update the quest's existing info to determine the state of the quest.


The picture below shows a dialogue state that gives an item to an NPC. If a fetch quest exists and the receiver and item is relevant to the quest, it updates the quest's info.


📷


While this technique works on a basic level, it has several issues:

1. It makes it difficult to manage if you have more than one of the same type of quest because it fetches quests using their enum id.

2. Checking quests are done manually and must be coded into any situation that might affect quests.


An Event-based Approach

After discussing the system with my technical mentor, he proposed a much more efficient way to handle quests; by using Unity Events. We agreed that as long as our current system works, it should be fine, but after some testing we discovered that the issues listed above created bugs and limitations.


The main difference is rather than placing manual quest checks for each situation, actions and outcomes would be registered through an Event Manager, allowing quests to subscribe to specific events related to these actions. Each event requires specific parameters that can be compared against quest requirements. If the parameter inputs are relevant to the quest, they will update their info similarly to the existing system.


Why this is a better approach: 1. Requires far less implementation efforts, relying heavily on the Event Manager 2. Allows for more flexible conditions and situations 3. More freedom for handling multiples of the same quest type.

bottom of page