Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



________=22Re=3A_CF=3A_Suggestion=3A_Talking_=28was_Re=3A_CF=3A_Suggestion?=
 =?iso-8859-1?Q?=3A_Reg_exps=2E=2E=2E=29=22_=28Sep_28=2C_12=3A12pm=29?=
References: <199809281012.MAA18372@chapelle.eed.ericsson.se>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: Raphael.Quinet@eed.ericsson.se (=?iso-8859-1?Q?_Rapha=EBl_Quinet?=),
 crossfire@ifi.uio.no
Subject: Re: CF: Suggestion: Talking (was Re: CF: Suggestion: Reg exps...)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii


> I thought about @give too, but this is not really needed: the only
> thing you need is to @activate a teleporter that brings the object
> from some area outside the visible map.  This has the advantage that
> nobody can get the objects by killing the NPC's, because the objects
> would not be in his inventory.

 On the other hand, there could be situation where that might be desirable (ie,
you can either talk with the npc to get the item, or have a tough battle -
especially if you surround the NPC's with friends of his.)

>
> Similary, @take can be replaced by invisible altars placed around the
> NPC, activating a @connect statement in the NPC.  Although this will
> only work if the NPC stays in the same place, it will be easier to
> program because the altars are already triggered when some object is
> dropped on top of them.  It would be a bit more difficult to activate
> the NPC every time some object is dropped around him.

 Thats true.  However, the NPC could examine the spaces around him each time he
gets an action and grab if appropriate.  On the other hand, if people pile
stuff around him, this could slow things down a bit.

 On the other hand, the point about wandering NPC's is true.  I know there were
at least some bugs where the npc got moved, but you could still have a
convesation where he used to be.  The same could happen with altars.


> There are lots of other options that could be added to the NPC's, but
> I think that we should start with that first, and leave the rest for
> later.  Besides the @cast command described by Mark, we could also add:
> - @follow (NPC follows the player if possible - but no word of recall),
> - @goto (moves towards some other location),
> - @attack (attacks some target),
> - @create (creates new objects from their archetype or summons new
>   monsters or NPC's) and
> - @location (conditional statement that executes some commands if the
>   NPC is at some location on the map - use together with @goto to
>   create complex paths).
> If @give and @take are implemented so that the NPC can add or remove
> things from his inventory, we could also add @apply.  But I have the
> feeling that things could quickly get out of control if we try to
> implement all that.

 Yeah - it would.  The main thing that drives progress is the needs of the map
designer.  For example, if the map designer wants the NPC to be able to cast
spells, that might warrant the cast command (however, this could also be done
via the connected ability, since there are spell casting altars now).

 Something like the @follow would probably just need to trigger a higher state
- that npc is now like a familiar to the character.

 I believe right now programmed movements for npcs could be done with player
movers.  On the other hand, this isn't very random movement.


> I agree.  We need more maps with interesting quests.  Especially for
> low- and middle-level characters (below 10).  In order to add more
> balance to the game and to make these quests worth playing, the old
> "kill all monsters and grab the treasure" maps should be removed when
> some quests of similar difficulty are added to the game.

 One thought I had would be different starting maps for the different
races/classes.  A dwarf should probably start in a dwarven city in/under the
mountains someplace.  And elf in a forest city, etc.  Each one would probably
have fairly unique low level quests related to their starting spot.  At some
point, they would need to venture beyond the starting town for the more
advanced quests, so things might get more similar at that point.  But I think
something like that would add a bit more color and also unique experiences.

 I remember in the very old starting village, until you knew some of the
tricks, you effectively had to be 8-10th' level before you could even exit the
village (town gate was guarded by a wyvern).  Granted, the world wasn't as
large back then, so most of the maps were more around the starting village.

 There are certainly some maps that could be removed.  The newbie tower would
be a good candidate - it is a relatively safe way for a starting character to
get to level 4-5 in less than half an hour of play - just a whole bunch of low
level monsters.

 On the other hand, while the old city quest is interesting, it is so long it
is almost discouraging.  IF looking for a good way to gain exp/levels, doing
that entire quest probably isn't one of them.   Probably some of the levels
just suffer from being too mazy - a lot of wandering to figure out where you
are going and how to get to some level.

 One thing I liked about the old ultima games is the various lords gave you
some definitive quest, and you almost always got a suitable reward for doing
it.  Right now in crossfire, there are the NPC's in teh starting tavern and
elsewhere, but trying to figure out what keywords they want can sometimes be
frustating.  And the rewards are not always worthwhile - some items are better
than others in almost all situations, so there is no reason to use that new
items.

 One thought on the scripting language:  This could be a good area in which to
expand crossedit - for example, have crossedit have some built in mechanism for
constructing the state/flow of conversation (right now, you have to code it by
hand) - this would probably make writing good conversant PC's easier, and might
make the scripting language easier to parse since it has been constructed in a
known way.



>
> -Raphael
>
>-- End of excerpt from  Raphaël Quinet



-- 

-- Mark Wedel
mark@pyramid.com