I forgot to mention, once you have completed the quest, you can extract the
quest item, that way they do not have a tonne of extra lame items around.
If someone wants to complete the quest more than one time, I think that is
fine.
We have quests for skills, and if you complete it more than once, it would not
matter since you have the skill anyhow. If it is for a piece of equipment,
I am
still fine, I like the idea of class specific quests and people having to
help each
other. Also to keep things neat, you could have a quest pouch, that store the
items (this would be overkill for me). It is not always the prettiest, but
usually
chars are only working on one or two quests at a time. Since there is a piece
of eq, or skill at the end, I can extract the object when completed, and chars
do not mind.
I am not sure if other muds have ownership of quest items, or items. We
coded that a long time ago to help prevent players from cheating, and stealing
each other's eq.
At 10:37 PM 6/10/2004, you 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
