[crossfire] The future of Crossfire

[Mark Wedel]

Yann Chachkoff wrote:
> Le lundi 4 juin 2007, Mark Wedel a écrit :
>>   Extra lore about the world could be used to explain other things.  <snip>
>>
> A lot of lore material is already available for a long time on the wiki. The 
> problem is not really adding extra lore, but using what's already written in 
> maps. Writing more lore is pointless if it keeps being ignored in the 
> map-making process.

  Fair enough.  It is sometimes hard to find the correct information, or if 
there is even correct information.  It may be a question if there is a better 
way to organize the wiki - I don't know if there is - unless one is to read 
everything on the wiki, it can get confusing fairly quickly - you see 
same/similar topics under different sub pages, and in same cases, they go to the 
same page, in other cases, they go to different topis, so it can make it 
difficult to know if you've actually read all the relevant informatin.

> 
>>   And while a lot of this could be done with scripts, I'll state this:  For
>> any point that comes up where it could be done with a script, there should
>> then be an example script set up that does that, with it clearly documented
>> (ideally at the top of the script) with the values to change.
>>
> Although creating templates or grouping often used script functions into 
> libraries can definitely be done, it is unrealistic to expect a template for 
> each use we can possibly think about; a lot of code would be specific to each 
> NPC anyway.

  But I'm not saying that I need a sample script for every possible NPC out there.

  I am saying that there should be sample scripts for some of the more 
frequently used/desired type of NPCS, or scripts in general.  sure, if I'm 
asking for something fairly obscure or something that will be used once, I 
should expect that I'll need to write my own script.

But if all I want is an NPC that takes and item and gives an exp reward, that 
should be standard enough that I shouldn't need to write that from scratch.

Likewise, an NPC which I can program to move about shouldn't be so uncommon that 
I need to write that from scratch either.

  It is a fair discussion if these are really common enough things, etc.  But I 
was stating that from my point, these are things that should be added to 'future 
crossfire'.

> 
>>   It doesn't do me any good to say 'it can be done with a script' if it now
>> takes me 2 hours to write/test that script or figure out if there is a
>> suitable one elsewhere I can modify.
>>
> Just for the record, spending hours to figure out how the C code is supposed 
> to work is already necessary, so I wonder why you are insisting so much on 
> that specific point.

But a map maker should not need to look at the code to write a map.  If things 
are documented correctly (which certainly isn't always the case), they just 
modify certain object attributes to get what they need.

Now at some point, someone actually wrote the C code to put that logic in.  I'm 
basically saying that for common scripts, that same level of work should be done 
with sample python scripts.

  Also, keep in mind that not all map makers are going to be programmers.  So if 
such a map makers asks 'how do a I do foo', where foo is a fairly basic feature, 
saying 'you can write a python script to do it' is fairly useless for that person.

>>   I think this change is actually fairly easy to make, because I think
>> almost all damage calculation goes through 1 function.
>>
> Except that changing the pace of combats also involves changes of a lot of 
> maps, which were designed with the idea of fast hack-n-slash. Rooms full of 
> monsters will become either impossible to empty, or very boring to do. I 
> don't think you can dissociate the code modifications from map issues it will 
> create.

  Maybe.  If it becomes boring, I'd say that is more an issue for the player 
(and perhaps a bug on the map) - remember, such a change shouldn't necessarily 
change the difficulty of things much, just the pace.

  I'd almost say that any map that is so full of monsters such that it becomes 
boring to hack through them with a slower damage rate, that probably qualifies 
as not a very good map in the first place.

  A couple other thoughts I have:
1) I think sometimes we become overly cautious about making changes that may 
have bad effects or create other things that need fixing - the problem is that 
this tends to paralyze us into not making any change at all, which doesn't help 
us go forward.
2) Given this would be something in the settings, and the default would keep 
behavior as it is now, there really isn't much downside - changing the settings 
makes it easy to see what the affects are (and perhaps other things that need to 
be adjusted, like spawn rate of monsters), but does make it easy to see what the 
effects are and how it plays out.

> 
>>   But here's the thing - if I have a quest to escort an NPC from scorn to
>> navar city, what would that script look like?  Right now, I envision it
>> being pretty complicated - I think it'd probably be good to have some
>> amount of C code backend to simplify it.
>>
> Python supports the use of script libraries, so common useful functions could 
> easily be moved into such a library, removing the need to add C code.
> I also have a hard time understanding how replacing a supposedly complex 
> Python script by an equally complicated C code would make things simpler in 
> the end.

   My point above is that if I write a script that moves an NPC, I basically 
want something like:

  move_to(x,y);
  apply_exit();
  move_to(x1, y1);
  move_to(x2, y2);
  move_to(x3, y3);
  apply_exit();
  move_to(.., ..)

  Where each action doesn't get processed until it does the previous one (we 
don't start move to x2,y2 until we reach x1, y1, etc.

  In addition, that move logic should probably have some options, like avoid 
obstacles (if something is in the way, will change course), will pick up things 
while it moves, will (or won't) attack enemy creatures as it moves, etc.

  How exactly all that logic is done, I don't really care much - if it is with 
python libraries, fine.  If there is C code to help, fine.  One concern on 
something like this, especially if there are a lot of NPCs about, is actual 
performance - if all done in python code, I'd have to imagine there'd be a fair 
amount of extra overhead as it examines the objets on all the surrounding 
spacing, as it looks for alternative paths, etc.