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

[Hwei Sheng TEOH <hsteoh@cs.toronto.edu>]

On Sat, 11 Sep 1999, David Andrew Michael Noelle wrote:

> Mark Wedel wrote:
[snip]
> 
> >  Some maps actually had problems with this - they would do a map that uses may
> > 60% of the map (or combine several small maps into one map with appropriately
> > linked exits).  If no magic wasn't applied to the walls, you could dimension
> > door into this no mans land so to speak.  And that will also be a problem with
> > etheraelity.
> 
>     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.

Frankly, I was quite shocked when I first installed the CF map editor and
found out how certain maps worked the way they did -- by using complex
contraptions with boulders/gates/etc. I'd have thought there should be at
least some way to do this stuff without needing to put weird "secret" stuff on
the map.

Actually, IMHO the "ultimate" clean solution is to implement some form of
scripting for maps... somebody has already mentioned before about the need of
quest scripting. Add to that the recent trouble with the pupland maps,
improved monster AI, etc., and it seems like scripting is just begging to be
added to CF.

The scripting language/mechanism doesn't have to be complicated -- simple
state-machine imitations with timed transitions and triggers should work
pretty well. (Although the exact details of this still need to be thought
out).

> >  The other suggestion would be to add some extra information to walls in perhaps
> > the form of a bitmask.  Thinks like:
> > 
> >  fly_over: If set, a player can fly over this wall
> >  ethereal: If set, and ethereal creature can fly through this wall
> >  digable: If set, a player can very slowly dig through this wall/use wands of
> > digging (much slower than an earthwall, and perhaps needing proper tools).
> >  minable:  Like digable, but wall may have some random mineral inside.
> >  Also add the no_magic and other such flags here, so you don't need to stack
> > other objects on top.
> 
>     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.

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

>     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?

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

[snip]
> >  There are a couple reasons things last forever right now:
> > 
> >  1) Most all current artifacts have a non existant material, which basically
> > makes them immune to any and all attacktypes (they can never be destroyed or
> > damaged).  So once you find an artifact, it is good forever.
> >  2) Except for acid, very few attacktypes (cancellation being another I can
> > think of) will actually harm items in a players inventory.
> > 
> >  Both could pretty easily be changed.  Artifacts should have some material and
> > be destructible - it would just be very unlikely for most artifacts due to their
> > high magic value and the fact they tend to have various protections.
> 
>     Many of them would probably be Adamantium, in which case they're still
> indestructible, but at least they're not made of nothing.
>     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.
>     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.

Several times while making maps I've had the wish that I could create a new
material type without having to hack the server code and deal with bitmasks,
etc., and recompile the whole source tree. Using material archetypes
(or even objects, with editable archetypes??) might provide mapmakers with a
way to do this (to a certain limit--I don't think we want materials that are
just too strange).

> >  The second one could have fairly big affects.  AD&D definately has a players
> > items make saves if the character itself fails their saving through.  But with
> > crossfire, where you have some attacks like fireball which hit you for a lot of
> > attacks, that could result in a lot of destruction.  So that could be pretty
> > harsh (get hit by a large fireball, and chances are you need to make a dozen
> > saves, with at least a few you will fail so some items go toast).
> > 
> >  OTOH, this may add some playbalance to the game -  player won't carry every
> > item he has simply because there will be some fear of that happening.  A player
> > may also think about getting out of spell effects a little quicker then.
> 
>     I like it.  I'm sure it will be thoroughly aggravating, but there's
> nothing wrong with that.  It would also increase the value of protection
> magic, especially when protection becomes additive.  A flame-retardant
> backpack (protects itself - and thus its contents - from fire, but not you)
> would be a must-have.

Yes, it will be thoroughly aggravating. And it would also make magic-users
have a hard time with gathering treasure, since using powerful spells will
almost certainly destroy whatever good equipment a monster is carrying. This
might be realistic; but at least there should be something else to balance it
-- perhaps by re-working the current spells so that there are more spells that
doesn't destroy equipment (though they would be weaker).

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.

And sometimes monsters may carry important readables that contain
important quest clues... using fire-spells on the monster will just ruin the
quest for you. One way would be to put the scroll/note/whatever in a safe
place that can be reached only after you kill the monster. But this gets back
to the problem with destructible keys... the only good solution I can think of
is to have the monster trigger the door when it dies -- though this has yet to
be implemented.

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


T

-
[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]