On Tue, 30 Mar 2010 20:55:36 -0700
Mark Wedel mwe...@sonic.net wrote:
On 03/30/10 10:20 AM, Brendan Lally wrote:
quests:
1)
2)
3) Down to the docks:
a) Port Pass
b) Scorn Password
c) The Hero of Scorn
4 ...
etc
and then the info section would say:
snip
Yes, that makes a lot of sense - it sounds like the solution to
what I said above was to do sub quests, but I'd really not want to
see a huge list of quests which are really subquests and have no
value on their own (in my example above, fetching a baz only makes
sense as part of talking to foo).
There is really a trade off here, the choice is between having the
smallest possible number of really complex quests, or a greater
number of simpler quests.
My instinct is to go with the simpler individual quests, because
they are a lot easier to build and test in isolation.
That makes sense. And really, single big quests vs many small
quests is a server mechanic - if they are presented to the client in
a cohesive fashion (so those 12 subquests appear as steps of a big
quest), that is great - you don't need to have the big quest have
those 12 individual steps.
My main concern, beyond it being managable from a map designer
standpoint, is also have some way to make them cohesive for the
players.
It would seem to me in such a system, you'd need the following
information for these subquests:
- What part of quest are they (parent quest)
- what quests do these open when completed.
In terms of what the player sees, I think it will suffice to show them
a two level hierarchy. The subquests would probably be called
'objectives' or something similar in the client. The default behaviour
then would be to only show the active subquests, not the completed ones
Any occasion where there are more than two or three nested layers of
subquests for one quest probably indicates a need to rethink how the
quest is defined, or to split it up into a 'chain' of top-level quests.
One thing I do want is hidden quests and quest steps, simply because
for many quests, it will be easier to change the state of the quest
rather than use markers, and there is a value to suppressing some
status changes. (eg, there is one I am looking at where there are a
number of monsters around a leader, if one of the monsters is killed, I
want to close off a peaceful resolution with the leader, so easier to
set the queststate to $bignum rather than track a marker in the
dialogue).
I think the generic thing to do this is to have a 'parent' marker
in the child quest file, and allow each stage of any quest to
conditionally advance any other.
ie,
quest scorn/TerrysFarm
step 30
advancetarget scorn/DisputedFarm
advanceif 0-5
advanceto 10
so that setting the terry's farm quest to state 30 should advance the
disputed farm quest to step 10, but only if it is already between steps
0 and 5 (so if it is at step 7, or 20, nothing happens)
Obviously, it would be considered bad form to update another quest
without there being some story-line reason for doing so.
For example, one could have a quest that has 6 different steps, and
they have to be done in order (doing step 3 before step 2 doesn't
make sense). But you could have other quests where several of the
steps could be done in parallel - a simple example could be alchemy
quest - you may need to get 5 materials for the recipe, but what
order you get them in doesn't matter. I'm not sure how this later
one is handled in the system - the step to go to alchemy master with
cauldron shouldn't open up until all 5 of those subquests are done.
This could be done with a hidden quest and lots of combinations of
steps, but I think the more sensible solution would be to check the 5
subquests for completion in a dialogue. (so the dialogue script would
check all 5 quests are completed before causing the connection on the
map to be triggered.
One of the things I will be doing very shortly (ie, the next time I
change the quest file definition after the release) will be to break
the default.quests file into lots of smaller files. I was going to
use the region file to specify these, so that quests then become
attached to a region of the game world as well.
Makes sense - ideally, .quest files could sit anywhere in the map
tree, but that would make it trickier for the server to find them all.
But one could imagine that in some cases, a quest may relate to a
small set of maps (already located in its own directory in the maps
tree), and keeping the quest near there would make sense.
I wonder if rather than regions file, if maybe adding something
like #include directives into the the default.quests would work?
Server would then just process those and load all quest files. It
should only need to do this at startup, so shouldn't add much to load
time, but gives maximum flexibility.
The reason to want to tie them to regions, is to give an idea
