[CF-Devel] Alchemy thoughts

[Mark Wedel]

  Some of this has probably been discussed before, but I was going to do some 
work to fix the experience flaws in alchemy (exp is basically the square of the 
number of objects).  My initial thought to that ws to just add an 'exp' field to 
the formula table, and use that.  This contral right there would do wonders - 
fix the above bug, but also let you tune exp for other factors (a hard to do 
formula because of rare components but in itself that isn't very complicated 
could perhaps have a high reward vs a formula that has many parts, but all of 
them common.

  But when I thought about this, I thought about refining alchemy more.  So here 
is my idea:

  Instead of the 'recipe' structure, put the formula into an object structure. 
Some fields may need to get overloaded (or additional ones added to the object 
structure) - fields I see (parens are current name in recipe file)

other_arch (arch): was this formula creates
nrof (yield): max number this can create
recipe treasurelist (chance) - likelihood of formula appearing in books -
    basically, make a treasurelist of all the recipes that you want to randomly
    appear, and when a recipe book is made, it uses that to choose one
msg (ingred): Recipe (ingredients) for this.
is_used_up (trans): Converts an existing object as the base object
slaying (keycode): player must have force with matching slaying field to make
     this recipe

New fields as far as recipes:
exp: How much exp you get for making this item

level: 'level' of the recipe - basic value to determine probability of making 
this recipe.  Eg, when you make it, it rolls a d20 and adds your alchemy level - 
this has to be higher than the level of the recipe for you to succeed.  In this 
way, you could set up recipes that require a reasonable amount of exp to make

  what I'd also do is make a new type of object - RECIPE (or maybe ALC_FORMULA, 
suggestions?).  When a recipe book is created, it would basically just take the 
above described arch and change the face appropriately.

  When a player applies it, a minor amount of server code would digest what the 
message string is and describe the recipe.  Also, at the same time, the code 
would check to see if the player knows this recipe - if he doesn't, we make an 
invisible copy of this object and insert it in the players inventory (so 
checking to see if the player knows it if is just seeing if he has an object of 
the same name in his inventory).

  What this last point allows is twofold:
1) Player can do something like 'alchemy' and see what recipes he knows, and the 
formula for them.
2) Could make a requirement that the player has to know the recipe in order to 
execute it, or alternatively, adjust probability of success.

Overall advantages:
1) Makes alchemy more balanced.
2) Hopefully makes alchemy more useful.
3) Reduces some redundant code (generic object loader can now be used to read 
the formulae file, instead of using its own, as well as not needing recipelists 
and like stuff).  Actually, if this is done, you don't have a formulae file 
anymore - you just have a 'formulae' arch directory, since these are now arches.

4) Would allow map designers to put new recipes on their maps!  All they would 
have to do is make the appropriate 'RECIPE' object on the map with the 
appropriate fields (note for such new recipes to work, they player would have to 
know the recipe, as that recipe wouldn't be in the list of global recipes, but 
that is probably a good thing)

  Thoughts?  Suggestions?  comments?