Member Discussions

Hey.
I am planning on making "manuel quests" where you can, as immortal, create quests with objectives, rewards etc. and be able to make mobs/obj work as quest givers.

I think I got all of the above covered. What I am not sure about is what would be the most efficient way of storing what quests a player (1)has taken upon himself, (2)has completed and needs to go back to the quest giver and (3)has completed and received his reward.

I thought about having a
ch->questison
ch->questalmostcomplete
ch->questhascompleted

I would then give each quest a 3 digit number (001,002,...,999) and add (not in a mathematical sense) that to the string ch->questison when someone wants to try that quest.
So a person on 3 quests, 001, 023 and 125 for instance would have his ch->questison = 001023125.

Now to the question:
Is this in anyway a good way to do it ? What I fear is a person who wants to take a quest and has, say, 300 quests completed. This would mean his questhascompleted is 3*300 characters long, his questalmostcomplete is also x number of characters long and his questison is also y number of characters long.
Each time the code has to check whether a given quest is available it would have to loop through rather long strings.
I don't know if this will have any effect at all but I am interested in hearing about alternative, and possibly better, solutions.
(The reason I want to declare it as strings is that adding more to the string is easy, whereas I am actually not sure how to "add" integers to the end of a number (10 and 11 wouldnt give 21 but 1011))

Comments are much appreciated, thanks.

Kristian

"Planning ahead" would be my biggest advise.

The problems I can see arising from this setup is as follows:

-Limitations to 1k quests. If and when you decide to use more numbers for quest reasons you may find that you want to have more than 1k reserved numbers. You can also use the alphabet, AAA, AA1, AA2, etc, to store more numbers. However, I've always been a fan of doing your own data structuring, in this case I would be separating quest 'IDs' by using a simple comma. When you're searching the string for completed quests, searching for ",798," is easier than "798", which return a positive position of "007982" when you might not mean for this to occur. Separators are always good for organizing. You never know what might happen.

Using separators also allows you to use, for example: ",1,2,56,809,5009,45," without having to use automated lengths, like 006 to sort through the data.


Now, I've gone and put in a lot of simple tag functionality in my code for use in many aspects of the running engine, but what I might use in terms of your idea would be somethinng similar: "<n>Orion's Call</n><id>309</id>completed"

You will find lots of opinions, but like you are talking about, storing data in strings (instead of I suppose query tables and other attached methods) I like to use my own setups, as long as it works. With tags, if something isn't supported, the code ignores it. If you add on tags, nothing crashes. It's a win-win situation if done right, and you can very easily imbed tags within tags, which adds a lot of functionality.

I'm not sure if this will help or not, but we like to use scripted quests using mprogs and whatnot that a builder or IMM can create. To that end we put in a quest field that's an 'int quest[255]' which gives a couple hundred quests to be used and active before another set needs to be added (quite a few years down the road perhaps) each quest is assigned one of the numbers and as you go through it (the newbie quest is 1 for example) the value of quest[1] changes. and then the other mobs can check and react to your level in quest[1]. There's no tricky manipulations really since each value in the quest field is separate and can be manipulated on it's own.

Recently I added a 'journal' that tracks the quests and updates a note about where you are in it to help people remember what they were doing. It uses the quest values and is assigned by the mprogs as well so with minimal extra work the builder can create the journal entries however they like to go with their quests.

I wouldn't use strings, because the string could become huge as more and more quests get added. Instead I would use something more like a database record. You can set it up so it's fairly simple. Each quest thats created is assigned a #, which would be its "record", then the fields would correspond to things like quest name, each monster involved, items needed, etc. Then in the player record, you add an area that deals with which quests are completed, or partially completed. Might also be useful to be able to assign "part of quest (y/n)" to an object created, which would update the player record.

Let me give an example. Quest 1 is given by a monster called QuestMaster. Player needs to find a rabbit foot, mushroom and a small knife. So, each of these items are set up as quests. (You can make it so player gains a small bit of xp for finding each, if you choose.) As each item is found, you can output something like, "Quest Part Fulfilled". You also update the player record so that in Quest 1 it shows: 1, 1, 1, 0" which means the 3 items are found, but have not yet been returned to QuestMaster. Once they are, the final 0 would be switched to a 1, some final reward of xp and/or gold is given. And an output of "Quest 1 Completed" is shown to the player. Just make sure people can't accidently drop, sell, steal quest items, cause then you'd have to deal with re-setting quests. lol.

Premature optimization is the root of all evil.

I would recommend something more like (assuming we're talking C here) making a struct to describe your per-player quest state, and storing a linked list or binary tree of these in the player. If that struct includes a pointer which can optionally lead out to an extended quest state that, for quests that want it, handles things like storing arbitrary information under arbitrary keys, you will save yourself a lot of headache later.

(What the premature optimization comment means is: don't start with the stage where you're trying to get all slick with the most compact conceivable data, handled in a way that only makes any sense whatsoever if you know the 27 assumptions it makes and do a bunch of math in your head just to figure out what you're looking at. Instead, start with the stage where you're building out a full, easily maintainable set of functionality, and once you've gone through some iterations of revising that to deal with new needs you encounter in deployment, and you've formed a really solid idea of what the mechanism is ever going to need to do, then get slick.)

Chaos
Lost Souls: medieval fantasy RPG
MUDseek: MUD gaming search engine

When you say "more like a database record" what do you mean exactly ?
I never took any classes in programming so what I know is more or less based on studying the ROM codebase + various stuff on the internet. That is why I am a bit hesistant using binary trees etc since I know, at least now, it is out of my league. (Don't know how hard it will be to learn though).

The idea of using a string kinda appealed to me since I know I can get it work that way :)
I did plan on using mprogs/oprogs/rprogs to make it work as someone suggested. Also, having "linked quests" would be as easy as making certain other quests only available if the person has completed some earlier quests, hence creating a quest line.

I'll make sure to have a look at linked lists and binary trees and see if I can get a grasp on it :)

Thank you all for the commments.

Dratgard wrote:
"When you're searching the string for completed quests, searching for ",798," is easier than "798", which return a positive position of "007982" when you might not mean for this to occur. "

I might just be influenced by my enviroment but, well I am studying molecular biology and when you create proteins you have a reading frame and each time you read 3 nucleotides (a codon). If you use strings as I intended and just make sure to not switch reading frames and make sure to compare 3 digits at a time, you will have "007982" be read as the "007 quest" and the "982 quest" and thus get the correct result. If you for some reason only get 2 digits removed/added though you will be in a ****load of trouble though :).
Using a comma will give you the same result I guess and is probably more readable for other users so that might be a better way to do it :)

Ok, consider the following as an example of a database record:

Database: Family

Record 1:

Name: Father
DOB: xx/xx/xxxx
Address: 1234 Checkerboard Square
: MyCity, MyState, MyZip
Phone #: xxx-xxx-xxxx


yada yada.

Basically you have a database called Quests. For each quest you have a record. Within each quest record there are the particulars of the quest (ie: start monster, second monster, third monster, last monster. start item, second item, third item, last item).

Now, in the player structure, you have a whole lot of player info. You can also include: Quests Begun, Quests Completed, Quests not Begun. In Quests Begun, you deal with the parts of the quest the player has finished. (Quest #, and then 1 for parts completed, 0 for parts not finished), etc. When the Quest is completed, you add that to the list in Quests Complete. (Which only needs the quest # probably). Quests not done would also be listed by just the quest #. When quests are done, all the information in Quests Begun dealing with that quest # can be erased, since the quest is finished.

Hope thats not too confusing. Oh, when a player begins a quest, you obviously remove it from Quests Not Done, and then put all the info for that quest into the player's Quests Begun. This way, unless a player starts all the quests, but never completes them, your player records should remain fairly compact.

In Neverwinter Nights, the Quest Journal was used to keep track of quests that a player was currently on. For example, if a player was on the first leg of the "kill the dragon" quest, and the 3rd leg of the "save the maiden" quest, then his journal "list" would contain the tags "kill_dragon_1" and "save_maiden_3". The actual Journal entries would be filled in from static text.

When a quest was completed, an invisible, immaterial object would be given to the player, and this was the item whose absence was looked for by the quest giver in order to offer the quest to that player.

How this scaled over time I don't know, but I believe the chapter transitions in the game removed these objects.

But I have a question for you:

What do you mean by "optimal"?

(Comment added by Kastagaar on Tue Sep 18 11:44:06 2007)

But in reply to your first question: no it's not good. If you're intent on making it unreadable, it may as well be binary.

What I think I'm missing is what you mean codewise when you talk about saving things in a list.
Do you simply mean saving data to a players pfile or have some dynamic table or ?

What I basically had in mind was something like this:

Immortal types; qedit create <number> and gets into an editor much like when creating helpfiles.
Here he writes the name of the quest, the reward, the description, level req, prequest requirements etc etc.

So we have quests saved in a quests.txt file.

Next I would add some mprog functions. So we can have a say trigger as "quest request" which would trigger something like: (written in pseudo C)
if (cangetquest(ch,<quest number>))
(addquest(ch,<quest number>))

Of course with some corrections so a player can hear what the quest is all about before accepting etc.

All this talk leads me to your question, what I mean by optimal.
Basically I mean, something I know I can code and understand well enough to manipulate as intended and something that doesn't take huge amounts of computer power.
I am always looking to learn new methods to make my code smarter but I Guess priority is to get it to work to start with :)

That is why just making a ch->questson, ch->questscompleted etc in the char_data struct seemed like an easy way to do things - maybe not the most easily readable way, but at least it is something I know how to code.

To make it less computer intensitive I thought about simply making a
ch->quests1-50, ch->quests51-100 etc. and have a
bool quests1-50, bool quests51-100. This way I could set these to true as soon as that quest number range is reached thus not having to make a for loop going through the max number of possible quests when a player only has the first 3.

Hope that answers your question :)