adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Quests and Logs


From: ksterker
Subject: Re: [Adonthell-devel] Quests and Logs
Date: Tue, 13 Jul 2004 16:04:33 +0200

Some notes on implementation:

> A quest could then look as follows:
> 
> Quest xyz
>   Task 1
>      Task 1a
>        Step 1
>        Step 2
>        Step 3
>      Task 1b
>        Step 4
>        Step 5
>      Task 1c
>        ...
>   Task 2
>     ...

To make things clearer in the mail, I've used the terms Quest, Task and Step. 
However, all these will be represented by a single class (called quest_part).

This class has two states: started and completed. For individual steps, these 
two are equal. That means, a step is an atomic operation. Starting it will also 
complete it. However, for tasks it is different. A task is started if at least 
one of its child steps is completed. That means, event or dialogue scripts can 
query tasks for 3 distinct states:

 - is_started
 - is_completed
 - in_progress (= started && !completed)

That alone is an improvement over the 0.3's naive implentation, I think.

Each quest, task or step can have a log entry attached. Whenever a step is set 
to completed, its parent is checked whether it is completed too. That way, log 
entries attached to the whole quest or any task can be copied to the log book 
as soon as that quest is completed. Of course, quests, tasks or steps without 
log entry are also possible.


Distinct quests are kept in the 'quest' class, which provides a number of 
static methods to query the states described above. A certain quest_part is 
retrieved by an 'address' composed of the names of its parents. E.g. the string 
"Quest xyz.Task 1.Task 1a.Step 1" would retrieve the first step in the example 
above.


Unlike suggested earlier, I think that entries into the quest log should only 
be possible via completing quest steps. That way all log entries would be kept  
 in one place. The quest editor would allow to write them.


A note on how the completeness of a part/quest is determined: by default, it 
requires all it's children to be completed. However, one can manually specify a 
rule how to calculate completeness. That allows optional steps (that need to be 
recorded in the log, though) or multiple ways to complete a part.

I hope that makes my ideas a bit clearer to you. It certainly helped me to 
decide some of the details. 

(As you might have guessed, implementation of the quest stuff is already in 
progress. So if you have comments, please hurry :)!)

Cheers,

Kai





reply via email to

[Prev in Thread] Current Thread [Next in Thread]