One thing that I always end up needing in a game is a quest system, even when you initially don’t expect to have one, you’ll quickly find yourself wanting one, or painstakingly trying to convert an achievement system into a quest system, only for it to end up in a massive mess on the day of release.
In such cases, I rely on previous systems that I build, when I have the time. These do the job for the most part, but usually end up falling short after prolonged use. Over the Christmas break of 2025, I decided to re-create a quest system I had made previously, but to fix all the issues that I had with it, and introduce as many bells and whistles as I can, while also keeping the entire system extremely flexible, open and extensible.
This new Quest Service can be found here: https://gist.github.com/RoyallyFlushed/44ece62454a8646b41b6e6d30c65e390
What makes this quest system special, is that fact that I really wanted the quest system to remain Event-Driven, Data-Oriented, but with the events themselves to be as open and modifiable as possible. One headache I always ran into was when I would need to implement a specific quest, but would end up having to create a new event or edge case just to handle that. This system decouples entirely the notion of event handler.
Everything that makes up what an event handler is and how a “task” should be processed and interacted with, is each handled in it’s own module. This approach worked so well, that all the quest events in two games that now utilise this system only rely on a singular Core handler which contains a lot of common task processing logic.
See code here: