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

[crossfire-devel-admin at archives.real-time.com]

And Two:

Why working over the materials system is good for game play:

Cast aside all preconceptions (including the material code which was 
recently committed which is being discussed) and consider:

1) There are no diamonds, there is stone(64). There is no silver, there 
is iron(2). There is no lead, there is soft_metal(1024).

2) Materials are found in all pickable objects, not just weapons and 
armour ('No material' is considered a material).

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).

4) Most of the inventory checkers and other item handling code, with the 
exception of parts dealing with the material type bitmask (primarily 
used for item saving throws against destruction...) when chacking for 
material has to work by item name, As far as I can tell, determining the 
difference between silver and gold or ruby and emerald is based on 
pattern matching on the name.

So what would a good material system look like?

1) The material field would be expanded to support a larger array of 
materials. Further, these would be referenced by name, not by a bit number.

This by itself would justify the change since it would be possible to 
use this value in code (the server code or a scripting language) and it 
would make things much cleaner. All discussion of recipies, construction 
and deconstruction, harvesting, or transmutation are merely a *wee* 
slice of this. It could also be used for item checking, for spells, for 
weapon bonuses or penalties... what ever someone can think of coding.
It would make the designer's life much easier and help to standardize 
such things as value and weight modifiers without limiting design (You 
can still change the fields after all, but you don't have to guess how 
much additional value or weight would be reasonable for golden 
underpants unless you want to).

2) The materials would be modular, not loaded from a header file. It 
would be nice if they were actually carried in the archs and not a 
server side file for the convienence of designers (so you'd only need to 
run 'make collect'), but not necessary. They should be in a very 
readable format like the arches in any case.

3) Material properties shouldn't contain combat modifiers or other 
values which are not universally applicable to pickable items. The 
system should work equally for a gold or ruby figurine as a gold or ruby 
helmet helmet.
Combat modifiers arising from applying 'oak' to a club would not apply 
to applying 'oak' to a bow or a spear and thus have material bonuses to 
combat must be maintained manually based on human judgement. 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.
So material properties would be primarily saving throws, weight and 
value modifiers and other non-item specific values (perhaps things like: 
is_magnetic, is_maleable, is_burnable...)

4) There should be an effort to make arches more material generic to 
streamline the system. Following that there should be a method of 
assinging a random type of material from a range to avoid need for the 
creation of a large number of arches.
Something like the treasure file or artifacts system should allow for 
'random' material type in an object'.

5) Although it should be simple to add new materials, it should be done 
with the same reservation of adding other metatypes (spells, 
abilities...). Materials which have very similar game properties (pine 
and spruce, granite and marble) can still be handled by changing the 
item name. If there is a reason to actually add the material. This 
should be handled in the same way as everything else dealing with arches.

6) There should be a simple way to manage items composed of multiple 
materials (multiple entries in the materials field to replace the bit 
addition mechanism).

There is little here that goes against the material changes made for 1.5 
specifically, but there is a component of reworking some things 
(especially uniting the material and materialname fields and seperating 
action bonuses from material properties). It is almost what existed with 
the originally with the bit field but expanded and moved out of the 
header files.

How will this improve game play without considering the contraversial 
topics of transmutation or item construction and deconstruction or 
unbalancing an already unbalanced economy?

-The elven city of Nimora will not allow entry to characters carrying 
any iron.

-I've already mentioned spells or abilities which target specific 
materials. This is a lot of ground to cover. Arch lightning, burst wood

-To create a golden statue of youself please drop 1000lb of gold.

-"I believe I will place a ruby helmet in the chest." <drops helmet 
arch>...<sets material to ruby>...

-CFPython.SetMaterial(), CFPython.IsMaterial(), CFPythonGetMaterial()

-The undead and their worshippers can be identified as they cannot bear 
the touch of silver.

All these would center on writing code that *checked* the material 
field, of course I made no mention of things you could do writing code 
that *changed* the material field. You can probably do some of these 
things now, but could you do it as cleanly?




_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel