Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NW_Kohaku]

By the way, for a little clarity on what Atelier Rorona is like...

See: http://www.youtube.com/watch?v=4siJ0NoS0Cs&feature=related

The "Trait Choices" in the bottom right?  That's the part I'm leaning towards learning from. 

That recepie, by the way, takes "anything with the [PLANT] category" and a "Pure Oil" specific item to make a "Healing Scent" (a bar of soap that exists only to be used as another intermediary product for further synthesis). 

[NW_Kohaku]

Since this has also come up in several other threads, I'd also like to say this:

This is not something that I suspect will be added onto the game as it is right now.  Dwarf Fortress has some serious need for some script-based commands (as in Standing Orders) to alleviate the micromanagement as it is, and partly, this system would be contingent upon having a more sane control system over the way in which dwarves work. 

That is to say, even as I suggest these things, I am not saying they are a higher priority than what are already the highest priorities of the ESV.

The way that this suggestion would interact with the rest of the DF intra-fort economy is that it would enable the creation of specialty goods when you feel the need to focus in on producing them.  With some of the interface elements I mentioned and standing orders, you should be able to just set up the production of +20% restfulness beds when you fall below 10 of them in stock (unbuilt).  It would just be a more complicated set of standing orders than normal to keep the supply chain steps in order.

Hence, with the proper interface elements, much of the most tedious micromanagement steps would at least be a single event, with the micromanagey looking-over-the-shoulder of every craftsdwarf and workshop handled automatically.

[Aachen]

Well thought through, and very flexible. I'd vote, but ....

It should link directly to the specific item.  It does for me when I click on it...

It gives me the top of the page. Is this topic tied to #213?

[NW_Kohaku]

Well thought through, and very flexible. I'd vote, but ....

It should link directly to the specific item.  It does for me when I click on it...

It gives me the top of the page. Is this topic tied to #213?

I'm not sure why it doesn't work for anyone else, because it links to the proper voting item for me, but it's "Alchemical Material Property Tokens", so just CTRL-F for that, I guess.  The links in the ESV are just weird, though, as I've seen the link change over time on occasion.  (That is, the item I was linking to was something like "vote#281", and then it later becomes "vote#280".)

[axus]

It's hard for me to read everything you put together, but I do support alchemy and potions in DF.  No intermediate components, though   The "easiest" way to implement it is like the Dwarf Fortress kitchen, where the "cook" fetches a bunch of ingredients and produces a batch of finished products.  The requirements system can be as complex as you like, as long as it's the alchemist that has to figure it out and not the player.

Alchemy knowledge could work like the animal taming knowledge Toady just posted about.  The civilization has knowledge of certain ingredients, and the site has it's own knowledge.  Maybe an "experiment" job could be added to let the alchemist try unknown ingredient mixes automatically to test their properties.

[Adrian]

http://en.wikipedia.org/wiki/Information_overload
I enjoy reading your giant threads, but adding diagrams or examples, like you did in the 'Outline of what will need to be implemented'-spoiler, will increase legibility 100-fold.

On a critical note i want to advise against the use of "useless properties". Running Dwarf Fort as is will already consume 600MB of RAM, and i cringe at the thought of the engine having to track useless data.

Now i'm going to grab something to drink, continue reading and post critique and ideas as they come to me.
So i'm starting to get a grasp on your Chemical Reactions Web. I say 'chemical' because it doesn't seem particularly alchemy-y (yet).
So far it looks like the web is just scrambling the physical properties of materials during reactions.

.. the water is altered with some bone powder being dissolved in ..

This might ask for some form of solubility-tag, like [SOLUBLE_WATER], [SOLUBLE_ETHANOL] or [SOLUBLE_NO], if only to prevent the game from accidentally dissolving the bones of your dorfs into their blood.
These tags could also make extracting water-insoluble dyes using ethanol distilled from rum possible.

Next, i don't understand wheat you mean by this:

Alchemical reaction webs .. can be procedurally generated on worldgen.

It feels like nowadays, 'procedural generation' has become a buzzword for a magical process that creates complex things out of little to no data.
To me, however, it refers to a magical process that creates things when they are needed. So the idea of creating the web at worldgen is confusing to me, seeing as how everything is created at worldgen.

Conflicting properties sounds interesting, but there needs to be more brainstorming on how to handle those conflicts because it sounds like it's going to be CPU intensive, should those properties ever get to influence the world outside the reaction.
For the reaction itself, my idea would be to assign a value to properties that might conflict with others (eg. 'X:70' or 'Y:100'), and subtracting those to create a 'Y:30' token (as opposed to an 'X:-30' token).

[NW_Kohaku]

It's hard for me to read everything you put together, but I do support alchemy and potions in DF.  No intermediate components, though   The "easiest" way to implement it is like the Dwarf Fortress kitchen, where the "cook" fetches a bunch of ingredients and produces a batch of finished products.  The requirements system can be as complex as you like, as long as it's the alchemist that has to figure it out and not the player.

Alchemy knowledge could work like the animal taming knowledge Toady just posted about.  The civilization has knowledge of certain ingredients, and the site has it's own knowledge.  Maybe an "experiment" job could be added to let the alchemist try unknown ingredient mixes automatically to test their properties.

Yes, to reduce it down to its most basic components, that is exactly what I am proposing.

The system I am talking about is basically going to look very much the same as the way that cooking works already, but where you can suddenly get very different results from cooking slightly different materials, and where you can specify exact ingredients when you want exact results. 

Likewise, the production of a "civilization knowledge" about alchemy is exactly the sort of thing I wanted when I was working on this, and Toady just happened to arrive at from a different angle. 

http://en.wikipedia.org/wiki/Information_overload
I enjoy reading your giant threads, but adding diagrams or examples, like you did in the 'Outline of what will need to be implemented'-spoiler, will increase legibility 100-fold.

Sorry, I thought I had managed to keep this one relatively simple, but there's only so much you can do when you're trying to work with something that I think is operating at a much more "programmer" level than a "player" level to help the non-programmers understand how the system will be different.

Diagrams could help, but I'll just need time to produce them.

On a critical note i want to advise against the use of "useless properties". Running Dwarf Fort as is will already consume 600MB of RAM, and i cringe at the thought of the engine having to track useless data.

Keep in mind that the game already just runs on, basically, "links" (pointers) to data already.  As in, limestone walls are all just links to a single definition of limestone, and the game really just sees "wall tile" with "link to material" in the game, already.  That limestone data is going to be there, regardless of how whether there are any limestone walls to begin with.

What this does is simply creates new definitions out of different combinations, and while the number of possible permutations goes up the more different tags you add in, the complexity of this won't be of the level that comes on part to matching the complexity of having hundreds of thousands of items on the board in the first place.

Next, i don't understand wheat you mean by this:

Alchemical reaction webs .. can be procedurally generated on worldgen.

It feels like nowadays, 'procedural generation' has become a buzzword for a magical process that creates complex things out of little to no data.
To me, however, it refers to a magical process that creates things when they are needed. So the idea of creating the web at worldgen is confusing to me, seeing as how everything is created at worldgen.

I think it's just part of entering into the world of programming that you start getting hit with those shibboleths.  I never really heard the word "procedural" anywhere but in gaming. 

Anyway, this relates back to one of Toady's old, over-arching goals, where everything about the world is created procedurally.  As in, you don't have dwarves with steel in a fortress every time, you press a button, and a completely randomly generated new creature is the dominant sapient species, with completely different hidden spoiler metals to be found if you start digging, with completely different hidden horrors lurking the caverns of the deep, with entirely different chemicals that react in entirely different ways.  I'm just talking about how this can relate in to that old idea.

The basic idea is that, if we build a single "chemistry" library of reactions, then there's only room to explore that alchemical reaction web once - then you've already explored it, and in future games, you're just re-discovering the wheel.  If, however, the tokens on each type of material change, and the way reactions occur change every game, then you have to re-explore that web every time you create a new world.

That's why there could be one "vanilla standard" web of reactions, for the new people exploring the system for the first time, who can look things up on the wiki to find all the answers when they are stuck or need help, and then an "alchemical explorer"'s set of reactions for those who enjoy the act of discovery. 

Conflicting properties sounds interesting, but there needs to be more brainstorming on how to handle those conflicts because it sounds like it's going to be CPU intensive, should those properties ever get to influence the world outside the reaction.
For the reaction itself, my idea would be to assign a value to properties that might conflict with others (eg. 'X:70' or 'Y:100'), and subtracting those to create a 'Y:30' token (as opposed to an 'X:-30' token).

The major way that conflicts are supposed to be resolved is that this check only occurs every time that a reaction is occuring in a catalytic event.  That is, it only occurs in the workshop when a dwarf is specifically trying to make something react.  Hence, nullifying properties are no more difficult to handle than any other reaction. 

That is, relatively speaking, it is a rare event for a wood log to be made into a wood bed.  It's only during that event that all the properties on the wood log have to check whether or not they conflict with each other. 

In games like Rorona, you actually can have a raw material with internally conflicting properties on them existing, since only one level of reaction can take place (so you can combine two properties to make a "Bad Quality" property exist on a material at the same time that you have already passed a "Quality" property onto the same good, even though in the next reaction that item goes through, they will conflict and cancel).  It depends on how Toady wants to handle such things, however.

Nullifying properties also exist as a way of preventing too many properties from ever existing on the same material.

And thanks for taking the time to read and respond, guys.

[NW_Kohaku]

OK, happy graphics time!

Gather 'round, children, and I'll tell you the story of when dwarves wanted to create a more virulent poison to dip their crossbow bolts into. 

Spoiler: large images (click to show/hide)

The basic gist of this reaction is that you are making a "potion" or "fluid" reaction.  The game will let you, basically, take a container, some sort of fluid in the container, and then mix in some sort of soluble solid organic material in it to create a potion out of the fluid. 

Or, in other words:
[FLUID] + [ORGANIC_SOLID] = [FLUID]

Yes, this means it's OK to take the same fluid, and make another potion out of it by putting some more organic solid materials in the product fluids.  That's the point - you can continually refine products by continually adding more and more materials that you mix together to get different results, and build towards a complex end-product.

Now, here's where we start. 


We have a poison that we extracted from some poisonous animal, like a platypus or something.  It's a fluid in a bottle.  It's a minor injected damage poison (meaning it takes effect when a poisoned weapon or body part scratches the victim) which causes minor necrosis.  So, we can look at this, and say it has the following tags:


[MATERIAL TYPE: CREATURE EXTRACT FLUID]
[ALCHEMICAL PROPERTY: GENERIC MINOR INJECTED NECROSIS POISON]
[ALCHEMICAL PROPERTY: EW! IT CAME FROM A CREEPY CRAWLY VENOM SACK]

Now, we have a lot of this poison, but we want to do something much nastier with it than just give some minor necrosis when we put it on our crossbow bolts and shoot it at people, so we want to alchemically change the nature of this poison by doing some reactions.

Now, our cooks in our kitchens have accidentally happened to stumble upon another reaction on their own:


Rock Nut Butter
It has the following tokens:
[MATERIAL TYPE: OIL]
[MATERIAL TYPE: ORGANIC PLANT]
[MATERIAL TYPE: FOOD]
[ALCHEMICAL PROPERTY: FATTY]
[ALCHEMICAL PROPERTY: SALTY]
[ALCHEMICAL PROPERTY: CREAMY]

And cooking it with the following:


Fluffy Wambler Pudge
It has the following tokens:
[MATERIAL TYPE: ORGANIC SOLID]
[MATERIAL TYPE: FOOD]
[ALCHEMICAL PROPERTY: HIGH CHOLESTEROL]
[ALCHEMICAL PROPERTY: ULTRA FATTY]
[ALCHEMICAL PROPERTY: STUMBLY-BUMBLY]

It creates the following reaction:

+ =
Rock Nut Butter + Fluffy Wambler Pudge = Deep Fried Nutter Butter

When this reaction takes place, invisibly, [FATTY] + [UTLRA FATTY] + [HIGH CHOLESTEROL] + [SALTY] = [HEART ATTACK SPECIAL]

So, when we have the final product:

Deep Fried Nutter Butter
Has the following tokens:
[MATERIAL TYPE: ORGANIC SOLID]
[MATERIAL TYPE: FOOD] (rather dubiously)
[ALCHEMICAL PROPERTY: CREAMY]
[ALCHEMICAL PROPERTY: STUMBLY-BUMBLY]
[ALCHEMICAL PROPERTY: HEART ATTACK SPECIAL]

So, now that we have fought away all the redneck dwarves that want to actually ingest our new poison ingredient, we can finally start creating the new poison we want when we have whipped up a few batches of Deep Fried Nutter Butter.

So, we have our FLUID + ORGANIC SOLID = FLUID formula all over again:
+=
Minor Injected Poison + Deep Friend Nutter Butter = Chest Burster Injected Poison

Where, let's say, "CREAMY" and the "EW IT CAME FROM A CREEPY-CRAWLY VENOM SACK" cancelled out. 

Then, however, we get the reaction we really want - The "HEART ATTACK SPECIAL" property mixes with "GENERIC MINOR INJECTED NECROSIS POISON" to create "HEART EXPLOSION INJECTED POISON"

So, properties look like this:

Chest Burster Injected Poison
[MATERIAL TYPE: CREATURE EXTRACT FLUID]
[ALCHEMICAL PROPERTY: HEART EXPLOSION INJECTED POISON]
[ALCHEMICAL PROPERTY: STUMBLY-BUMBLY]

(Note that the Stumbly-Bumbly property from the Fluffy Wambler made it through the whole process without ever being cancelled out.  Maybe that would be important, maybe it's a drawback for the sort of poison we want to create, so we'd want to go through the process again to mix in a material with a property that could cancel out the STUMBLY-BUMBLY.) 

Now, we have a poison that, when we instruct our marksdwarves to dip our bolts into the poison and shoot at specific targets, the poison causes their hearts to explode out of their chests, rather than a more mundane poison effect. 

And that's how dwarves learned to stop worrying and love eating Deep Fried Nutter Butter Alchemy!

[tsen]

One possible issue is that a token based materials interaction system also needs to be able to handle "real" chemistry. So there would need to be two layers, one "realistic" layer which simulates real-world materials properties, and then a second layer which handles the "fantastical" elements. Then of course some logic to allow them to coexist.

For example, you might have a bed made from "dream oak" that provides a restfulness bonus, but if the dwarf whose bed it has personality traits which make him or her lean heavily toward a spartan lifestyle, if the bed itself is ultra-soft it might actually *decrease* the apparent restfulness and qualify modifier. So there is both a "realistic" component and a "fantastical" component.

Also to properly simulate things like the seelie fey's weakness to "cold iron" we would need some way to track the essential nature of an object that is unrelated to its "fantastical" (or alchemically, read "magically") based properties.

So for example, there might be a world-gen option for chemistry that allows things to be comprised of some mixture of the four cardinal elements scaling up to something like the real-world periodic table. It could be procedurally generated and track the "component" and "component proportion" which would be the "realistic" layer.

If you forged a sword from iron it might save item-specific data
[MATERIAL:1:10000]
...where "1" was the signifier for iron and 10000 was the proportion as a percentage out to two decimal places.

Melting that sword down and resmelting it as steel might result in
[MATERIAL:1:9800]
[MATERIAL:2:150]
[MATERIAL:3:50]
...where 1 is iron, 2 is carbon and 3 is say, manganese.

I'm not sure how precise we'd want to get, as trying to track alloy amounts is somewhat troublesome. They DO cause noticable differences in materials properties, so they could certainly be handled in your TOKEN1+TOKEN2 = TOKEN3 interaction framework, and interactions could also be procedurally generated for things like metal that's had too much carbon added so the alloy is inferior to normal steel. That would be quite complex though, and while the inner metallurgist in all of us might squee at the concept, probably insanely complex to implement a procedural generator for if we wanted it to make any sense.

Returning to the original point, this system could be adapted to keep track of the unique, physical components, which could also be used via the existing framework behind syndromes (i.e. when hit by something, it checks for the right materials or the right materials in the right proportions, so a bismuth bronze sword could be differentiated from a bronze one.)

Now if, say, a particular forgotten beast required a "celestial bronze" weapon, then the second layer is what would be used to magically or alchemically give a bronze weapon its "celestialness"

So then the syndrome could check for:
Copper 80-95%
Tin / Zinc 5+%
"Celestialness" Y/N

...before it applied the additional damage effect. Which neatly allows both fantastical transmutations (the material specificity token gets completely changed, so lead + unobtanium + process = gold) AND real world applications like metal alloying (unique material component amounts tracked, properties go through token based merge process) as well as a combination of both, without either of them losing their uniqueness or value.

[NW_Kohaku]

One possible issue is that a token based materials interaction system also needs to be able to handle "real" chemistry. So there would need to be two layers, one "realistic" layer which simulates real-world materials properties, and then a second layer which handles the "fantastical" elements. Then of course some logic to allow them to coexist.

The thing is, that's why I refer to it as an alchemical reaction web, not a chemical one.

There is no difference between science and magic in this system, the lines are pretty much blurred.  When you have a Nethercap, which consistently produces an aura of 0 degree Celcius around it, you could "scientifically" make a refrigerator by simply making a box out of nethercap wood. 

Alchemically combining nethercap wood with other materials, so long as there is no reaction that nullifies the ice-cold property, would always result in other ice-cold materials. 

The point is that you can mod the system if you want, and it would be flexible enough to have a purely "science" type of chemistry if you so chose, but at the same time, you could have a system where everything worked by having to spread flower petals by the light of specifically only the full moon on a moonstone altar before the given reaction you want could take place, and you had a fully "magical" type of alchemy.

If you forged a sword from iron it might save item-specific data
[MATERIAL:1:10000]
...where "1" was the signifier for iron and 10000 was the proportion as a percentage out to two decimal places.

Melting that sword down and resmelting it as steel might result in
[MATERIAL:1:9800]
[MATERIAL:2:150]
[MATERIAL:3:50]
...where 1 is iron, 2 is carbon and 3 is say, manganese.

I'm not sure how precise we'd want to get, as trying to track alloy amounts is somewhat troublesome. They DO cause noticable differences in materials properties, so they could certainly be handled in your TOKEN1+TOKEN2 = TOKEN3 interaction framework, and interactions could also be procedurally generated for things like metal that's had too much carbon added so the alloy is inferior to normal steel. That would be quite complex though, and while the inner metallurgist in all of us might squee at the concept, probably insanely complex to implement a procedural generator for if we wanted it to make any sense.

That's not really how the system I was talking about would handle it, however. 

A "steel with too much carbon" sort of reaction would basically be the set of tokens that represents steel, and then another token that degrades its performance by lowering its TENSILE FRACTURE or otherwise changing its material properties to make it less ideal than steel. 

In order to break it back down into carbon, manganese, and iron, you'd have to find some sort of chemical reaction that would be able to take those materials out of the metal.

Returning to the original point, this system could be adapted to keep track of the unique, physical components, which could also be used via the existing framework behind syndromes (i.e. when hit by something, it checks for the right materials or the right materials in the right proportions, so a bismuth bronze sword could be differentiated from a bronze one.)

Now if, say, a particular forgotten beast required a "celestial bronze" weapon, then the second layer is what would be used to magically or alchemically give a bronze weapon its "celestialness"

So then the syndrome could check for:
Copper 80-95%
Tin / Zinc 5+%
"Celestialness" Y/N

Not quite, as again, bronze would simply be a token (or set of tokens), and "Celestialness" would also be a token (and maybe celestial bronze itself are not even separate tokens).

Part of the point is that the game would only need to check for specific tokens, however, so the "bronze" part might not need to matter - only celestial weapons harm the creature, but a "Celestial Steel" might be just as good as a celestial bronze, as well as being just plain steel in general.  Likewise, you could potentially get "Celestial Cold Iron" and have materials that count against multiple vulnerabilities, so that you don't need to carry around 28 different spears for each flavor of werecritter.

[tsen]

Hrm, ok let me attempt to explain differently. I understand fully what you are suggesting and would like to alter your suggestion slightly to be friendlier to procedurally generated worlds. Rewrite #5 so far!

The reason Atelier Rorona's crafting system seems so expansive is that it treats all materials as identical except for a single 'type' tag to categorize, then sub-tags to give stackable properties. While in a game like that it is advantageous, it ends up being a problem in a game like DF, and I will attempt to explain why.

Problem #1: Scalability.
Atelier Rorona is a highly simplified simulation of a single, specific, static world. So their system works by having a large amount of pre-programmed token interactions. The game doesn't 'know' that a flower has a scent, it looks at the item's tag and randomly generates properties from a list populated by hooks that are scripted into the item's 'type' tag.

It is all very well and good to say that the system is flexible enough to handle a realistic chemistry via modding, but that isn't my point. My point is that the system needs to be able to do total realism (or as close a facsimile as is reasonable) AND total fantasy. Not only this, but a truly robust system needs to be able to do both extremes at the same time--and not only that, but able to handle virtually any procedurally generated variant in between.

If the system relies purely on modding by players to handle more than a single way of doing things, it is no longer a piece of a "fantasy world generator" and is now a system that simulates a single world and only that world, until someone decides to spend months of their life modding in tens of thousands of new materials, tokens, reactions, and property interaction rules.

Problem #2: Essential Nature.
If you look into folklore, you'll find an awful lot of supernatural critters or effects which must be dealt with by a specific thing. Whether it's cold iron, garlic, wooden stakes, salt, or silver, the point is that there is some ineffable quality to that material that causes a specific result. In a system that respects only token combinations and does not pay any attention to essential nature (i.e. composition) this is almost impossible.

Not quite, as again, bronze would simply be a token (or set of tokens), and "Celestialness" would also be a token (and maybe celestial bronze itself are not even separate tokens).

Part of the point is that the game would only need to check for specific tokens, however, so the "bronze" part might not need to matter - only celestial weapons harm the creature, but a "Celestial Steel" might be just as good as a celestial bronze, as well as being just plain steel in general.  Likewise, you could potentially get "Celestial Cold Iron" and have materials that count against multiple vulnerabilities, so that you don't need to carry around 28 different spears for each flavor of werecritter.

...you seem to be completely missing my point and attempting to answer it with reductive reasoning. I don't grasp how the elaboration is different. I will be more explicit:

Let us say that there is an internal ranking of power levels, and say, a demigod of some sort requires three, rather than one 'special things' to be harmed. The game randomly selects bronze, then looks at the creature's sphere and selects something whose sphere(s) are generally in opposition. So Oogle Boogle, Demigod of Darkness and Mouldy Bread, must be attacked by a bronze edged weapon with the 'celestial' modifier. Since the modifier is based on sphere, the possibility of "sphere"-ness can be a property of objects. So you can now make you know, a gold ring engraved with runes... That happens to also have the "evil" sphere property which might give it various related properties. (One Ring reference anyone?)

We have all sorts of routes we can take to arrive at that:
1. One of the component materials is inherently "celestial"
2. The "celestial" property is the result of another interaction, say dipping it in holy water.
3. The property of "celestialness" might be localized to an area of production, so items made in that area inherit the "celestialness" token by virtue of the process of their creation without needing other inputs.

Results:
1. Information in the form of legends becomes more valuable.
2. Rules governing what is likely to harm various supernatural critters are logical for that specific world.
3. It will tend to add hooks--if the creatures of darkness in the world local to a specific region are weak to silver, the fighting implements/standard loadouts of civs in that area will tend to include silver more often than not, and also provide a hook into economy. If say, horse hoof is what the nasties are weak to, the market value of horse hooves in that area will be higher than in another area. If a specific type of plant provides the antidote to a syndrome, more foodstuffs will probably have that plant in them, assuming it's not toxic. Etc...

The point is that differentiating between substrate and additive properties has benefits outside of alchemy. Food for one species can be poisonous to another to varying degrees due to the properties inherent in the substrates, as well as gain properties unrelated to the actual materials; additionally, what we might consider "fantastical" materials i.e. alchemic silver or orichalcum, can exist which have properties of both expressed accurately in a way that hooks from a huge variety of subsystems internal to the game can access the information in a robust and useful way.

TL;DR:

All I'm suggesting is an even MORE robust version of the system you're proposing that could do all the same things, and a lot more, only do them in a way which is more accessible to the game's internal workings in terms of procedural generation and emergent behavior based on in-game factors rather than explicitly modded-in information that requires a player to micromanage dwarves to access.

I merely gave an example as to what a "set of tokens that represents steel" might look like, based on what steel actually is.   There isn't any need to mod in a token specifically devoted to "This is STEEL -3" if you let the way the data structures interact represent the actual thing more accurately to begin with.

Letting alchemy take the form of a reductive representation of pseudo-magical material transformation is doing the game and ourselves a disservice--we want the little inhabitants of the worlds we create and watch over to DO stuff, not only when we tell them or force them to but also on their own in response to their own issues.

A robust system with realistic treatment of substrate components and their properties that ALSO integrates everything from psueodmagical alchemy to direct manifestation of magic into physical objects is better than one that only lets you stack up "+1 Speed" modifiers until you get bored or run out of money.

Even TL;DR-er TL;DR

I like what you are thinking, but I think that it needs to be taken even farther and made even more robust so it can handle anything you can throw at it.

[NW_Kohaku]

Problem #1: Scalability.
Atelier Rorona is a highly simplified simulation of a single, specific, static world. So their system works by having a large amount of pre-programmed token interactions. The game doesn't 'know' that a flower has a scent, it looks at the item's tag and randomly generates properties from a list populated by hooks that are scripted into the item's 'type' tag.

It is all very well and good to say that the system is flexible enough to handle a realistic chemistry via modding, but that isn't my point. My point is that the system needs to be able to do total realism (or as close a facsimile as is reasonable) AND total fantasy. Not only this, but a truly robust system needs to be able to do both extremes at the same time--and not only that, but able to handle virtually any procedurally generated variant in between.

If the system relies purely on modding by players to handle more than a single way of doing things, it is no longer a piece of a "fantasy world generator" and is now a system that simulates a single world and only that world, until someone decides to spend months of their life modding in tens of thousands of new materials, tokens, reactions, and property interaction rules.

That is still scalable.  The argument here, as far as I can tell, is simply that you think this will take too long to mod. 

If you want to talk about a way to make modding easier without losing functionality, though, go right ahead.

Part of what I'd like to do with the procedural nature of the alchemical webs, however, is to simply let players set guidelines for how that procedural web is built, and let the game (or some third-party raw scrambler) build that web for them.  That way, your "hard science" mod could still be possible, and some "mostly realistic, but with randomized chemical properties of different materials" could be produced, as well.

Problem #2: Essential Nature.
If you look into folklore, you'll find an awful lot of supernatural critters or effects which must be dealt with by a specific thing. Whether it's cold iron, garlic, wooden stakes, salt, or silver, the point is that there is some ineffable quality to that material that causes a specific result. In a system that respects only token combinations and does not pay any attention to essential nature (i.e. composition) this is almost impossible.

Actually, what I'm saying is that token combinations are their essential nature. 

As in, bronze is just a token combination, so if you want to look for a composition of bronze, you just look for the bronze token combination. 

It's also part of the specific point of this system that the game doesn't reduce you to only using one incredibly specific material from one incredibly specific source, screw folkloric tradition.  It's a problem if the game randomly rolls up something like "This creature is only vulnerable to weapons made of sperm whale intestines" after the last sperm whale went extinct in the year 52, or "horse shells", or "wagon wood", or other problems like we had with impossible mandates.  The point is that if it is always at least possible to alchemically derive some token out of some other set of objects, so a "sperm whale intestine spear" isn't the only way to kill a creature. 

By that token, part of the point is that you can create bronze by mixing copper and tin bars in a smelter, or you could derive the same tokens as bronze through some godawful unnecessarily complex series of reactions involving some quartzite, twenty rutile, some gold, half a forest of wood, and an entire field's worth of rutabagas, and wind up having the token combination that produces "bronze", and therefore, you will have alchemically produced something with the essential nature of bronze.

[tsen]

Not talking about making modding easier though... I'm talking about making it easier for the game to handle it and have civs or individual entities make use of 'alchemy' in practical ways rather than making it something that only players have meta-game access to.

Otherwise we seem to be in general agreement, except that I am being more explicit about token formatting.

[NW_Kohaku]

Not talking about making modding easier though... I'm talking about making it easier for the game to handle it and have civs or individual entities make use of 'alchemy' in practical ways rather than making it something that only players have meta-game access to.

Otherwise we seem to be in general agreement, except that I am being more explicit about token formatting.

Well, the way in which civ knowledge has been added recently by Toady lends itself well to the notion that civs can procedurally start gaining some alchemical knowledge of its local flora, fauna, and minerals.  I suppose I could write another section on it, but at the same time, I think it would go without saying. 

It would provide a quasi "tech-tree" style of civilization advancement for civs to gain a foothold and move around the alchemical web based upon the ways in which they can mix what materials they have in some worldgen experimentation the way that they should now experiment on training different exotic animals. 

That civs should focus their development on items that are most beneficial to themselves would obviously be a great idea... and also something that I think is obvious enough Toady would want to do it, anyway.

[jseah]

Perhaps we could write the master reaction types?

Eg.
Reaction: Dip
[Solid object] + [Liquid any][volume > multiplier x surface area] = [Solid object] + [Liquid any]
Conditions -
[Container] containing [Liquid any]
Interactions -
[Liquid any][Tag class: X] copies to [Solid object]
[Solid object][Tag class: Y] copies to [Liquid any]

Reaction: Leeching
[Liquid any] = [Liquid any]
Conditions -
[Container] containing [Liquid any]
Interactions -
[Liquid any][Tag class: X] copies to [Container]
[Container][Tag class: Y] copies to [Liquid any]

Reaction: Melt
[Solid object] = [Liquid = melted object]
Conditions -
Temperature > melting point
[Container] containing [nothing]
Interactions -
Check [Solid object][Tag class: Temperature sensitive]