[CF-Devel] new artifact & treasures idea

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

Nicolas Weeger wrote:
>
     
      Sounds like a good idea.
     
     >
     
     
     >
     
      Here are some more random suggestions/thoughts:
     
     >
     
      * some way to tweak sublist's chance based on 'difficulty' (map or 
     
     >
     
      whatnot). For instance to increase the chance of damned item as it goes 
     
     >
     
      more powerful.
     
     >
     
      Like:
     
     >
     
          randomitem helm
     
     >
     
              ...
     
     >
     
              arch damned
     
     >
     
                  min_diff 30
     
     >
     
                  chance 5
     
     >
     
                  diff_factor 2
     
     >
     
     
     >
     
      for a difficulty of 37 damned chance becomes 5 + 2 * 7 = 19%
     
     >
     
      (formulea is just the first to pop outta my mind, can be changed :))
     
     
  That's a good idea - it would do one of the things I did mention in my 
previous mail, which is to make it easier to make better objects show up more 
often in high level maps - one could even do something like negative 
diff_factors (eg, item becomes less likely to show up as the map increases in 
difficulty).

  The one problem with this is increased cpu time.  Currently, the total chance 
of a treasure list is set when the treasure lists are first loaded 
(chancedifficulty).  In this way, if the treasureone list total chance is 85, we 
can generate that number between 1->85, and then as we walk the treasure list, 
substracting the chance for the object - when we get to <=0, that is the item to do.

  If adjustments to chance are allowed on the treasureone lists, now the list 
would have to be walked two times - once to find out the total chance based on 
difficulty, and then again to actually choose the item.  But that probably isn't 
that big a deal.

>
     
     
     >
     
      * one drawback i see with the implementation is that it'll be real hard 
     
     >
     
      to forbid special combinations. If we want to forbid strange ring of 
     
     >
     
      ruling, we'll need to make 2 lists, one with strange and not ruling, the 
     
     >
     
      other with ruling and not strange, and duplicate all stuff we put (else 
     
     >
     
      probabilities make that at some point one will appear). I'd suggest a 
     
     >
     
      way to say 'this arch can be used only if this arch was not used', but 
     
     >
     
      it may be slightly overkill to implement...
     
     >
     
     
     >
     
      (this assumes ring is implemented something like
     
     >
     
          arch random_ring
     
     >
     
              arch strange_ring
     
     >
     
                  chance 5
     
     >
     
              end
     
     >
     
              arch Ruling
     
     >
     
                  chance 1
     
     >
     
              end
     
     
  That may be less an issue.  I'd presume that it'd be more generic than 'don't 
allow strange ring of ruling', but more likely of 'if this is a strange ring, 
then it can't get additional artifact abilities'.  And in that case, its much 
simpler - it may just mean we set the randomitems for the strange ring to be 
empty (presuming that since it is an artifact, things like material and other 
abilities shouldn't be added).


>
     
     
     >
     
      * the treasures file will grow fat, but maybe that's not too bad. 
     
     >
     
      Someone wanting to find some info without downloading whole arch module 
     
     >
     
      will need sometime to find it, though :)
     
     
  Well, I'd imagine one coudl probably write a nice tool to display the 
treasurelist in a friendly to display format (hyperlink or something to show how 
the lists are related to each other).

  The counter to this is that the archetypes file disappear, and everything is 
more public (you don't need to look at treasure.c to figure out how attributes 
to some items are added).

  Perhaps part of this, allow treasurelists to be set in objects themselves - 
that in itself would be relative simple of something like:

starttreasurelist
....
endtreasurelist

such a list could make references to other lists in treasures, but those lists 
could not make references to that per object list of course.



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