[crossfire] RFC: dynamic alchemy
Raphaël Quinet
quinet at gamers.org
Wed May 24 07:34:01 CDT 2006
On Tue, 23 May 2006 01:56:44 +0100, "Anton Oussik" <antonoussik at gmail.com> wrote:
> On 22/05/06, Raphaël Quinet <quinet at gamers.org> wrote:
> > [...] Once this full list of all items is available, it is not very
> > difficult to perform a "brute force attack" on the alchemy hashes. This
> > would be easy to do because the large but finite list of all named items
> > that can be picked up in the game can now be generated easily. [...]
>
> The full list of items is not really needed nor preferred. What you
> want is a list of easily avaliable ingredients (things you can get in
> large quantities from altars, money, and summonable items), and
> generate hash collisions using those.
I should have explained this better in my previous message: the list
of items that I get out of my script is sorted by "relative abundance".
It counts the total number of objects of each type (or each name, in
this case) found in the maps. For the objects that have treasure lists
or that are generators, it also takes into account the items that can
be generated and their relative probability of being generated (so you
can end up with fractional numbers, as I mentioned previously).
Besides finding the hash collisions for shadow alchemy, you will also
know how easy it is to find the ingredients.
> Removing shadow alchemy alltogether would only work by not allowing
> recipes not found in formulae file at all, in which case there is no
> point in having a hash value representing the recipe, and the way
> alchemy works needs redoing entirely. Dynamic alchemy IMO can replace
> what is used today, but I think it should work thus:
[...]
One thing that worries me a bit about dynamic alchemy (including the
variant that you described) is that it could be used with almost any
item. Even if there are safeguards based for example on the highest
level allowed and things like that, there is a risk that it could
bring some imbalance in the game if some items with unusual properties
go through the dynamic alchemy process.
I would prefer a system that is still based on some kind of template
given in the formulae file. For example, some "template formula"
would only work for daggers, another one would only work for pieces
of armour made of copper, etc. Each template would have constraints
on the kind of improvements that could be applied to the base item
and the ingredients or class of ingredients required for these
improvemens.
I am not really sure about how these templates could look like, but
the general idea is that I would prefer something that is still
(loosely) defined in the formulae file rather than something that is
a bit too dynamic.
> Also IMO traditional alchemy recipes should be made easier to do. By
> the time you find ingredients, you can already find/buy the target
> item. Perhaps ingredient shop should extract ingredients straight from
> the formulae file, and stock those, in large quantities. This way
> alchemist would be able to buy ingredients without spending ages
> looking for them in the wild. I know ingredient list is supposed to
> encourage exploration, but if you go exploring you will find the
> target more easily than find and collect all the ingredients. There
> also needs to be more medium and high level alchemy-only items that
> require high (100+) level to generate.
I agree that the cost/benefit ratio of alchemy is bad. Also, reaching
level 100+ in the alchemy-related skills is currently rather hard.
Besides the improvements that can be made in the maps (like the quests
that I described, and the corresponding random maps providing an easier
way to get some ingredients), I would like to encourage the usage of
alchemy by adding more valuable items that can only be created via
alchemy. These items would never be found in treasure lists. Instead
of adding more formulae, another option could be to remove some of the
items that are currently found in treasure lists and in the formulae
file so that they can only be created, not found.
-Raphaël
More information about the crossfire
mailing list