[CF-Devel] quest exp rewards (RE: monsters, ...)

[crossfire-devel-admin at archives.real-time.com]

Various notes:

Specifying a skill to award exp is completely reasonable, and easy enough to do. 
  In the new skill system, you can have exp in a skill and still not be able to 
use it (this sort of has to be the case, because you have skills like praying - 
you may need a skill tool, or you may know it intrinsicly, but either way, the 
pray skill object has to hold the exp).

  It would be odd to have 5000 exp in a skill and still not be able to know it. 
  but it seems completely reasonable to me that if the exp reward is noteworthy 
that it would teach you the skill instead of the exp reward if you don't know 
it.  This may not be appropriate for low level (<10?) quests, but at some point, 
learning a skill is more about the luck of finding the appropriate skill scroll 
in the shops and not about resources (money).

The issue of players camping out keeps coming up, and I keep repeating the same 
thing - look at the RESET_LOCATION_TIME in include/config.h.  Setting that means 
you can't camp out - you'll get returned to your last savebed location.  The 
only downside to turning it on is that players get a free word of recall.  But 
if set to something reasonable (1800 (30 minutes)), probably not a really big 
deal - losing half an hour of play time to get that word of recall is probably a 
reasonable tradeoff.

The only other issue with exp reward object is how to handle a party of 
adventurers - I guess that would be easy - split the reward with everyone in the 
party.  If a player leaves the party right before he steps on the space, the 
other players are screwed, OTOH, they are not likely to party with him again. 
But if people just work together and don't actually use the party code, I'm not 
sure how to work it out.

  This could be one reason to add a force object recording player has got the 
reward - then, it could be usuable many times, but if the player has gotten the 
reward, he won't get it again (until the force expires or whatever).  But it 
means everyone he is playing with can also get the reward.

Tracking who has visited the object doesn't make a lot of sense to me.  If 2 
weeks have passed and for whatever reason, people haven't visited that exp 
object, should I get screwed out of that exp?  And at least with force objects, 
we could perhaps have a special 'quest' tag or the like and thus have a command 
which shows which quests you've done and when they expire, eg, something like:

quest name		expires at
return the scroll to
grok			May 28, 23:18
clear tower of foo bar	May 26, 18:54

  and whatever - can use the 'msg' field of the force object to hold the quest 
name.  Thus, a player logs in and says 'ahh - I can re-do the forge sword of 
kram quest, as its not listed'.  The only question would be should the lack of 
repeatability of quests be real (earth) time based, or game time (pticks) based?

As far as plugins go, to me, it makes the most sense to have basic functionality 
within the server code itself, and use plugins to expand the functionality of 
the object.

  In this case, the object actually isn't that complicated - has walk_on/fly_on 
set, in the 'skill' field contains the name of the skill to add the exp to, and 
the exp field contains how much exp to reward.  Some other flag can have 
something like 'player can't use this if force object is in inventory, and we 
add one if player doesn't have force object'.

  Now the plugin can expand that - do other things, do other checks (if, for 
example, the quest is to clear an area, then perhaps the plugin would go look 
and make sure there aren't any monsters in the area).

  To me, we shouldn't expect most map makers to write plugin scripts.  Rather, 
we should provide the basic functionality in objects in the came, which the 
editor make easy to modify, and which are readily available.  If the map maker 
has the skill and want to make plugin scripts, great.

  But as I've said before, the code has to be someplace - whether it is C code 
in the server, or python code in the plugin.  IMO, basic functionality should be 
in the C code.

  I don't mean to downplay the usefulness of the plugin code - there are lots of 
things where you want to do some special processing, but it is used in only a 
few places, and thus doesn't make sense to do it as C code - the plugin is ideal 
for that.  But the python code shouldn't replace the basic operations of the game.

The other fact of the matter is that I'm sure the C code is _a lot_ faster than 
the python code.  This isn't a big deal right now, and probably isn't a big deal 
for most scripts, but if using scripts for common objects became to commonplace, 
we'd then probably start looking at performance at that point and start 
implementing more of it in C anyways.

I also don't think the basis of 'using plugins would be hard, thus we don't have 
to worry about mapmakers abusing it' is quite the right approach.  If it is too 
hard, no one would use it at all, and we'd have the same type of maps we have 
right now.  IMO, keeping good maps is more an issue of players/other developers 
reviewing the maps, saying they are good/map, making changes, and whatnot.  I 
have a feeling a good number of 'bad' maps are not as much because the map maker 
didn't know what they were doing - they almost certainly did when they put that 
mega weapon there or whatever - they just thought it'd be cool or whatever else. 
  If plugins are used, the same thing could happen, and now you also have to 
start reviewing the plugins that are submitted (what exactly is this plugin 
doing?  Does it make sense, is it abusive, etc).






_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel