[CF-Devel] Projects List, part I

[Chachkoff Yann]

(I am speaking as ESPS representative this time)
After nearly 3 months of information gathering of all sorts about Crossfire, 
we established the following list of most wanted things to do in Crossfire.

We do know that those things could not be to the taste of some people. Some 
of the following things will certainly sound uninteresting to quite a lot of 
people usually speaking on the crossfire-devel list (else those matters would 
probably have been studied deeper here and would be now available in the 
code). 

We do not want to impose any idea to the Crossfire Community; we also do not 
want to write all these things by ourselves, because 1) we do not have enough 
time to manage anything (it is not the only project we are working on) 2) 
because we think there are already anough coders involved in the project to 
handle all the work 3) because a code coming from outside the Community would 
get less chance to get accepted (as previous attempts clearly showed this). 

However, after reading our records of IRC conversations about various ideas 
and seeing how problems were handled by the Crossfire Community, we decided 
that posting a list of most wanted things could make decisions about what 
should and what should not be done a little easier.

The list in unsorted - the order used to present things does not mean 
anything here.

1. Multiheaded servers: Ability to link several servers so they can share 
datas (like communications, items, players or maps);

2. Multiplayer infrastructure: Quests, maps and game rules promoting the 
multiplayer gaming;

3. Network Protocol: New network protocol better suited for low-end 
connections (like 36K/56K analog modems) and lowering both bandwidth and 
required computing time both on client and server side;

4. Improved esthetics: ISO graphics with complete animations (by "complete 
anims", we mean that the game no longer use a square-by-square walk scheme, 
but a more precise positioning system);

5. Dynamic maps: Ability to have maps that can be changed at runtime, even by 
players.

6. Dynamic server: Ability to add game objects or rules at runtime, even by 
players.

7. Functional split: Code reorganization implying that each main game 
function (graphics handling, rules engine, networking stuff, etc.) become 
independent of each other, so developments in the "rules" part would require 
no modifications in the other parts. 

All those ideas were already discussed, in a way or another. All other 
subjects are either less often wanted or very small ones that could be 
handled by only one coder working for a couple of hours.

Of course, there are lots of objections to each of those subjects (for 
example, 1 implies security problems; 5 implies performance problems). We 
deeply studied any of them and we have written quite a lot of datas about 
(algorithms that can be used, possible problems and suggested solutions, 
testings, etc.); those datas are mostly handwritten ones, but we are ready to 
transcript them on a "digital" format and share them to the Crossfire 
Community.

However, we are ready to share our knowledge only we are certain there's a 
strong will to do serious work with them. We'll not agree to put our work "on 
the middle of the arena" just to see endless debates about them. We are of 
course not again the idea of discussing each point, but we do not want all 
our work wasted by infinite chatting about worthless details.

So, if someone is interested by working any of those points, let us know 
(simply send a reply to 
     
     yann.chachkoff at mailandnews.com
     
      with "ESPS Crossfire" 
as subject). If you are not interested, do not reply. We'll not answer to 
"philosophical" questions about this message - either you accept or refuse 
the idea, but nothing else interest us. Anyone interested in the idea can 
send us an e-mail, even those that have no knowledge of programming. Of 
course, the people that agree to help are not "confined" in some kind of 
private work. It is just a confirmation that allows us to see how many people 
are ready to work on a particular subject - our infos would be diffused via 
the standard crossfire-devel list as it is already now.

If not enough people can be found for a particular point, we'll simply put it 
aside. If not enough people can be found for all ideas, we'll simply conclude 
that Crossfire reached a point where evolution has become too difficult and 
we'll propose our work to another similar project. 

We hesitated quite a long time before mailing this message, because it could 
be interpreted as an attempt to gain control of the project, or to restrict 
the current field of research. We finally decided to go on, because we think 
that the Crossfire Community members are clever enough to see that we only 
want to see the project quality to improve, and that we have no interest in 
an eventual "control".

Well, you may like or hate the idea. It does not matter for us. We simply 
hope that Crossfire will continue to improve, with or without support.

If you have any technical question about this message, email to 
     
     yann.chachkoff at mailandnews.com
     
      with "ESPS Crossfire question" as subject.

For the ESPS,
E. Verfay, Programmer/Coord.
Y. Chachkoff, Programmer/Obs.
A. Cafarelli, Programmer/Obs.