[crossfire] Moving server towards a modularized system?

[tchize]

Le Lundi 16 Janvier 2006 13:07, Anton Oussik a écrit :
> Throwing in my two pennies:
> 
> In general modularisiation of the code will improve maintainability,

That's also my opinion.

> On the other hand modularising the code will result in many changes,
> may introduce new bugs into the code, and is in general a lot of work
> whilst the benefits are questionable (this will only be useful if core
> is really small and most things are out in modules which can be
> configured at configure stage). If someone has a desire to do all that
> they are welcome to (it is an open source project :-) ), but in my
> opinion implementing new features would be more beneficial to the
> project.

Speaking of my experience with crossfire code. I have developped
a few add-ons to crossfire in the past (don't remember the list). 
From my point of view, adding new features in the code is currently 
a pain in the ass. I have dropped features add-ons which took
me lots of time simply because it has become nearly impossible to find 
something in the code. 
If you add a new arch type, you have to register it in a define list, register 
it in the movement function if it is active, register it in the attack code 
if it can attack player, maybe register it with weather system if it can 
interact with it, register it to spell casting system if, for example, it 
represents a spell modifier. Can you imagine today creating an item which has 
as characteristic 'owner can walk over water' without modifying piece of code 
everywhere?

In a modularized system, you could have something like that (it's just an 
idea, it still has obvious flaws in aglorithms)

when trying to move object from squareX to squareY, you trigger a move_request
event on squareX listeners, on squareY listeners and on object listeners.
Each listener can respond with NEUTRAL(0), ALLOW(1), REJECT(-1)
if there is an allow, then allow movement
else if there are no reject then allow movement
else refuse movement
water would be REJECT non swimming obj, your item, registered in player when 
applied) would allow on every square with water.
The exact same idea can be used to create complex check_inv, confusion spells, 
director, no_movement traps . You just 'plugs' in the movement code.

Also this system can improve server performances. Currently, one of the main 
'lag' problem of server is meteor swarm in the open areas. thousands of fire 
elements are checking the object list on a given square (that is other fire 
elements) at a given tick, and this until fire dies a few seconds later.
Now imagine this.
create a 'fire' arch at square X.
When inserted, arch code register a move_event for the square and also analyse 
immediatly content of square.
when new things are added to the square, the fire can check immediatly if this 
item can burn. Most of the time, there is nothing to burn.
when the fire element gets activated avery X ticks, it does not have to 
explore a list of 100 other fire object to know there is nothing burnable 
where it belongs. 

Saying it's more important to add new features than modularize the code is 
simply a short term view. Since am part of this projects, i saw new features 
coming on a regular basis. Today the code, imho,  is far less maintanable 
then it was 5 years ago. And if we continue to focus on features without 
architecture the code will be a blotted piece of unmaintanable code in a few 
years. 

If i remember well, Mark Wedel already had in the past to request from 
developper they spend more time on fixing the server code then add new 
features. There are tons of features in code map maker simply don't know 
about.

Moreover there are tons of security issues in the code. They could be isolated 
and identified far more easily during a reorganisation process.

I hope we will ge to an agreement on this subject.

> 
> If you are going to go ahead with it, before you do anything to the
> code you will need to define what goes out to what modules, and what
> depends on what. Since CF was not designed to be modular you may also
> find recursive dependancies which will need resolving first. But I
> suspect you knew this already...
> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
> 
>