I'm a newbie coder, but what's wrong with doing it like this?

This is how I run it on my MUD and I have had no problems, works like a
charm.

#define MAX_ZONE_QUEST 10 // Of course needs to be updated, I just assign a
// person a quest # when they want to write one

bool zqdone[MAX_ZONE_QUEST]; // TRUE/FALSE whether you have completed that
                                     // quest or not.

Upon character load, set all zqdone as FALSE, then read in something like
"ZqDone #" to flag which ones they have done as completed.

int  zqstep;

Very easy to just go ahead and save which step they are in as an int, no
need to make it more complicated than it should be.

int  zqcurrent;

What zone quest they are currently on, they can only be on one at a time,
and if a quest is not completed, and another is started, progress will not
be saved.

Although, if you do not attempt any other zone quest, it should save your
progress.

That is just the basics of what I use on my MUD, I'd rather not give out any
more information than that, you would need to code in the saving/loading and
all the mobprogram manipulation yourself, but really it's quite simple.

If zqcurrent $n [#zqnum]

If they are on quest x.

If zqdone $n [#zqnum] 

If they have completed that quest.

Mob Zqstart $n [#zqnum]

Set their current quest to the num, default
Sets them on first step of the quest

Mob zqstep and if zqstep $n [#zqnum]

Check which step they are on, or set them on a step.

Mob zqfinish $n [#zqnum]

Finishes their quest, sets that quest as done, as well
As sets their current and step to 0.

Stored which quests are done in pfiles as "ZqDone #", 
Then on load, just set ch->zqdone[#] = TRUE;

Of course you'll need to do some type of fread_number to get that from the
file and set a variable of some sort, or just do a flat out
ch->zqdone[fread_number(fp)] = TRUE;

^^ but I wouldn't do that

Without completely writing a snippet for it, which I'd rather not to, this
is the basics and the jist of what I use for zone quests on my MUD system.  
I did use Thri's mobprog driven quests to get an IDEA FOR THIS, I did not
rip his system off, and I custom coded every aspect of it myself.

If there is some like, major flaw I'm missing why this won't work, let me
know, but as far as I'm concerned, and as far as the people and builders on
my mud are concerned, this system has been working out truly great.

There's lots of other little random things, like making sure its set to 0 on
a load_char_obj and just the little things that I suppose anyone who has
been working with code for a while knows.

If you do choose to take this approach, I can help you and am willing to
give you a little more in-depth up close look of how I did things and maybe
even copy/paste it to ya if you e-mail me. ([EMAIL PROTECTED])



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick St Jean
Sent: Thursday, June 10, 2004 6:33 PM
To: [email protected]
Subject: Re: Quest and files

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


Reply via email to