Re: CF: What do you want?

[Mark Wedel <mwedel@scruznet.com>]

> ...implies a hell of a lot of work. I very much like the points you've
> made, but I still think there should be a fallback case where if a
> mapmaker doesn't want to bother with creating a whole mythos behind his
> kickbutt new artifacts, then the game will choose some default behavior.

 I think it is somewhat reasonable if a map maker wants to make some kickass
artifact to add the necessary support to balance it.  I think one of the causes
of many of the super artifacts is the great ability for a map maker to add them
(along with a difficulty of quickly checking the map to see if the artifacts are
balanced).

> Unless someone's going to volunteer to fix all existing artifacts, and
> police new ones.

 Existing articles/maps is always a support issue.  Certainly, some general
support is needed.  How often the server checks to artifacts for special
behaviour (basically, call the do_artifact function).  And done properly, code
can be re-used - the code to handle a dragon bane sword could probably also be
used for a dragon bane dagger without any problems.  So presuming a fair number
of base cases are added, with some general purpose ones, a specific unique
function is not needed for each artifact (although, that would be sort of nice -
if all the artifacts do more or less the same thing, it would get pretty
boring.)

> 
> A scripting language for this sort of thing would be very cool, though.
> 

 An improved scripting language is needed for lots of cool features (improved
monster, npc, and pet ai for example).  It is a difficult feature to add.   For
most any scripting feature to be useful, it needs fairly good access to internal
objects (for example, an npc must be able to look at the map around it in order
for it to be able to do something, a scripted artifact may need to look at the
player/inventory of the player, etc).  And it has to be fast enough that the
game doesn't slow down drastically when 20 scripted artifacts/npcs are active. 
The later can perhaps be handled via using threads or the like for scripting.

 So what would probably end up happening is you would have a scripting language
that relies heavily on C code to actual determine test results/move (for
example, a call to find the nearest enemy, and then the script could perhaps
look at some basic things and determine if it should move this npc towards or,
at which time it calls the C based move functions or the like), with perhaps the
script storing a result someplace in the object so when the object moves, it
examines the script result and calls that action (script said we should move
east, and we have time now, so lets do it.)

Christian Stieber wrote:
> 
> Sure. So maybe the real question is: should crossfire stay like it is
> _now_ (-> only a few minor changes), or _should_ there be some
> redesign on a larger scale?

 The question to be asked could also be 'what should crossfire be like?'  I
think even if it 'stays like it is', there will still be gradual improvements
and new features added.


> The latter means a whole bunch of work (definitely too much for the
> 0.95 -> 1.0 version range); it even makes sense to dump the whole
> thing and start all over again: the "make a version 1, dump it, and
> make a version 2 based on the things you´ve learned from version 1"
> scheme, starting with a proper development cycle such as designing
> the thing before coding it :-)

 But I see that actually happening pretty unlikely.  The likelihood of someone
actually starting from scratch and being able to make a usuable project in a
reasonable amount of time pretty difficult.  I know that some people have
started new projects in the past - not sure of the current status.

 There is a definate incentive to develope for a program that still mostly work
- in that case, you can pretty immediately see the results (new spell, monster,
whatever).

 Not that starting a project from scratch would be a bad idea.  But if that is
going to be done, I think a clear view of what the end goal/game is needed.  If
it is just going to be like crossfire but with cleaned up code, it may very well
be more reasonable to just clean up the code we have.

> This would, as a sideeffect, clean up the code as well --- after all,
> crossfire has grown over the years; new features have been patched
> in, variables (structure fields, in particular) have been re-used
> over and over again causing problems (the speed bug, the how-to-get-
> personality-exp-more-than-once-even-after-it-has-been-fixed abuse
> and probably others). The server contains code for map-bugs; there
> is no documentation telling whether something that can be done is
> a bug or a feature, etc.

 I think the re-doing the object structure of elements are not overloaded and
make things more general can be done with improving the current code.

 I agree in that there are lots of area in which it is not documented how things
work.  An advantage of starting over is that could be documented (but I would
imagine you will still run into conflicts as a new feature is added or code is
changed so something that was not possible is now possible and that side effect
was missed.)  The biggest problem with crossfire in this regard is that there
are maps using these bugs/features, so if they change, maps break.  If no map
used a particular side effect and it was fixed, no one would care.
-
[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]