[CF-Devel] Adding New Stuff (again) - Requests and suggestions

crossfire-devel-admin at archives.real-time.com crossfire-devel-admin at archives.real-time.com
Sat Apr 26 00:06:05 CDT 2003


Flying Pedestrian wrote:
>
     
      Finally had a chance to start playing with Crossfire again...
     
     >
     
     
     
>
     
      One problem I run into trying to add new things is the fact that MOST
     
     >
     
      of them require recompiling from scratch - and getting anyone else
     
     >
     
      to try them out requires generating a diff and talking someone else
     
     >
     
      into also recompiling from scratch (and hoping CVS hasn't changed in
     
     >
     
      the relevant areas in the meantime...).  Realistically, this means
     
     >
     
      only the person who created the new "thing" would ever try it out, and
     
     >
     
      nobody on a dial-up line would ever be able to contribute effectively at
     
     >
     
      all (as running a server on a dial-up line is not as simple to keep up long
     
     >
     
      enough for anyone else to try it out...)
     
     
  The compiling issue is one that can't be avoided - if you make code changes, 
the code has to be compiled.

  I'd note that one issue is that there just aren't a lot of servers, so you 
have a relatively small audience of peopel to try to run any changes, whether a 
compilation is needed or not.  And of those, some number may want to stick to 
stable code, just CVS code, etc.


>
     
      This way, if someone generated a new race (requiring nothing more than
     
     >
     
      new arch's, barring any completely-new abilities that can't be 
     
     >
     
      defined there), anyone who wanted to try it out would need only drop
     
     >
     
      the generated "add-on" files containing the extra archetypes-file info and
     
     >
     
      extra treasures-file info into the appropriate place and restart the server.
     
     
  The archetypes and treasure files are text only, order is not important.  so 
right now, something like 'cat arch_new >> archetypes; cat treasure_new >> 
treasures' would do as you describe.  I don't really see the point of having 
seperate external files from those.

>
     
     
     >
     
      Similarly, it would be helpful if more of the "generic" functionality were
     
     >
     
      to be split out of the source code and into configuration files/arches (such
     
     >
     
      as hand-to-hand attacks, the "generic" bullet/bolt/ball/cone spells, creatures
     
     >
     
      summoned by different summon-type spells, etc.) would make it easier to
     
     >
     
      contribute new variations for testing and evaluation for inclusion in the
     
     >
     
      "real" source.  As I recall, all of those categories in the game are really 
     
     >
     
      defined by external config files, but it is currently still necessary to
     
     >
     
      edit header and source files to add the names (and recompile), which cuts 
     
     >
     
      out a lot of potential testing of new spells.  I don't know how difficult
     
     >
     
      this would be do do in practice, so I assume it's incredibly easy for any of
     
     >
     
      the official developers and therefore I demand that it be done immediately.
     
     
  It depends.  I personally don't want a bunch of config files each with a 
unique format.  However, I do plan to move more of the functionality to arch's 
(spell archs as per a mail a few weeks ago).


>
     
      (I'm still surprised that there's no "biting" HtH attack, given the number 
     
     >
     
      of biting monsters [mice, snakes, wolves, etc.] wandering around...)
     
     
  monsters don't use skill attacks.  So for example, while right now there is a 
clawing skill, monsters don't use it - they just use the values in their arch 
which defines to hit, damage, etc.

  However, at some point, one has to examine how many 'unarmed' attacks there 
really should be.  In real life, given a choice, almost no one would go unarmed 
- even a master of karate would probably be more effective with katana in hand. 
  So the unarmed attacks more add color, and not effective attack methods 
(although the code may be generous with some).

  And crossfire doesn't follow other game system model where a claw/claw/bite 
attack would mean 3 attacks a round.  So if a player has claw and bite, he 
doesn't get extra attack, he just gets more choices.  But almost certainly, one 
will be better than the other.  So the question is why add all these skills in?

  I'm also tempted to just roll all of these into an 'unarmed combat' skill. 
One can think of this as kicking, punching, clawing, biting, etc.

>
     
     
     >
     
      Finally, some published semi-official guidelines as to what's required
     
     >
     
      for "acceptable" submissions of new races, spells, foods, materials, etc.
     
     >
     
      would be helpful, similar to the existing documentation regarding new
     
     >
     
      skills, e.g. something along the lines of:
     
     
  This is much more variable.

  My personal thoughts on this:
1) It must be sufficiently different to be added.  This is probably why the 
northman lost out in the competition - not sufficiently different to really care 
about.  similiar to the spruce/pine material discussion.

2) It must be balanced.  Balance is a trickier issue.  Look at some of the races 
- a lot of stat bonuses, but some other penalty to offset for it (lack of 
ability to use some item, etc).  There are probably some things to say, like 
more than a 10 modifier to a stat would be questionable.

3) It must be complete, eg, have the arch, image if appropriate, treasure file 
if appropriate, etc.


I'd also note that discussion on this can happen on the mailing list.  For 
example, you can make a post like 'here is a new class - I show the bonuses, 
skills,etc,  What do people think?'  This is a bit harder if there are code 
changes - one can envision what they want to do, but may run into problems when 
it comes to writing the code.  Same issue shouldn't be true for archs.



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list