[CF-Devel] Materials (was FW: DIAMONDS)

Sat Apr 26 11:24:40 CDT 2003

>

     Yes, I can agree with what you said. I didn't mean to argue against

     >

     the new material system actually - that's quite fine and I do see

     >

     the benefits.

     >

     Maybe I'm not fully satisfied with the current implementation,

     >

     but that's not a big issue so let's cast it aside.

     >

     No explanation necessary.  It's a proper question to ask what this would 
do for the game.  Since I brought it up, it is my duty to attempt to 
argue why something should be done differently rather than your duty to 
justify not doing it.

>

     >

     What I am primarily concerned about are the effects caused by item

     >

     deconstruction and especially transmutation (e.g. lead -> gold).

     >

     >

     Now, you got me with one particular argument

     >

     pro item-deconstruction:

     >

     >

     >

     >>

     3) Part of creating an object on a map consists of picking a

     >>

     material, assigning an arbirtary value, assigning an arbirtary

     >>

     weight and putting in a name. There is no consistancy between map

     >>

     makers so for example if I were to make a gold bar:

     >>

     I would make it material 1024, guess it has a value of 600 (?), say

     >>

     it has a weight of 5000 and call it 'gold bar'

     >>

     You would make a silver bar, assign it material 2 (it holds an edge?), 

     >>

     assign a value of 900 (?) say it has a weight of 300 and call it

     >>

     silver ingot.

     >>

     The map maker is expected to understand the values of these fields even 

     >>

     though the values are heavily modified in the game (well value anyway).

     >>

     Further to this weapon and armour items have more arbitrary fields to 

     >>

     modify their effectiveness and many standard weapon and armour items are 

     >>

     subject to further modification when called into existance (artifact

     >>

     code).

     >>

     >>

     >

     >

     If I understand it correctly, you mainly say the current "value"-

     >

     system is bad and item value should better be based on materials?

     >

     Not exactly, what I am saying is that if the material component of an 
item is tied to material + weight, there is *less* to mess up when 
assigning values.  It also speaks to standardizing arches a little bit 
(especially if there is a way to specify a random list of materials as a 
material or otherwise invoke variations on an arch on a map without 
requiring a arch as a template) since you could make more use of generic 
arches (chainmail rather than mithril mail, iron mail - or nugget rather 
than gold nugget, iron nugget, silver nugget.)  It's more Platonic.  
This doesn't really change how value works however, I don't think there 
is a need to mess with the value system itself.

>

     That's a good point IMO. Of course it's hard to balance, but maybe

     >

     easier to balance than the current value system.

     >

     >

     With item-deconstruction, any item has two values:

     >

     1. The item value (= value for selling the item "as is").

     >

     2. The material value (= value after de-constructing the item).

     >

     >

     >

     >>

     Yes there is also a component of value that is based on the

     >>

     'quality' of an object and not on the material alone, but this

     >>

     is in addition to the material value modifiers and thus there is

     >>

     no reason value couldn't also modified at this point in an

     >>

     external system (artifacts file or similar set of lists or

     >>

     whatever) as well.

     >>

     >>

     >

     >

     The item value should always be higher than the

     >

     material value, except for raw materials and coins/gems for

     >

     which both values are identical.

     >

     Yes, but actually the intrinsic value should be stated while the 
material and weight would comprise the rest of the value.
I am not going to speak to coinage at this time since that is a special 
case and there is special code for money, but otherwise yes, an arch 
like an ingot would have a low or zero value  prior to applying the 
material value while an arch like flawless diamond or worked metal 
object would have a high value prior to the material value.

>

     Assuming that mapmakers are also playing crossfire, it is

     >

     likely that they will get a feel for material values.

     >

     They might have an idea what 1 kg of gold is worth,

     >

     much rather than knowing what "value 1500" means.

     >

     >

     I'm not sure what you envisioned exactly, but I can

     >

     see two ways to go which seem interesting:

     >

     >

     a) Dump "value" fields in the arches, and auto-calculate

     >

        the item value in the server by summing up bonuses

     >

        like resistances/damage etc.

     >

        Item value is then material value + sum of bonuses.

     >

     >

     b) Leave "value" fields in the arches, calculate:

     >

        Item value = material value + "value" from the arch

     >

     >

I thought that I was being clearer than that... The second one is the 
idea I was intending to portray and I believe the way it works in Tim's 
code. (or should work if the thing Mark mentioned about why it doesn't 
is ironed out).
Mapmakers can of course change the value field and will do so based on 
experience, but the portion of value that comes from a material's 
intrinsic value (if the item was broken down) can be applied 
automatically.  You would still have a base value in the arch, but it 
would save the fiddling required when you sub class the arch on a map to 
make a ruby dagger as opposed to a iron one.  Also it will standardize 
values somewhat since the modification to the value I would have made in 
the above case is not likely the same as the one you would have made on 
a different map.  This would not prevent you at all from also modifying 
the value field further however if you felt it should be a particularily 
nice ruby dagger.
As for adding value by other things like bonuses and such - I never 
thought much about it.  I mentioned the materials since it is already 
mostly implemented.

>

     >

     So, after all, I can see benefits in item-deconstruction

     >

     too. However, I think it is very important to plan and

     >

     implement it carefully.

     >

     If done wrong it could just as well mess up our economy

     >

     worse than it is now.

     >

     >

     To talk about material transmutation: I still think

     >

     we should not do it. If there are ways to convert

     >

     lead into gold - no matter what or how - that is definitly

     >

     going to screw economy.

     >

     >

Well if there is a marerials field to be manipulated I think you will 
see transmutation occuring and I believe this is a good thing.
Now as to transmuting lead to gold specifically - yes this sort of thing 
can't be let loose without great care, but transmutation equally applies 
to changing between all the other materials too,  most of which would 
not impact economy or even some that would improve it.  I never had the 
idea that lead to gold should be a street corner thing, (it could 
perhaps be assigned as possible only with a unique item called the 
'philosopher's stone', or perhaps not at all).  But since this covers 
such things as turning iron to tin and diamonds to glass, I think it is 
like throwing the baby out with the bath water to say no transmutation 
unilaterally.  Again I'm not speaking of 'transmutation' the spell or 
any such powerful skill, just a term for when the material field is 
changed using code and an object gains a new set of modifiers (maybe 
properties?)

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

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