[crossfire] Moving server towards a modularized system?

[tchize]

Le Mardi 17 Janvier 2006 06:12, Alex Schultz a écrit :
> Indeed. On this example, IMHO random maps are not optional, as they are 
> essential to some quests, and also soon would be used by land plots 
> (though land plots would in my opinion be a relatively good thing to 
> implement as an optional-but-defaultly-on C plugin)
> 

IMHO they are optional, they are mandatory to use the current map set, that is true, but that just mean a random maps module is a requirement for using bigworld maps.
I my opinion, those are optional, even if they may appear mandatory to run current maps. Imho it should even be possible to pickup the crossfire core and create a brand new world out of it.
- communication protocol (should be interchangeable, it can be driven by object modification events in server, this also would help dissociate rules from socket events, it would make also easy to put several protocol modules, eg, one for bots or another one for a scorn webcam)
- weather system (it's main architecture is, on a regular time do calculations and update world maps)
- python scripting (is a requirement to run big world, but not to run server)
- random maps, in a more general point, map loading / saving, this would give the possibility to have other means of generating maps and saving maps. We could think of separate modules for random maps, user specific permanent maps, underworld? (it has been suggested the underworld could be based on what exist on upper world)

The fact is, a server would be able to start without map loading, without scripts, without communication protocol. It would just have a bunch of rules and nothing to do.
But that also mean we could start it with only communication protocol plugged in and a dummy map loading module, this only in the purpose of testing protocol behaviour, maybe in an automated way.