Development of Manasource and anything else related to the Mana Project.
#134209 by atheros
Thu May 09, 2013 8:07 pm
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.
Last edited by atheros on Sun May 12, 2013 5:54 am, edited 1 time in total.
#134210 by Ablu
Thu May 09, 2013 8:19 pm
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
#134211 by atheros
Thu May 09, 2013 8:38 pm
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.
#134212 by Ablu
Thu May 09, 2013 8:44 pm
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
#134214 by atheros
Thu May 09, 2013 8:53 pm
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.
#134215 by Ablu
Thu May 09, 2013 8:56 pm
Do you want to differ between subquests and "main" quests or simply send the questId as 0 (for example)?
#134217 by Ablu
Thu May 09, 2013 9:01 pm
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.
#134218 by o11c
Thu May 09, 2013 9:22 pm
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).
#134220 by Bjørn
Fri May 10, 2013 5:53 am
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").
#134223 by atheros
Fri May 10, 2013 6:40 am
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)
#134224 by Ablu
Fri May 10, 2013 6:44 am
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 :)
#134225 by Ablu
Fri May 10, 2013 6:48 am
atheros wrote: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.
#134227 by Bjørn
Fri May 10, 2013 7:36 am
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.

Who is online

Users browsing this forum: No registered users and 1 guest