Nothing wrong with it.
I wish I could italicize wrong in that sentence.
It's just less efficient, memory wise, than using an unlimited bits system.
Specifically, it uses 1/8th the memory of a simple array of bytes. And if you
already have all the functions and macros for unlimited bits in your game,
most of the work is already done.
And it's less flexible than using an SQL database.
For example with an SQL database, you could let the builders give a name to
their quests, and store it in the db based on that name. This would allow
builders to make a virtually unlimited number of quests without worrying about
assigning quest numbers to builders, not having MAX_ZONE_QUEST set high
enough, etc.
----- Original Message -----
From: "Krayzie K" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, June 10, 2004 7:14 PM
Subject: RE: Quest and files
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
--
ROM mailing list
[email protected]
http://www.rom.org/cgi-bin/mailman/listinfo/rom
