[CF-Devel] new artifact & treasures idea

Thu Dec 18 23:54:56 CST 2003

Todd Mitchell wrote:

>

      This is good as well, especially when dealing with monster abilities.  I

     >

      think it would be great to be able to assign more than one treasure list to a

     >

      object - especially for say monsters or NPCs who could be assigned a body

     >

      parts list, a treasure list and a 'jail' or citizen list which contains local

     >

      specific random items or special 'guards' to summon when they are killed.

     >

      (you slay the orc at the door to the summoner's lair but now 5 gnolls appear-

     >

      he must have sounded an alarm!  You should have tried to sneak past him.)

  Well, if you can assign treasurelists to objects, you could easily do this. 
you could do something like:

starttlist
   list body_parts
   more
   list city_item
   more
   list normal_treasure
endtlist

  And thus you basically have three treasure lists.

>

     >

      Making the list more modular would be good too as now the treasure list calls

     >

      the bodypart list so new lists must be created for any new combinations.  You

     >

      can of course insert items directly in the inventory but this would be a

     >

      better way to insert entire lists and random items.

  Not completely sure if I follow what you mean.

  Are you asking for something like an 'allowed' keyword in the treasurelist?

  Thus, you could have one list of bodyparts, but something like:

treasure body_parts
    arch orc_chop
      allowed orc
      chance 5
    more
    arch dragon_scale
      allowed dragon
      chance 30
    more
...

  And so on?  Given the list format can contain redundant entries, with 
different match criteria, probably easier to list each monster you want the item 
to show up for (one entry for dragon, one for wyvern, one for chinese dragon, etC).

  OTOH, I really wonder how much it comes up - the dragon is already going to 
have a different treasure list than the orc anyways.  Such customizations would 
be most useful for common lists (more low level lists).

  I had thought of changing the format - it seems that more than once there have 
been errors of missing 'more' keywords or the like.

  But I'm not sure of a form that would necessarily be a lot clearer.  And the 
current list does allow the fact that even within a single list, you can 
basically form a tree structure (eg, the no/yes combos)

Nicolas Weeger wrote:

 >>  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.
 >
 >
 > I was thinking of chance adjustement on a 'sublist' level. IE 5% chance
 > of damned item, independantly from other 'sublists', and +2% per level
 > over 30 for instance.
 > It would not affect total chance, just the item generation.

  But if it is a treasureone list, you need to change the total chance.  Eg, 
take the following list:

treasureone physical_traps
   arch trap_diseased_needle
     chance 70
   more
   arch trap_blades
     chance 33
   more
   arch trap_needle
     chance 33
   more
   arch trap_spikes2
     chance 33
   end

  If you add something like diff_adjustment 3 to the 'trap_diseased_needle 
list', then if this list is called on a high level map, the effective chance fo 
a disease needle show up might be 100.  Without a change to the code, that would 
need that the last entry could basically never happen (code makes a number 
between 1->169, based on the total chance that is stored away.  Lets say it 
rolls 150.  Process the first item, with adjusted chance of 100.  Doesn't choose 
that, but remaining chance is no 50.  Looks at next item - chance 33.  Doesn't 
take that, but remaining chance is now 17.  IT does take the next item 
(trap_needle) because that chance is now greater than the remaining value.

  So for those higher difficulty treasureone lists, you need to adjust what the 
total roll chance is before making the roll, otherwise items at the end of the 
list are less likely to show up.

 >
 >>  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).
 >
 >
 > Indeed depends on the granularity we want for forbidding combinations.
 > If it's not too hard to implement i'd go for the finest granularity (ie
 > forbid strange ring of ruling but let go strange ring of thieves)

  While fine granularity is often nice, there is the code complication (and in 
this case, also treasurelist and so on).

  However, if that was really the desired result, one coudl still do that - just 
take the normal treasurelists for ring, rename them, and remove the ruling 
template but leave the rest.

  In the long run, such granularity could make the lists unmanagable.  OTOH, I'm 
not sure I see the need of such granularity.  And it really doesn't exist right 
now (the artifact code just matches all rings right now, so you could get a 
strange ring of whatever, but of course some combos would be quite rare).

  My personal thought is that in most cases, the 'true' artifacts should 
probably be disabled from having templates applied to them.  This is mostly for 
balance - true artifacts are often already quite powerful.  If some template 
like '20% more damage' was applied on top, that could really take an artifact 
from 'very powerful but OK' to 'too powerful - shouldn't be allowed'.

 > And since all files are public in the first place, I don't really think
 > that's an issue to make things more public. Quite the contrary, maybe
 > it'll give non-tech-savy people a chance to come up with nice items :)
 > Also will give more options for server customisation, since you'll be
 > able to change a text file instead of hacking the code.

  My point is that it is reasonable to expect map makers to be able to 
understand treasure lists and archetype files.  IT's a bit unreasonable to tell 
them 'look at the code in treasure.c to try and figure out the likelihood of 
specific plus items showing up on your map'.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel