The mob program method is clever and probably the best
route if you aren't eager to undertake a large coding
effort.
I chose to use dynamic lists saved in the pfile to
track a player's progress in current quests and quests
finished. This does add a fair amount of memory to
each PFile while the player is online.
Anytime they interact with a new object or kill a mob,
there's a quick scan of their active goal list to see
if they've progressed. When a goal is finished, the
quest number it came from is updated (simply increment
the number of goals completed and remove the goal from
their list, when they reach the total number of needed
goals for that quest, the quest if flagged
successful). If the scan is a concern, the goal list
could be divided into 3, one for mobs, items and
rooms.
Both the unfinished goals and overall quest status
lists are saved to the pfile so they can continue
where they left off anytime.
I prefer this to using a file since I frequently check
for quest progress as well as allow players to bring
up their completion lists and goal lists whenever they
want. Keeping this data in a file that I have to open
for each data request was too processor demanding.
I don't have any memory concerns, which made this alot
easier for me to accept. I think this is worth
considering since players only take up as much space
as the quests they have undertaken and then each final
quest pointer contains a minimal set of integer data
for their progress. It really depends on how much time
and code understanding you have.
I'm not exactly a brilliant programmer so I image
there's a more efficient method too :) However, I've
been satisfied with what I have.
Here's a quick picture of the data I store per goal
and per quest. A quest can have as many goals as the
designer wants (I added a QEdit to my OLC for that):
struct quest_status_type
{
QUEST_STATUS *next;
int qn; // unique quest num
int status; // done, accepted, etc
int count; // goals done
int awarded;// prizes given so far
};
struct quest_goal_type
{
QG_DATA * next;
QUEST_DATA *pQuest; //pointer to actual quest
int qn; // not necessary with pQuest
int amount; // goal progress
sh_int type; // (kill, retrieve...)
int vnum; // Goal/target vnum
sh_int rank; // importance of goal
};
Well that's probably more than you care for now. Just
bringing this up as a long winded alternative. Btw,
there's a toggle per quest to determine whether it's
completable one time or infinitely.
And as a side note, I did use mob progs to launch the
quests through whatever trigger type is desired. From
there, the code regulates the progress.
--- Jeremy Hill <[EMAIL PROTECTED]> wrote:
> You know, that's kind of a fun, neat way of doing
> it. I applaud your
> creativity. Saves a shitton of behind-the-scenes
> code, can use existing
> mobprog code to check stuff, etc.
>
> Only problem I could see is someone could drop the
> item to play the
> quest again or give it to someone else to give them
> a head start. Would
> take a little bit of code to ensure once a person
> has an item, they will
> have it forever. How do you do this without having
> inventories full of
> quest items?
>
> -- Jeremy
>
> Rick St Jean wrote:
>
> > I am a bit of a hack and a simpleton, but I just
> make a quest item for
> > each of those quests.
> > I assign v0 as the quest number, and use v1 to
> track the different
> > events on the quest.
> > This means that each quest needs an item, but that
> is really not a big
> > deal.
> > Then you do not have to make anything other than a
> quest object type.
> >
> > You would also need to code an mprog in there as
> well, but it really
> > does save
> > a lot of space .. and it will disappear when the
> player deletes.
> >
> >
> > At 06:43 PM 6/10/2004, you wrote:
> >
> >> I'd generally not go with the file idea. Just
> too slow.
> >> Well, it could work (dbms's do it all the time),
> just probably not if
> >> you're a novice with I/O.
> >> The SQL idea is workable and certainly very
> flexible, but obviously
> >> you need a dbms and will have to do a little
> research if you haven't
> >> worked with it before. And it would take more hd
> space and cpu time
> >> than the unlimited bits method.
> >>
> >>
> >>
> >> ----- Original Message ----- From:
> <[EMAIL PROTECTED]>
> >> To: <[email protected]>
> >> Sent: Wednesday, June 09, 2004 10:29 PM
> >> Subject: Quest and files
> >>
> >>
> >>> I am going to write my own custom quest code and
> I was wondering how
> >>> I could
> >>> easily keep track of the quests that players
> have done. I've decided
> >>> that it
> >>> would be the best way to have a master file that
> contains all the
> >>> quests done
> >>> by a player. In this file would be a listing of
> the player name and
> >>> the quest
> >>> number they've completed. When a quest is
> requested, the file will
> >>> be checked
> >>> and if they are not in the file they can do the
> quest, but if they
> >>> are then
> >>> they cannot.
> >>>
> >>> I am not exactly sure how efficent this will be,
> or if it'll cause
> >>> problems.
> >>> I don't want to have players become HUGE from
> the sheer amount of
> >>> quests that we
> >>> will be adding in, so I was thinking we can
> condense it into 1
> >>> master file.
> >>>
> >>> Another option I suppose would be to have a
> secondary quest file,
> >>> based on the
> >>> player's name and it won't clutter up the player
> file.
> >>>
> >>> Or something else that you guys could suggest.
> >>>
> >>> Thanks.
> >>>
> >>> PS: When I write code I try to write in a way
> that I will learn
> >>> something. As of
> >>> right now I suck at file I/O in C so this will
> be a great learning
> >>> experience.
> >>> It does have a reason why I am doing it besides
> what I've said in my
> >>> previous
> >>> paragraphs. Thanks again!
> >>>
> >>>
> >>>
> >>> --
> >>> ROM mailing list
> >>> [email protected]
> >>> http://www.rom.org/cgi-bin/mailman/listinfo/rom
> >>
> >>
> >>
> >> --
> >> ROM mailing list
> >> [email protected]
> >> http://www.rom.org/cgi-bin/mailman/listinfo/rom
> >
> >
> >
>
> --
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
