Re: Talking to NPC's

[Petri Heinil{ <Petri.Heinila@lut.fi>]

On Wed, 6 Apr 1994, Gregor Schmid wrote:

> Mark Wedel writes:
>  >  Conversation code should really be re-done at some point, to allow for
>  > more advanced features (give or take, for example), as well as different
>  > states.  Right now, if there is a match for yes, there can only be
>  > one response.  Different states should be used, so you can be asked a series
>  > of yes/no questions, and with each answer, have a different question come
>  > up.
>  > 
>  >  --Mark
> 
> I think it's time to rethink the general approach here.

I have thinked, yes :^)

> Crossfire implements a simple parser for the archetypes, including
> the @match handling, which does it's job but not much more.
> Whenever there is need for a new feature, tha parser has to be
> extended.

Going sightseen trough lib, ... the language is used in:

treasures	- descripe different type treasure, where are the changes
     		  in dirrefferent item, when creating object that have that
         	  treasure, or when object dies.

spell_params	- descripe what spells exists, and what are the 
	       	  charasterisks of those spell.  This is like table form.

sounds 		- description what sounds exists, and their mappings

motd		- the word of day

maps		- descripe the contents of the map. And descriping
		  the detailed parameters for the instance of the
		  object class. The map format is also used in
		  temporary saving of the maps.

help		- files that contains pure for for helping info.

fsconfig	- hmm, something for server info. I think, does this
		  really exist here.

def_keys	- input system keybiard mapping

def_help	- help for inputs

artifacts	- descripes different type of artifact and what to
		  it can be effect.

arch		- descripes the attributes of the architypes. And
		  the faces of the archetypes.

[generated files and adm are out of vision]

The purposes of the files are like system configuration, files
sounds, motd, help. These are server side stuff and could be well
in one file ar by command line params (look xpilot).

The client side configuration, files: def_keys, because this 
is a x-program these should be in x-resources (the .ad -file).

And then there are the world management (we are the gods, aren't we :).
These are the files: treasures, spell_params, artifacts, arch. And
for these there should exist common, consistent language.

> How about including a real scripting language like tcl into crossfire.

Scripting vs. coding ! There have to draw line between things that
are coded (by some compiled machine depend language) and what
things are scipted (by high-level (means crossfire oriented language :)
machine independ language).

> It would be hard at first, but tcl runs on just about every unix box
> (there's even a DOS port, ugh) and is easy to combine with any app.

Tcl is easy combine to most applications because it's designed
common configuration language. And it could be used as server
side sytem configuration. But for the describe the world
and the objects need some more specific language where the
primary messages (= routines) are like "move direction",
"drop item" or "create object". And tcl eats quite amount
of memory; whitout Tk the consuption can be 2MB and with 5MB,
and thinking the crossfire more, it would be 7MB.

The form of language sould be some like describing the values of
attributes of the objects (the number of attributes should be constant, 
because of creation of variables in language leads to allocation and
performance problems). And there are defined the behaviour of
objects (= monsters) in different events, like "born", "die", "apply",
"say" or "hit". Languages like these, are the real-time system or
simulation system description languages, like simscript, simula or
smalltalk (that is derived from simula).

> Archetypes and maps could then include tcl-scripts that are evaluated
> at run time, which brings about unlimited possibilities.
> 
> I'm afraid it is a bit late for that though, but maybe it's a thought.
> 
> By the way, the overhead wouldn't be much more than the existing
> parser.

Hee, say parsers :). Foreach file exists own parsing system.
The situation now is not quite robust.

-- <A HREF="http://www.lut.fi/~hevi/">The Page</A> --