A Quest System framework Options

[Tsukihime]

There are probably many quest scripts out there and I've only looked at a few from XP and VX. Some of them are really fancy with like nice HUD's and everything, but I think when it comes to actual quest-making, it's a little different than what I had in mind. Let me know if any existing quest systems implement the kind of system I am looking for.

The goal of this system is to provide a framework for creating and managing quests, with a set of built-in functionality. It's something I'm going to be doing myself cause several parts of it sounds interesting.

I thought this was pretty cool though: http://www.rpgmakervx.net/index.php?showtopic=34037 . I don't have VX to test it out though.

But anyways.........

Quests can be complex. When you complete a quest, you may unlock another quest.
A quest may be composed of multiple parts. Maybe you can re-do quests. Maybe you can fail quests.

There are also many different types of quests, for example:
-deliver an item
-collect some items
-defeat monsters
-talk to someone
-go somewhere

I am looking for a quest system that will satisfy the following criteria:
-a quest scene that will dynamically generate a list of quests from a quest tree and allow you to accept/manage quests
-a central quest management system that will handle all quest-related logic such as checking for completion and updating quest progress
-a flexible quest system that allows users to extend it with their own rules and grammars

A centralized quest management system should handle quest availability, quest task completion, and updating quest progress, amongst other things.

Doesn't matter if you're asked to kill 20 slime or collect some eggs or to visit a particular NPC somewhere. You only need to write the management system once, and then you can just pass all your quests into it without worrying about how to handle each quest on a per-case basis.

The quest manager will provide an API that will allow you to give quests through script calls.

For this system, a quest scene will be created.
Quests will primarily be obtained from the quest scene.
It will present a list of quests available for you to choose from.
The list itself will be dynamically generated from a quest tree.

But again, the quest manager will allow users to choose how they wish to give their quests, and for sure not every game is going to be centered around a quest list.

Parser

The bulk of the system relies on a parsing algorithm that you will implement.
Because we are aiming to provide a system that allows (almost) arbitrary quests to be defined, we need to define rules and grammars.

The parser will read structured input and determine how to build all of the necessary things to allow the quest system to function.
Each type of quest is a separate component all by itself, so it is not necessary to implement every type of quest in order to have a working system.

*note: It is just my opinion that a parser will be required. If you have a better way to implement the system then by all means go for it. I only think a parser is necessary because of what is to follow.

This sounds like a computationally expensive system so optimizations would be quite important.

Quest entry

The quest tree will be parsed from a collection of quest entries. Implementation is up to you (array, hash table, ...)
Each entry will consist of the following fields. Implementation is up to you.

I think I would use an array of hash-tables when defining each quest because then you don't have to rely on hardcoded array indices, which may make it more flexible if someone decides to extend it by adding extra fields.

CODE

-a quest ID
-category
-difficulty
-description
-prerequisites
-effects
-automatic show?
-can redo?
-Fail behavior?
-list of tasks

Quest ID. It is really a user-friendly feature so you can easily refer to a specific quest rather than trying to remember what its index is. Oh, and you can sort your collection of quests internally as well for optimization?

Category. User-defined categories. Just to organize your quests and make your GUI look more interesting. For customization.

Difficulty. User-defined for customization. A constant should be defined to indicate sorting order.
-Easy/normal/hard
-1/2/3/4/5-star (maybe the GUI will actually draw stars)
-S/A/B/C/D-rank.

Description: self-explanatory. Anyone should be able to customize the parser if you wanted to add things like control characters to make descriptions more interesting? (colors, font, icons...). Actually I think it would provide interesting options if your parser is written flexibly.

Prerequisites. A list of quests that should be completed. And possibly other conditions! Maybe you need to have an item in your inventory in order for this quest to show up. Maybe you need to be at a certain level. Anyways the parser for this should be written flexibly so that if it sees numbers then it implies quest ID's, but if it sees structured text then it should parse it as such.

CODE

<actor 1> level 10
Has 1 Golden Egg

Effects. Don't know what to call this field. Basically things that should happen when you accept this quest. You know, perhaps you get a quest item, or you lose something.

CODE

Remove 2000 gold
Remove 1 Golden Egg
Add 1 key

Automatic show? Default True.
-If true, then it will automatically show up on the quest list when the prerequisites are met.
-If false, then you will have to manually activate it via script calls. Useful if you want to control when a quest appears and the story proceeds.

Can redo? Default False
-If False, then once you complete the quest (or fail), the quest will never show up again
-If it's a value from 1 to n, then you can repeat it that many times.
-if True, then it will always re-appear, provided the pre-requisites are met.

Fail behavior?
When you fail a quest, you may want to define different behaviors.
Maybe it's game over time.
Maybe you get a refund.
Maybe you lose exp.

List of tasks.
Just a list of tasks. Like many of the previous fields, you will need to define a set of keywords for your parser and require structured input.
This is especially important because your quest management system will be using these to check whether your quest is complete or not.

CODE

Collect 10 Berries
Kill 20 Slimes
Deliver Letter to SomeNPC

Rather than the string "Berries" you would instead enter the ID in the database so that when you parse the array of quests to build your tree you know exactly which object you're referring to. I think that is the most reasonable way to do it? So maybe something like

CODE

COLLECT 10 ITEM 3
Kill 20 enEmY 1

Case-insensitive to make it more user-friendly, but maybe the performance trade-off is not worth it.
Also, I don't know how to specify the letter-delivery, but it is a matter of adding an extra case to your parser.

Extending the system

As mentioned, the system is meant to be designed for extensibility.
The parser should be written so that it handles different cases and consequently additional cases may be added if someone comes up with an interesting type of quest (or knows how to implement the DELIVER quests or VISIT NPC quests lol).

I would not worry too much about the GUI; we can probably just grab an existing one and just hook it up to the appropriate methods and attributes.

Compatibility

Depending on the type of quest you're implementing, there may be compatibility issues.
For example, there shouldn't be any problems if you're just checking how many of an item you have, or whether you have a golden egg in your inventory, but if you started tracking enemy kills, you might run into problems.

Fortunately the system is meant to be flexible so if a type of quest just doesn't work out, just take it out or re-write it to make it compatible.

This post has been edited by Tsukihime: Apr 26 2012, 03:11 AM