Re: CF: Object decay, wear, and repair (Was Re: World Map)

[Mark Wedel <mwedel@scruznet.com>]

David Andrew Michael Noelle wrote:
>     Wouldn't it be *much* better to just implement LOGIC objects so map
> designers don't have to putz around with secret rooms full of monsters and
> buttons and boulders and gates?  A few simple logic objects would simplify
> that whole mess considerably.  Throw in "dice" objects, described in a
> previous thread, and "insert" objects that can be connected to triggers and
> can deploy a creature or produce an item from their inventory (so it doesn't
> have to be an archetype), and a lot of the complicated, unstable
> contraptions currently used for special effects could be replaced with fewer
> objects that are much easier to use.

 I think there are several factors on this.

 One is that if the map maker is a non programmer, they will look for this
creative use of objects to get the job done.  And of course, other people see
that, and do the same thing.

 Some of this may be fixed up by the revised objects in 0.96 (for example, I
recall many maps use a handle/spikes/boulder/button/gate combination so that the
object is activated once and only once (you pull the handle, it raises the
spikes underneath the boulder, which rolls onto the button that now activates,
which now activates the gate/creator/whatever).

 But some of it is a map maker know what they want to do, but no simple object
to do it.  In many cases, some code should have been written to do that.  I
believe several objects and the supporting code was written specifically because
the map maker had an idea in mind, and the current idea in the game did not
support that.

 Perhaps with the CVS, map makers and programmers may work closer together so a
more proper object can be added instead of these creative links.

 That said, some things may require quite a bit more work (getting an item from
an npc inventory to give to the player).


>     no_magic is already a valid flag for walls.  I use it for my walls all
> the time, so I don't need extra "dungeon_magic" objects under them.  I
> haven't worked with crossedit yet, but if someone more familiar with it
> could make "no magic" a switch for walls, it would be much appreciated.
>     Rather than fly_over, how about height?  That would allow some walls to
> be harder to climb or jump over than others.  And instead of just a
> "minable" flag, use the diggable flag and a treasurelist.
>     I was thinking of suggesting a "no teleport" flag for walls, but I
> really don't think there's any difference between that and the no_magic flag
> we already have.  Would no_aethereal be any different?  Is there any case in
> which an aethereal creature should be allowed to pass through a wall that
> blocks a Dimension Door, or vice versa?

 Thats true - no magic currently works.  The idea on that was to make it a bit
more visible or different.  One problem that does happen when map designers
start changing objects too much is difficulty in other designers down the road
to figure out the map.  So by actually having different objects that have
different names or otherwise appear differently in the editor would make it
easier on other maps (or the other would be to have an overlay - ie, show me all
the non magic spaces, show me all the no pass spaces, etc)

 If you can't dimension door, you probalyb should not be able to get past
ethereally and vice versa.  And i think trying to get too refined on the
different attributes may just add extra complication and other errors.

 In terms of wall height - not sure how much it really adds.  If anything, you
coul have a 'climb_chance' field.  If non zero, it is climable, or you could fly
over.  You could use this to take into consideration wall difficulty or
whatever.

 But in reality, it probably does not make a big difference - either you can get
over the wall or you can't.  The difficulty is not likely to make a big
difference, as if the wall is climbable, the player will just try over and over
again until they can do it, and likely with the fast paste nature of crossfire,
that time to do so would not be a big deal.

> 
> >  It really depends on what aspects of the game are interesting.  Very few games
> > deal with equipment deteriotation, and I think the reason is just that - having
> > to deal with constant repairs really isn't that interesting.
> 
>     Good point.  Some people like micromanagement, and some don't.  So, make
> it a server option.

 The problem is that there are lots of other stuff needed to support this.  If
it is a server option that is enabled, yet no maps have the necessary repair
altars, it really doesn't do any good.  Likewise, if a fair number of people
turn it off, when they make up new maps or objects, they may not think about
decomposition of objects, so you quickly get a bunch of objects that don't
decompose or don't decompose at a reasonable rate.

 IMO, for balance issues, configuration options that affect the game play really
need to be removed (there are some options which affect the server, but not
really how the game plays that much).  If you have 40 different possible
combinations (spell speed, object decay, alchemy, gods, etc), it is likely
things will never get balance pretty well.

 Now we could come up with an official configuration, and only worry about
balancing that, but even that is likely to be slower (as some players won't use
that, so there suggestions on balance may not be totally accurrate).  And some
options may have opposite affect on balance.

 For example, if you use stat_loss_on_death, then at least a reasonable supply
of stat potions is needed.  But this could by contrary to other options where
you really don't want a ready supply of those potions.)


> >  2) Allow objects to have non inheritable protections.  For example, that
> > platinum coated sword should be protected/immune to the affects of acid (and
> > thus not rust when hit by acid), but should not give that same protection to the
> > player, as it is not a magical manifestation.  This is actually pretty easy to
> > do - just add a flag which determines if the attributes are inheritable.
> 
>     Choose a different example.  You can make a sword acid proof without
> making the player acid proof by simply setting its material to 256
> (Adamantium).  Only material 2 (Iron) can be rusted.  The materials list is
> currently much too short to differentiate the properties of specific
> metals.  If you want a sword that takes extra damage itself from fire, but
> doesn't make it's user vulnerable to fire, that would be a use for
> non-inheritable attributes.  If you're going to do that, you may as well
> make it a pointer instead of a flag, so the item can have inheritable and
> non-inheritable attributes.

 Thats true.  The acid was a simple example.  OF course, changing the sword to
admantite gives it more than immunity to just acid - I believe it basically
makes it immune to everything.  So your counter example is not perfect.

 But this may not be a big deal.  With the number of artifacts and the like out
there, chances are players won't ever really want an item that is immune to the
effects of acid but nothing else (how many players really care about things like
the lythander clubs or shields of gnarg?  Not many, because you are more likely
to find a better standard variety)



>     I wonder how hard it would be to replace the material bitmask with an
> archetype pointer and replace the various types of materials with archetypes
> of type MATERIAL.  The material archetypes could specify all the various
> properties of objects made from certain common combinations of materials,
> and the more imaginative combinations could be added along the way.  For
> that sword you described above, you could add an archetype for things made
> of "platinum-plated iron and gems", assuming the hilt is encrusted with
> various gems, as one would expect from something plated with platinum.

 I think this is going a bit on overkill/overcomplication.

>     This would allow interesting new materials with imaginative
> descriptions, without eating up very much memory, since all the common
> objects would point to the same few basic combinations, like flesh, wood and
> iron, glass and liquid, iron and crystal, paper, and maybe a handful more.

 IF anything, just add a flag which is basically has the program use the item
message field for the description, and basically have the program not say
anything about the item except maybe its worth.

 In that way, you could have the message describe the item any way you like
without conflict from the program saying it is adamantium.

 In any case, the pointer method still does not do anything for saving throws,
since they are hard coded into the program (ie, iron needs a XXX against acid,
yyy against fire, etc).  So the pointer really doesn't add anything at all to
the possible destruction of the items.

Hwei Sheng TEOH wrote:
> 
> I thought walls had no_magic by default. (Or some other form of magic
> blocking.) I've never been able to teleport through walls created by the
> default wall archetypes in the editor, unless I deliberately changed the
> no_pass flag (for fake walls, secret doors, etc.).

 Walls don't by default have the no magic flag set.  You still can't walk over
them, but you can dimension door through them.  The tricky (and undocumented)
feature of dimension door is being able to specify an exact distance by using
the repeat count.  Otherwise, ddoor will often fail because where it wants to
put you by default is the wall at the far end of the map.

 but if you do something like a 5 then fire the ddoor spell north, you will
teleport exactly 5 spaces north.


> This reminds me... apparently ghosts have some kind of pass_thru_door flag??
> What exactly does this do? So far, I've never seen a ghost pass through any
> kind of door. Is there even code that checks this flag??? (Or is it a leftover
> from an ancient version of CF?)

 Not positive.  But chances are that the logic which actually looks to see if a
monster can reach you stops at the wall.  The function probably doesn't look to
see if that wall actually affects the monster or not, so for all purposes, it is
a flag that doesn't do anything.

 This has been broken for as long as I can remember (broken in that I never
remember seeing ghosts go through walls), and thats a long time.  However, if
fixed, this could create bad situations (the ghost is in the wall and attacks
the player, but the player can't attack back because the wall is there.)  I am
not sure if the code is smart enough to see that there is in fact a ghost there
to attack or not.

 Plus, it hasn't worked in such a long time I have a feeling if it was fixed at
this point, the balance/difficulty of some maps would radically change.


> Also, I've always wondered about how far we should go for realism with this
> equipment destruction thing... Some quests require you to kill a monster in
> order to go further -- mostly implemented by putting the key to the next room
> in the monster's inventory. Now, if keys were made of pretty weak material, an
> unknowing magic user may destroy the key as well as the monster -- and he may
> not even know the key has been destroyed, and spends the rest of the time
> getting upset because the door refuses to open.

 I certainly think some items will have to be immune to the destructive/aging
aspects - items key to completing quests one of them.


> Personally, I think it's silly to NOT have equipment burn when the player gets
> hit by a fireball (so the fire burns only the player, not his backpack nor any
> scrolls he may be carrying? Hmm...). OTOH we have the problem of important
> quest items/clues getting destroyed because you use a fireball on a monster
> carrying the stuff. In "real life", a player would be able to see that the
> monster is holding a scroll that looks like it contains an important clue, so
> he wouldn't use fire spells on the monster. But in CF, you can't see this...
> in fact, I've never figured out the difference between a goblin leader and a
> regular goblin, because they look exactly the same and the leader is not
> significantly tougher. So how would a player know whether or not it's "safe"
> to use fire against that group of goblins (assuming the leader would be
> carrying the important scroll)?

 Note that this is true right now however.  If you launch a fireball in a room,
kill the guy with the scroll, and he drops the scroll when he dies (like all
monsters do), it could then burn up at that time.

 The problem would certainly be worse with if inventory also got hit.  One
unrealistic way would only have inventory get burned for players, and not
monsters.  After all, we are trying to balance the players more than the
monsters.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]