The Questlog... but how?

[atheros]

Ok, so there is Ablu's commit (link) from a year ago.

But the main question is how do we want the questlog to work. Is it just a simple log a player should use as a general hint of stuff to do, or a more complex backlog with failed/successful quests, divided into smaller tasks, categorized (like Primary quests/Side quests/Whatever).

Any thoughts on that?

EDIT: link to the bug tracker.

[Ablu]

Ok read my commit again. Right. We probably want sub quests.

However i think we do not want to transfer all the old quests at login time.

So sending the DONE message is only for displaying a "Quest done" message on client side.
When i did this patch bjorn and I agreed about making it as simple as possible in its first version and see what we need later. But i agree that we could at least need a subquest system.

I am not sure about side, main quests... I planned to have a ability in the client to enable a specific quest and display waypoints on the map or minimap / npcs where to walk to. But i guess this is advanced stuff again...

Regards
Ablu

[atheros]

Main / Side quests or categories in general can be done either with a type parameter (byte) or totally client side, based on quest ID (so network/manaserv part isn't affected and this can be added later).

Old quests can be heavy on the network, so a GUI with tabs Open Quests / Completed Quests [ / Failed Quests] would reduce bandwidth, as would additional paging or quest reading at reduced speed, for example 1quest/sec (latest to oldest)

I think realtime quest signaling to the client is also needed with the following message:

• New quest - obvious
• Quest updated - whenever something changes (subtask, description, goal...)
• Quest completed - when the entire quest was finished succesfuly
• Quest failed - when the quest failed (does any MMORPG have that?)

Also I think the API should be more powerful than what you initially did, allowing to modify only parts of the state, not the entire quest.

[Ablu]

The way i did it things like making the client loading only parts of the quests is not really nice. Though i think we do not need to care about old quests at all. For subquests, why don't we simply send a parent id (or 0 if none)?

About failed: yes not sure if we really need this. We should try to keep the stuff simple.

Also: Feel free not to follow the stuff i did there. I only pushed it there so you could look at it if you want.

Regards
Ablu

[atheros]

I think a subquest structure should be something like: subquestId, questId, Text, State [open/done]

Failed can be simulated by "categories" if they are not clientside only, if not, I think it's safe to skip it.

[Ablu]

Do you want to differ between subquests and "main" quests or simply send the questId as 0 (for example)?

[atheros]

maybe quest with parentid is better, but we must limit the depth of that relation to one

[Ablu]

Why that? We could have a main quest, which has multiple major subquests, which in their turn have subquests again.

I do not see the need for this limitation.

[o11c]

For what it's worth, I would simplify things by saying:

• There is no such thing as a subquest. If you want something to act like a subquest, just give it a name with the prefix.
• There are only 2 states/logical messages: "quest activated" (with a variable length text field) and "quest deactivated" (with a variable length text field that may imply success or failure).
• There is no history within a quest (however, you could emulate this by putting longer text in the field).

[Bjørn]

Actually I also think we shouldn't have quest history. Apart from the additional work on UI, bandwidth and server-side storage issues, the main reason for me are dynamic quests. I want to allow scripts to dynamically create quests and this does not combine well with a history. I also think quest history is a rarely used feature which makes it not worth spending a lot of time on, and there are other ways of giving the sense of "achievement" this would be meant for (for example an "achievements" system or going up in rank in a faction).

For similar reasons I don't think we should have subquests. Again it's additional UI work, but also if you don't keep track of stuff you've completed then there is no list of subquests with their status. Each quest always has only one "next goal" that is relevant to the player. And as o11c said, if you really want to give the player the impression he's performing a sub-task, then this can be done with the quest title.

And btw I don't think it hurts allowing quests to fail. It may be a rarely used feature, but it's easy to support and could be useful. But, we can also add that later anyway.

As for messages, I think we need only one and can just use flags to indicate its contents:

Quest Update { Quest Id, Flags [ State, Title, Description, Goal ] }

And maybe from the client side the ability to abort a quest (could be based on a flag because not all quests will be "abortable").

[atheros]

I was constantly thinking how to implement dynamic quests... If we don't keep finished quests history, we could reuse quest ID for that. +1 bjorn

However I would keep a simple, text based history in form {string quest_title, int timeout}, so when I see in the log "Quest finished" and I have no idea what quest did I just finish, I can go to the quest history and see it. Such log could have a timeout of a few hours or so, so it wouldn't hurt anyone/anything and since it's a simple short text, it wouldn't be hard to implement the UI on client side (just a list component on a separate tab).

And the messages could look like this:
QuestUpdate {questId, operation, [title | description | goal | flags]}
QuestBacklog {questTitle, timeout}

operation one of:
- update title
- update description
- update goal - is it text description or map+position to show a marker on minimap?
- update flags
- finish success (removes the quest)
- finish failure (removes the quest)
- canceled (removes silently the quest)
- aborted (by player)

[Ablu]

Well we can just make the client displaying the finished quest while it is still connected. The quest will be gone on the next login then.

Also i think we want to display the "Quest completed" notification along with the name in the client

[Ablu]

operation one of:
[...]
- update flags

If i got bjorn right he meant to use flags in the network messages to set what parts of the quest updated.

[Bjørn]

Right, I also think we don't need a separate QuestBacklog message and as Ablu pointed out I meant the Flags to be used to indicate what information is included in the message (but of course some flags can have a meaning of their own, like the 'abortable' flag I suggested). This is similar to how position updates are done, which can optionally include the previous location and a change of speed.

A topic that hasn't been discussed yet is how we keep track of quests server-side. I see mainly two options:

• Let the scripts rely on the persistent character variables for storing the state of quests. This would mean the scripts are responsible for figuring out a character's quests when a character logs on and sending it the list.
• Introduce a new mana_quests table that explicitly stores the list of active quests for each character, with their id, state, title, description and goal (can be added later). This would mean adding this to the Storage class, adding communication between account and game server, having the game server keep this list in its CharacterComponent and adding script bindings to query and modify this list.

I think when we initially discussed this I suggested the first option. The second approach is quite a bit of work and may not be necessary at first, but it could solve the complexity of restoring the list of quests purely on the scripting side. On the other hand maybe we can find another solution for this.

[atheros]

I prefer the second option, the first one can get out of hand very fast.