Re: [crossfire] RFC: dynamic alchemy
On Mon, 22 May 2006 23:56:52 +0200, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: For many formulaes I find the ingredients way too hard to find as compared to finding the equivalent item. I agree. The only exceptions are the water of the wise that are easy to create, especially when purchasing water bottles from the converter in the alchemy shop. It is also easy to find the ingredients for the water of diamond/emerald/ruby/saphire and the mushroom of Gourmet. But beyond these simple things, the cost/benefit ratio of alchemy is just too bad. I'll grant you that potions will work everywhere, as opposed to scrolls/spells on cursed/non magic squares. But still, for instance balm of first aid is way too hard to do, for a few hitpoints restored! (as a side note: shouldn't the balm of flying [word of recall] work whether square is cursed or not, like other balms?) Isn't that the balm of return home? Anyway, I haven't checked but I suspect that the spell is cast when you apply the balm but it fails later when you should be teleported back home (like when you invoke word of recall just before entering a cursed area). Anyway, the cursed squares are a separate issue: I think that too many maps have cursed/no magic areas without giving appropriate clues/warnings to the player. Some of them are there for historical reasons and could probably be removed or replaced by something else. This would deserve a separate discussion. As for finding formulas, I'd say your idea of alchemists could be interesting, but shouldn't require combat or such - maybe finding ingredients, or rare items? Acquiring some of the ingredients may involve some kind of combat. If the alchemist asks you for a chinese dragon's heart or even some simple orc chops, I don't think that you can find them easily without fighting. Currently, the easier quests ask for ingredients that are not too hard to find. Some of them may not even require combat. For example, collecting some flowers or mushrooms. Although they are hard to find inside the cities, they can be found easily in some random maps where they are just waiting to be picked up. The quest gives you some hints about where you might find these ingredients but since they are generic objects you are free to bring them from some other place or even buy them in shops. The more difficult quests (I have only one currently but I am planning for some others) give you access to more interesting formulas. They also require ingredients that are more difficult to find and always require some combat. For these quests, the alchemist (or bowyer, etc.) will ask you to bring him some dread's eyes, lich dusts, etc. Or maybe even more specific items such as blue dragons' steaks or other objects that can only be found in a few places. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
Could someone explain how potion making and similar magic where the result is nothing like what you start off with will work? Will you need to put in a water bottle as part of the recipe? What about balms? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
On Wed, 24 May 2006 14:56:16 +0200, Wim Villerius [EMAIL PROTECTED] wrote:
On Mon, 2006-05-22 at 20:50 +0200, Raphaël Quinet wrote:
I am not sure that the dynamic alchemy as proposed here is the best
alternative, but at least it is better than the abuses that are
allowed by the shadow alchemy tricks.
Honestly, I am not sure as well but I am sure that it's better than
current alchemy and I am even more sure that we can find a still better
solution. That's exactly why I brought up this point. Hopefully we can
design an alchemy-system that makes the alchemist-profession as useful
as the warrior :)
As I wrote in my reply to Anton Oussik, I would prefer a system that
keeps some constraints on the ingredients and on the result of the formula.
A system with a bit more freedom than the current alchemy, but not much
more. I think that the dynamic alchemy is very interesting but it goes a
bit too far.
Also, shadow alchemy is player knowledge and not character knowledge:
this gives an unfair advantage to experienced players regardless of
their character level.
Yes, shadow alchemy is player knowledge, not character knowledge. But
the same goes for current alchemy, maps (passwords), where to find
artifacts, how to beat monsters, etc etc. In other words, (almost) the
whole game is player knowledge.
Well, it is worse for shadow alchemy: it is player knowledge that is very
hard to acquire while playing, but easy to remember (or write down) once
someone or some program tells you how to do it. So it is a bit like cheat
codes for the game. The shadow formulas are of very little use for the
normal players.
Even using dynamic passwords would not change that much: an experienced
player knows where to find the password.
What's the point? Player experience is just everywhere, so perhaps it is
not as worse as it looks.
I agree. But the fact that some things are not perfect should not be an
excuse to making them even worse, if you see what I mean.
Why do I suggest _that_? Because from a player perspective it's horrible
to search for information you already know. Why do a quest to learn that
water of the wise is made in a cauldron using 7 water if you already
know that? Oh, just because the game forces you to do so.
Nothing wrong with that for some items (especially powerful receipes)
but I think it will be very annoying if you have to do so for all
receipes.
(Note that I am not suggesting that this was your suggestion, I just
want to express a bit of frustration about games that forces you to find
out what you already know)
I also agree with that. None of the basic formulas should be locked.
There is no point in forcing the player to go to a specific place to find
how to make the water of the wise. These formulas should be much easier
to find anyway and if a player already knows them, then they can as well
use them directly. On the other hand, the most powerful recipes should be
locked because they are quest items. Even if I remember how to create the
potion of fire immunity, I do not expect to be able to use it immediately
when I create a new character: I know that I have to go through the fire
temple first.
[...]
I suggest to put a lock on every receipe that has a change of zero to be
found in random treasure. (there are quite a few: face of death (dust,
currently broken according to the formulae file), fire immunity,
invulnerability, magic immunity, electric immunity, magic power (both
formulae), fiery destruction, rainbow wave, bolt/arrow of Assassinating
{Dragon, Troll}, bolt/arrow of Blessedness)
My reason for that is that the formulae don't show up in the game, so
players are not supposed to create them. And in fact, they cannot,
unless they cheat.
I would as well add the formula for the potion of cold immunity to that
list, but it currently has a small but existing chance to appear.
As I mentioned earlier, I would also like to lock that potion. But this
is only a suggestion.
P.S.: Did you know that there are ... only two maps in which one can
find Ancient dragons (and the corresponding dragon steaks required for
entering the dragon training levels)?
Nice statistics... Perhaps this one is not very player-friendly.
Well, the entrance to the dragon training levels requires three sacrifices
(Ancient dragon's steak, ancient red dragon's steak and Acient Blue Dragon's
steak). That map is in /dungeons/train/dragon_train. The sacrificed items
are difficult to find but I think that it was done on purpose. However, it
would have been nice to give a few hints about where these items can be
found.
In fact, one of the reasons why I wrote my map checking script is because I
could not find one of these 3 dragons' steaks, even though I had no problems
finding the items required for the other training levels (undead, humanoid,
etc.). So I wrote the script in order to check if I had overlooked some
area of if that training map was broken because it was asking
Re: [crossfire] RFC: dynamic alchemy
On Thu, 18 May 2006 10:34:25 +0200, Wim Villerius [EMAIL PROTECTED] wrote: On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote: To those unfamiliar with it, shadow alchemy generally involves finding hash collisions for the recipes, fooling the alchemy code into thinking you are doing something else entirely. Since the hashing function is (on purpose) very weak, there is no easy way of making shadow alchemy impossible short of entirely changing the way traditional alchemy works. It is currently hard enough to discourage most people though (thanks to some safeguards in the code). For most purposes, however, it currently does what dynamic alchemy will do, but without the much needed game balancing, and very scarce documentation. AFAIK shadow alchemy is indeed in desperate need of game balancing and since it is by no means documentated (except that it's written 'in the code') it is almost never practised (anymore). At least on MF, I know no active players that do anything with it. (Are there any active players anyway?) Perhaps I could even put it this way: because shadow alchemy is undocumented (and almost unknown) there is a request for dynamic alchemy! Sorry for joining this discussion a bit late, but I only restarted plauing Crossfire a few weeks ago. In my opinion, the shadow alchemy should be removed from the game because it will soon be too easy to abuse it (more on that at the end of this message). I am not sure that the dynamic alchemy as proposed here is the best alternative, but at least it is better than the abuses that are allowed by the shadow alchemy tricks. Also, shadow alchemy is player knowledge and not character knowledge: this gives an unfair advantage to experienced players regardless of their character level. One of the reasons for the RFC on dynamic alchemy was that alchemy is not used that much in the game. Before reading that RFC (while being mostly off the net) I started working on a partial solution to that problem: I have started creating a set of maps for an alchemy quest. The basic idea of these quests is that you can apply for being thaught some alchemy tricks by some some alchemists (and smiths, bowyers). They ask you to perform some specific tasks before they reveal more of their secrets to you. This is a bit similar to the quest for becoming the prince of Scorn and the rewards are some formulas, like in the fire temple quest (by the way, I would like to put a lock code on the potion of cold resistance, like there is one for the fire potion that can be found in the fire temple). Some of the tasks that the alchemists assign to their pupils involve the creation of specific items that can only be created by alchemy. For example, you will only get the next task if you sacrifice a Frostbrand or Firebrand of Slay Dragon. It will probably still take a few weeks (or months?) before I am ready with these maps and offer them for testing, but I am hoping that adding some quests related to alchemy could encourage more players to develop their alchemy skills. One of the things that hinder the usage of alchemy in the game is that the formulas are *much* too difficult to find in dungeons and in shops. As a test, I created a new character and I decided to collect all readable items that I would find in the dungeons (bestiaries, books on religion and of course alchemy) and to buy any formula that I could find in a shop. After a few weeks, I had collected a few hundred books on religions and on the various monsters and items, but only 53 unique formulas (I got rid of the multiple copies for the water of the wise). As a comparison, I had also collected 4416 scrolls of identify (various levels) during that time. More than four thousand. Another comparison: before finding the formula for the Ring of Beguilement, I had already found 15 of them in the dungeons. And before finding the formula for the Ring of Mithrandir, I had 4 of them. It is not surprising that nobody uses alchemy if it is so hard to find the formula for any useful item. Not to mention that having the formula is a prerequisite, but only a small part of the solution: the ingredients are usually hard to find and the difficulty for creating the most useful items is such that there is a very high probability of failure. I had to slay a very large number of dragons and many Firebrands/Frostbrands before I was able to create a (non cursed) weapon of Slay Dragon. My suggestion would be to increase (by a large amount) the probability of finding formulas in treasure lists. On the other hand, there could be less books on religions. In my opinion, the random books on religions could even be removed from the treasure lists: the knowledge of gods is mostly useful for low-level characters. After having gained a few levels, it is likely that the player would have already picked a god and is unlikely to change. For that reason, it would be more useful to have the books on religions as part of
Re: [crossfire] RFC: dynamic alchemy
On 22/05/06, Raphaël Quinet [EMAIL PROTECTED] wrote: On Thu, 18 May 2006 10:34:25 +0200, Wim Villerius [EMAIL PROTECTED] wrote: On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote: To those unfamiliar with it, shadow alchemy generally involves finding hash collisions for the recipes, fooling the alchemy code into thinking you are doing something else entirely. Since the hashing function is (on purpose) very weak, there is no easy way of making shadow alchemy impossible short of entirely changing the way traditional alchemy works. It is currently hard enough to discourage most people though (thanks to some safeguards in the code). For most purposes, however, it currently does what dynamic alchemy will do, but without the much needed game balancing, and very scarce documentation. AFAIK shadow alchemy is indeed in desperate need of game balancing and since it is by no means documentated (except that it's written 'in the code') it is almost never practised (anymore). At least on MF, I know no active players that do anything with it. (Are there any active players anyway?) 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. And I am sure that once I publish my map checking script, it will not take long until someone does exactly that and publishes the full list of hash collisions for the alchemy code. Then the problems of the shadow alchemy code will become even more apparent. 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. A couple of summers ago I wrote a short C program that parsed formulae file and generated collisions using these ingredients in O(n^2), it worked quite well. I also saw a Windows collision seeking program that would find a collision that was very profitable and generate a client side script repeatedly doing it. In my opinion shadow alchemy is not widely used because it is so obscure, not because it is impractical. The actual number of collisions is huge though - publishing (and generating) a full list of collisions is quite pointless. 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: If the recipe matches one in formulae file, use that. else use dynamic alchemy: Resistances: Max resistance that can flow in/out of an item is the level of the player in alchemy up to 100%. One can argue that this is too high, but it is already possible to get 100% resist items from traditional alchemy without shadow alchemy - on of the failures generates the desired item with stats doubled. Stats: Max stat that can flow in/out of an item is up to 5, and also depends on alchemy level, where lvl 1-20 is +/-1, lvl 21-40 +/-2, ... for each item in the device for each non-zero property (affected by alchemy) in the item find a random item in inventory get a random number between 0 and the max level allows if the number is greater than the amount in the original item reduce it accordingly transfer the property if amount in the new item is greater than level allows reduce to max level allows effectively alchemy will then have reproducible and yet random behaviour, and will act as a method to transfer properties between objects. Although this method will allow high resistance items in theory, they will be very very rare. This approach also does not need to build up any aditional tables, and so can be entirely implemented within alchemy.c. 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
First of all, apologize for not replying before, I guess you almost forgot what the proposal was about - so did I. ;-) A quick summary: Dynamic Alchemy is the art of transferring magical powers (bonusses) from one object to another. It is not yet clear how the magical powers travel. There are at least two proposals. 1: mark an item as receiving object. 2: they flow from low to high. Due to this unusual direction, items with low magical value cannot be used to enchant to infinity. All items have an upper limit, above which they are useless. A dragon steak might raise (in several steps) the fire resistance from an object to e.g. +30, but not any higher. To make it +50, better stuff is needed (ancient red dragon's steaks) Also, it is not defined what 'magical powers' are. In principle, it is not limited to anything. The idea is that you can use alchemy without predefined results - and without fixed ingredients. Anyone who wants to know more is invited to read the message that opened the discussion - sent on March 27 2006. you wrote: Mark Wedel 1) The idea is interesting. However, like most such proposals, balance has to be maintained - if I can take a couple ancient red dragon steaks and get mithril chain resist fire +90, the case can be made that that is a bit too power. So true. for resist fire+90 one would need more than just ancient red steaks. Defining a max_resistance in a table (or the arches) would prevent this can happen. In the formula I suggested I included a factor (current_resistance - max_resistance) which is the upper limit of possible improvement for a particular source. Thus if an ancient red dragon's steak is defined to give at most +50 fire resistance, it will never ever add more fire resistance using these steaks. For sure, this value of 50 is an arbitrary choice, balancing issue's should settle the real value. 2) You mention where to store information about alchemical improvements, and state your preference for a table instead of the arches. I'd say arches are the right place - a large table is just unwieldy, and unlikely to get updated snip The other point is that if anything, the more recent push has been to get rid of files in the lib directory and put that into archetypes. snip OK, that's fine too. The main reason to prefer a large table was the initial work that is needed to change lots of arche files, that I'm uncommon with them and that in the beginning a lot of things need some tweaks for balancing purposes - which is easier with a 'huge table'. Anyway, I would say that it's not up to me to make such a decision. 3) Other things that could be added: hp/sp/grace regen, sustenance. Bonus movement types (flying, swimming, etc). This last one is trickier because it is really an all or nothing type of thing (either the item lets you fly, or it doesn't). An unrelated but perhaps interesting improvement would by duration items. Eg, this object will let you fly for up to 1000 ticks. Then, for each tick it doesn't fly, it recharges 1 tick of duration. In that model, partial movement types make sense - this object lets you fly, but right now, only for 20 ticks before it needs to rest - further improvements increase the duration. Doing this wouldn't be that far off from the rod code. I see no reason why these couldn't be added - as long as the item remains in balance. About movement types, I cannot exactly grasp how a platemail could give the ability to swim, my first guess would be it gives a 'dive' (rather: sink) ability. Nevertheless, magic is magic, so why not euh? I like the idea of temporary giving an ability, but what do you do with a swiming player that looses his abiltiy to swim? Unless boots of levitation become very rare, nobody will add a flying ability to their equipment - you can't thrust it. 4) In terms of stats - they are sort of like movement type - either you add a stat point or don't. However, the key-value lists could be used to hold fractional improvements. So each improvement gets you say 0.1 of a point - you could in fact use similar logic to your resistance improvement idea. Thus, it could a bunch of objects to improve a stat. Or the whole stat-thing should be redesigned to allow stats to grow into a few hunderd ;-) This requires a lot of work - all items should be updated. (And I think it's quite a different discussion at all.) A problem with the approach you suggest is perhaps that stats are stored as ints (I assume). I have no clue if it is possible to change that behaviour. 5) Direction of resistance - if prepare weapon scroll is used, as said, that solves the problem. However, as one of the potential bad effects, maybe it does reverse. One problem with 'low to high' is that if you are starting with something relatively mundane you want to improve, that is unpredictable. Lets suppose for some reason you just want to start with a simple +1 sword. That could be low. Yes, but then first start improving it with
Re: [crossfire] RFC: dynamic alchemy
On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote: To those unfamiliar with it, shadow alchemy generally involves finding hash collisions for the recipes, fooling the alchemy code into thinking you are doing something else entirely. Since the hashing function is (on purpose) very weak, there is no easy way of making shadow alchemy impossible short of entirely changing the way traditional alchemy works. It is currently hard enough to discourage most people though (thanks to some safeguards in the code). For most purposes, however, it currently does what dynamic alchemy will do, but without the much needed game balancing, and very scarce documentation. AFAIK shadow alchemy is indeed in desperate need of game balancing and since it is by no means documentated (except that it's written 'in the code') it is almost never practised (anymore). At least on MF, I know no active players that do anything with it. (Are there any active players anyway?) Perhaps I could even put it this way: because shadow alchemy is undocumented (and almost unknown) there is a request for dynamic alchemy! I like your idea about dynamic alchemy, but creating a resistance table seems like a lot of work, and so does messing with the arches. Instead, why not make a semi-random roll on what to add/subtract, partially based on the hash value of the ingredient? This means that only the alchemy.c file will need changing, and dynamic alchemy will have a much better chance of actually happening (+working). That would be very interesting, the only question is how to make a reasonable guess. It would be kind of weird if a Vampire's heart gives resist_fire bonus. I'm terribly afraid that it has to be documentend (one way or the other) what bonusses an item can give, but that could be my ignorance :) If you (or someone else) has an idea to make this suggestion work, I'd be happy with it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
Quick thoughts: 1) I'd prefer a way to say what item I want improved, vs it improving the strongest. this is more an issue for the first improvements most likely. Or if it is very clear how it decides what is the more powerful object (item power) that may be reasonable, except you have 2 objects with power 0. 2) Limiting the improvement of the target item based on the first item probably isn't good. In the case of resistances, one can find items that have very high resistances, but these can not be directly applied to the player or have a limited duration (think of the potions here). If I can take that potion of fire resistance (90% resistance) and apply it to a sword or other permanent item, that would make things way out of whack. Even 75% fire reistance on an item may be too powerful. This is more a case if the player has a mechanism for making those items. While there are some good items out there right now, there are some effectively limitations because they would go on the same place on the body (dragon plate mail gives good protection, but you can only wear one suit of armor at once). If I can make a hat, boots, gloves, belt, etc of fire resistance, many limitations may be easily overcome (OTOH, there really isn't anything that prevents those items from showing up in maps.) 3) I'd also think it is nice for items improved not to be tied to the player as previously state. However, I was thinking that what could be done is that based on the power of the item, there is a random chance it becomes tied. In this way, a player could make items for others, but not really powerful ones. That said, IMO, the need to make some objects god given is no longer relevant with the item power code. At one point, I think that was to make it so that you couldn't give really good stuff to low level players. While item_power doesn't prevent that gift, it effectively prevents the low level character from using it. IMO, if we really want more multi player cooperation and interaction in crossfire, we really shouldn't limit what players can trade, etc. 4) Stats are currently ints. Changing it so that the max value is much higher is IMO not a worthwhile task. They could probably be changed to floats with a lesser amount of work. Another approach is the mimicing of floats via random numbers. If that item should really improve it by .1, you make a random roll with a 10% chance of it increasing it, the rest, it does nothing. For alchemy, this could be good enough, and adds some luck and 'oh cool, it worked this time' factor. 5) For most custom objects (white dragon scale armor) there is no way to know if it has been modified from the normal one. The only thing you can really find is if it has been modified from the archetype, but lots of things on maps are already modifications from an archetype (almost all generated treasure is in fact). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
On 27/03/06, Wim Villerius [EMAIL PROTECTED] wrote: Shadow alchemy is an exploit, used to create items that are impossible to create with dynamic alchemy. (It is impossible to have items with resist_something 99 - and this limit could even be set lower) To those unfamiliar with it, shadow alchemy generally involves finding hash collisions for the recipes, fooling the alchemy code into thinking you are doing something else entirely. Since the hashing function is (on purpose) very weak, there is no easy way of making shadow alchemy impossible short of entirely changing the way traditional alchemy works. It is currently hard enough to discourage most people though (thanks to some safeguards in the code). For most purposes, however, it currently does what dynamic alchemy will do, but without the much needed game balancing, and very scarce documentation. I like your idea about dynamic alchemy, but creating a resistance table seems like a lot of work, and so does messing with the arches. Instead, why not make a semi-random roll on what to add/subtract, partially based on the hash value of the ingredient? This means that only the alchemy.c file will need changing, and dynamic alchemy will have a much better chance of actually happening (+working). These are the things I can think of adding/subtracting to items: resistances stats speed weight value ? -- careful not to make this one exploitable ac wc luck ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] RFC: dynamic alchemy
Hi, Dynamic alchemy is a proposal which was discussed about a year ago on the message board. During that time I've been writing a message for the list that never was sent for a reason I cannot remember. Perhaps I judged the proposal to be too incomplete to lead anywhere. Perhaps it was because I am not capable to code anything myself. Anyway, since I think this would nevertheless be an interesting addition to Crossfire, I now do send it. Take your time, the message is pretty big now. (I'm sorry for that.) I don't think the idea in its current state is ready for implementation, but an idea - in whatever state it - is ready for discussion, right? ;) WHAT IS ALCHEMY? Alchemy is a form of chemistry studied in the Middle Ages which involved trying to discover how to change ordinary metals into gold (Oxford advanced learner's dictionary) WHAT IS ALCHEMY IN CROSSFIRE? In Crossfire, we don't try to create gold, for it is a rather useless metal. As far as I am aware alchemy is used like a fully controlled commercial process. It is highly accurate and reproducible, more or less like a chemical, an industrial process! So, current alchemy is more or less an industry used to create predefined items in a predefined, reproducible - 'scientific' - way WHAT SHOULD ALCHEMY BE IN CROSSFIRE? From a role playing perspective, what should alchemy be? IMO this question is assuming too much. It does assume role-playing! Crossfire doesn't have much role-playing at all, since (almost) all players tend to be(come) a 'Jack of all trades' (and a master of all, if they spent sufficient time). OK, scratch that role-playing perspective for now, and just ask what alchemy should be. Way too hasty, first ask if there is any need for alchemy and if the current alchemy is not sufficient. Alchemy is not necessary (strictly speaking). Although it is an interesting addition to the game, it usually doesn't come in sight before a player is already quite experienced and has seen a lot of the world. At that stage, alchemy and alchemy results do not offer much - except little experience and some money. The artefacts found in game are better than alchemy results (except for results of shadow alchemy, a subject I don't wish to discuss). So, alchemy is not necessary. But that's not an answer to the question whether there is any need for alchemy or not. I would say Yes!, playing with alchemy is (or is supposed to be) a lot of fun. The answer to the second question (Is the current alchemy system is sufficient?) is by me answered with a resounding No! Why is that? For reasons already mentioned: - results are pre-defined - results are not half as powerful as 'normal artefacts' In other words: If we manage to develop an alchemy system that allows one to create really powerful items, a system that does offer more than just predefined results, I'll be satisfied (but others wont). Before continuing with some more detailed descriptions, I would like to offer some in-game notes about alchemy. Since the game takes place in a not-so-very-high-tech world (where very high-tech things like teleportation are still magical) nobody (in that world) has exact knowledge of what alchemy is. Alchemy is an art practised by many, mastered by none. In ancient times, there where a few great alchemists, and their stars rose high. They all where capable creating highly enchanted equipment, and some of these items, amongst which the Dragon Scale Mail of Ruggilli still exist today. Perhaps the most praised White Dragon Scale Mail still exist somewhere. Although equal in skills, the ancient masters of Alchemy had very different definitions of what exactly alchemy is, and they where likely all wrong. Since alchemy is a business enshrouded in a cloud of vagueness, nobody exactly knows what could be the result of an alchemical process. Therefore, nowadays alchemists describe the art of alchemy as a mystic process used to transfer magical powers from one item to an other. This is the baseline I will use in the development of a new alchemy system, which I would like to call 'dynamic alchemy'. DYNAMIC ALCHEMY AND THE CURRENT SYSTEM Dynamic alchemy is not intended to be a complete replacement for current alchemy, but it is more than just an extension. Dynamic alchemy is used to create 'advanced' equipment, current alchemy remains to create base ingredients (such as water of the wise, (fixed) mercury, potions of ...). Since equipment is not created with alchemy but rather with bowyery, jewellery, smithery, thaumaturgy or woodsman, we perhaps should speak about dynamic bowyery (etc.). I will not do so, but please keep in mind that experience gained from any dynamic process will go (I assume) in one of these skills and not in alchemy. For the user nothing but the recipes (and results) changes, but under the hood, there will be lots of difference. DESCRIPTION OF 'DYNAMIC ALCHEMY' As said before, dynamic alchemy is the art of transferring magical powers from items to other items.
Re: [crossfire] RFC: dynamic alchemy
Various thoughts: 1) The idea is interesting. However, like most such proposals, balance has to be maintained - if I can take a couple ancient red dragon steaks and get mithril chain resist fire +90, the case can be made that that is a bit too power. 2) You mention where to store information about alchemical improvements, and state your preference for a table instead of the arches. I'd say arches are the right place - a large table is just unwieldy, and unlikely to get updated (I can see the relatively common case of someone copying one arch to another, changing the name, and making some other changes. This won't match in the table, and thus the table is out of date. Yet if they copy the archetype, they are likely to see alchemy_... fields.) The other point is that if anything, the more recent push has been to get rid of files in the lib directory and put that into archetypes. I'm specifically thinking of the treasurelists here - no longer do we need a monolithic file for all the treasure lists, these can be in the arch directory tree. 3) Other things that could be added: hp/sp/grace regen (unless you count those as stats). sustenance (slower digestion). Bonus movement types (flying, swimming, etc). This last one is trickier because it is really an all or nothing type of thing (either the item lets you fly, or it doesn't). An unrelated but perhaps interesting improvement would by duration items. Eg, this object will let you fly for up to 1000 ticks. Then, for each tick it doesn't fly, it recharges 1 tick of duration. In that model, partial movement types make sense - this object lets you fly, but right now, only for 20 ticks before it needs to rest - further improvements increase the duration. Doing this wouldn't be that far off from the rod code. 4) In terms of stats - they are sort of like movement type - either you add a stat point or don't. However, the key-value lists could be used to hold fractional improvements. So each improvement gets you say 0.1 of a point - you could in fact use similar logic to your resistance improvement idea. Thus, it could a bunch of objects to improve a stat. 5) Direction of resistance - if prepare weapon scroll is used, as said, that solves the problem. However, as one of the potential bad effects, maybe it does reverse. One problem with 'low to high' is that if you are starting with something relatively mundane you want to improve, that is unpredictable. Lets suppose for some reason you just want to start with a simple +1 sword. That could be low. However, I think that given crossfire is multiplayer, binding improved objects to players isn't a good idea. I should be able to create some cool stuff for a friend - that will help things IMO than everyone having their own stash. It also means that not everyone has to be an alchemists - a few powerful player alchemists in the town could possibly make pretty good business improvement objects for other players. However, one could perhaps change the enchant item scrolls - it just marks the object for improvement, but doesn't tie it to the player. 6) I think even some more dynamic aspects are needed. For example, you can't really enumerate the normal rings - rings have their resistances added in the treasure code - there is no way to say a ring of str +1 is this archetype. So you need some way to say 'if this is a ring, examine what properties it has and choose one for dynamic alchemy'. Perhaps some for a large majority of food items. One thought on this is that for a baseline, the object can't improve the object any more than it grants. For example, you have a ring str+1 resist fire +18 You toss it in the pot to transfer to your plate armor. If your plate armor already has str +1 or resist fire +18, this ring can't help out at all. However, if the plate armor has less than that, this ring can help bring it to that point. This does get interesting if you have a ring like 'resist fire +20, resist cold -20'. Can resistances (or other things) get drained away? Does the code try to optimize for improvements? That also raises the other interesting point: Suppose I have plate armor resist cold -20. Can I transfer away that resist cold -20 to just some other object, or is the only way to get rid of it is via resist cold + objects? I bring that point up because that could be used to explain why there are items with negative resistances - they were used to get rid of the undesirable aspects of an otherwise good object. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
