[CF-Devel] Materials (was FW: DIAMONDS)
crossfire-devel-admin at archives.real-time.com
crossfire-devel-admin at archives.real-time.com
Mon Apr 21 22:58:59 CDT 2003
Mark Wedel wrote:
>
Just a note, I think you are confused by what I mean when I say
>
'artifacts'.
>
>
[..]
>
In all my discussion in this thread about 'artifacts', I'm talking
>
about random artifacts above.
>
Nope I got the random artifacts thing. The artifacts file will generate
random variations (good and bad) of objects, but this occurs when the
item is created and is well... random - if I wanted to place a dagger of
Gnarg I couldn't. This isn't good for me if I want I do think I see the
real issue here however...
>
I think we're talking past each other right now. As the code stands
>
now, the material bonus is universal. yew wood gives a +2 damage
>
bonus for any weapon that gets made out of it, whether that weapon is
>
a bow, club, spear, axe, etc. To me, that is wrong.
>
Another case - lead has a -2 damage penalty. That is reasonable to
>
see in the case of things like swords - lead can't keep a sharp edge.
>
But for things like sling bullets (if they existed), or hammers, lead
>
should probably cause more damage (heavier weight = more damage in
>
those cases). As the code stands now, there is no way to make that
>
distinction - it just says that anything made of lead has a -2 damage
>
bonus.
>
Yes, this is a problem. A better example still is a metal bow. This is
perhaps the crux of the entire issue. Is this what you were speaking of
all this time? You can't do these bonuses/penalties universally, you
have to have arbirtary lists because the distinctions are arbitrary, so
you *have* to use the artifact file for this. _But_ thinking on this
point, I believe that it doesn't mean you should use the artifact file
for assigning materials to objects, it means that materials shouldn't
contain this type of information.
Weight, value, saving throws and other universal modifiers should be
assigned based on the material, but the artifact file should match
materials to objects to produce bonuses or penalties (so for swords some
materials would be benificial, but the same materials would be
detrimental to bows.)
This may make no sense to but consider this. No one is generally going
to make a map and place a bow with material type 'metal' or 'iron', but
a iron bow could exist, as a quest object (in which case the map maker
placed it and perhaps magicked it right up), or as a byproduct of a
spell or ability or alchemical transformation, or as an object (could be
a model or a statue part?). You can see the problem with accounting for
such things as a metal bow or ruby slippers using the artifacts file and
how the way that Tim did it with mateial type is much more managable
for item composition. This is why I first disliked the material
changes, I thought It was similar to the artifact file where he had made
lists of what item was made of what - too many limits and it overrides
the map maker. This was already being done with the daggers of gnarg or
cursed items. What he actually did however is expand the material
system in the arches, and by adding saving throw, weight and value
modifiers made it meaningful (more than a just a name) to put objects
like a ruby crown (as opposed to a 'stone material crown' called ruby
and manually modified to add value and other properties if you had the
patience) or silver dagger or lead pipe into the game. Perhaps as a
side effect to this because of the way it was implemented there is a
random component as well so that there isn't a requirement to make an
arch for each maiterial combination (which you would have to do to
autogenerate items), but merely an arch for each material class (I can
live with having a stone axe arch and a steel axe arch...)
>
I actually think this is a pretty good idea. The only thing currently
>
in the 'materials' file that won't transfer is the saving throw
>
values. So you'd now need to copy in saving throws into the object
>
structure, or find some other clever way to handle that.
>
>
As a note, if materials were done in this way, rather than the object
>
containing the material, it'd probably just be easier to have an
>
'object *material' pointer. However, you'd actually need to use
>
something like objectlink pointer if you plan to have more than one
>
material in an object.
Well either in a list or as an arch it is the same, the difference being
where and how it is stored- I dont' know about pointers. I wasn't
thinking of using these particular arches on a map if that is what you
are saying, just standardizing 'objects' in one place. If you wanted to
actually see some gold on a map it would have to be put into a material
field in an item (an ore arch, or a ingot arch, or a nugget arch...)
Just like recipies and spells would be good in the arches too.
Perhaps it would be a good way to fill out or otherwise work out other
issues with the arch fields. I don't have see a real problem with hp
meaning x coord in a exit type and hit point in a creature, so I don't
mind if it is a property in a material as well, but I do get the idea
that there are other issues with the arches that are causing some headaches.
>>
>>
This is where I was imagining inheritance played a part. General
>>
class characteristics inherited by the specific materials so you
>>
don't need to configure every little setting (but you could...).
>>
Note imagine is the operative word since this was speculation on my
>>
part.
>
>
>
I'm not sure how this work.
>
>
At one level, I could see something like tree >> spear >> club >>
>
arrow. IS that what your talking about?
No, I meant wood>>pine or wood>>oak or metal>>iron where wood passes
properties to pine which can be modified (like basic saving throw
information, burnability) or where metal passes properties to iron (like
basic saving throw info, malability, melting)
Material would have no direct relation to the platonic spear, club or
arrow until these objects are created. This came from an idea in the
Crossfire TODO list. Realistically however, aside from some theoretical
(and as yet coded) properties like burning, malability and melting (so
you can add metals, but not wood, but you can burn wood and not
metals...) it is probably just as effective to have a list as it is
now. I realize that Tim was working within the existing material code,
but I think that he hit upon a good model for material in general even
if there weren't already metal, wood, glass...
>
But a little trickier - you somehow have to know that the fire
>
elemental can heat that armor. Is this a spell like ability, or
>
happens if you just stand next to it (does anything that attack with
>
fire do this?) And how often do you make this check. It can certainly
>
be done, but I'd not consider this an easy change.
I was thinking it as an example of an ability or spell that could use
material. Think of a spell/ability that worked like a fireball that did
an amount of damage (dropping off each square removed from the
caster/creature) for each 100g of metal worn. You could call it Nova or
ColdWave - it would work the same. It would target more the armoured
fellows (not a bad thing). There are probably enough material
orientated spell ideas to make a class of magic out of (of course since
these are all imaginary uncoded spells you could say the same thing
about magic based on a catmotif as well - animated cat o nine tails,
nine lives, claw of the magi, furball...)
>
Well, it would be nice to somehow denote what happens to the object
>
when destroyed. But this gets tricky. While wood ash makes sense if
>
the object is incinerated, if the object is destroyed by acid, you
>
shouldn't get that. However, to list all the combinations is probably
>
not possible.
>
>
But therefore denoting what this object turns into could be
>
interesting. As well as perhaps what portion survives (eg, wood ->
>
ash, you'd lose a lot of mass, presuming you can collect all that
>
ash. metal -> melted metal, the mass would be near the same, its just
>
now in a less useful form (that iron sword turned into a 'melted mass
>
of iron'.)[..]
>
We'll ignore the issue that if you melt tin and copper, you should
>
really get a pool of bronze - trying to figure out those mappings is
>
another can of worms not worth dealing with.
Yes. Another thing is that hopefully there will not be so many
materials that you are talking about making alloys. There is no problem
just *naming* something copper or bronze - they are close enough in game
play that ther need be no physical distinction. For materials to be
useful they should be different enough. That being said, there will be
a greater representation of things such as precious metals and gem
stones for atmospheric reasons, but I really don't even see the need for
say iron _and_ steel, iron would be fine.
>
Ok. Presumably, the random map/herb code could also make
>
adjustments. Eg, growing conditions say this is good for oak, so let
>
me set that material name. Over here, growing conditions are good for
>
pine.
>
>
This is trickier for the mountain spaces - presumably you should be
>
able to mine some of the metals as well as some of the stones.
>
However, weather doesn't really play into that - I guess some small
>
number of mountains could get turned into quarries/mines. Ideally,
>
over time, you might want thse to move around (eg, just don't always
>
go to X to mine mithril).'
I'm pretty sure you can use the herb code to place mines in mountains as
well.
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
More information about the crossfire
mailing list