[CF-Devel] Crossfire plugins

Yann Chachkoff yann.chachkoff at MailAndNews.com
Thu Oct 25 04:05:56 CDT 2001


>
     
     ===== Original Message From Mark Wedel <
      
      mwedel at sonic.net
      
      > =====
     
     >
     
      I have some general questions about the plugin supports:
     
     >
     
     
     >
     
     What is the long term idea behind the plugins?  It seems to me that if I am
     
     >
     
     designing a new map, I'm less likely to use features from the plugins unless 
     
     I
>
     
     know they exist in the servers that will be using my map.
     
     >
     
     
     >
     
      This then leads me to think that longer term, you end up with two main
     
     >
     
     possiblities:  1) Most every server has a set of core plugins they support, 
     
     in
>
     
     which case these are not really plugins anymore, but main features of the 
     
     game,
>
     
     or 2) Different servers may have completely different sets of plugins,
     
     >
     
     potentially creating very different game play enviroments.
     
     >
     
     
     For #1: I use the term "plugin" to name a piece of code that is not directly 
part of the main executable file and can be added or removed at any time. The 
fact that some plugins may become "canon" and be distributed with every decent 
crossfire server does not mean they are not plugins anymore.
It is of course indeed true that some plugins may prove so interesting that 
they could become "main features" needed by a lot of maps. But making plugins 
optional functionalities was not what I got in mind when I started developing 
this. The main idea behind the plugin concept was to allow easier server 
updates for work-in-progress functionalities (you previously needed to rebuild 
the whole server, stop the old one, and restart the whole stuff - it was also 
difficult to desactivate a faultly beta-stage code once it was integrated into 
the main code). As a side effect, it also means that you could imagine very 
different gaming environments using different plugins. It also means that you 
could say "I have a brilliant idea, but I don't know how players will react to 
it" and make your code as a plugin that could be easily tested without 
requiring you to put your code in the core just to see that lots of people 
don't like it.

>
     
     #2 of course leads to all sorts of possibilities - if most everything 
     
     currently
>
     
     in the server directory becomes plugins, then choosing your plugins (and
     
     >
     
     archetypes) could really determine the type of game you have.  The only 
     
     downside
>
     
     I see on this is a pretty big fragmentation of developers - some may like one
     
     >
     
     environment more than the other.
     
     >
     
     
     I don't understand why it should make the development process more fragmented 
that it is now. The plugin system simply means that you can develop your own 
piece of code without bothering about what others are doing/have done. I think 
the increased freedom in the development process allowed outweights the fact 
that anyone could go in a different direction - this is already more or less 
the case.

>
     
      My other potential concern is basically the current status of the clients - 
     
     a
>
     
     bunch of different people write different plugins, but some fundamental code
     
     >
     
     change is made (say changing one of the structures), and now there are a 
     
     bunch
>
     
     of plugins that need to get updated (a lot of work).
     
     >
     
     
     Isn't it already the case for the core code ? If you make some big changes in 
the core (say, in object structure for example), it implies that quite a lot 
of code needs to be changed anyway (and I don't even speak about the 
clients-update problem here). And don't forget the plugin interface is based 
on an interface less dependent of the server/crosslib internals (by the use of 
hooks). Maybe I could go further on the abstraction layer problem to prevent 
compatibility break ?

Chachkoff Y.

-----------------------------------------
Visit 
     
     http://www.chachkoff.f2s.com
     
      for
a journey into a fantastic world !
(But don't expect too much...)
-----------------------------------------


    
    


More information about the crossfire mailing list