[crossfire] C++/Qt server version

[Nicolas Weeger]

> From past experience, I'd tend to lean towards writing a server code "from
> scratch", possibly recycling various elements by cut'n'paste, instead of
> evolving a codebase that is already of questionable cleanliness.

Yes, that's indeed a solution I can see, and it may be the choice I (and 
others if people participate :)) make.

> This would also need to lay down a code architecture, split this into
> tasks, and establish a development schedule. It also obviously require a
> coding team - the scale of the task would require it to achieve decent
> results in an acceptable development time.

Yes. Design documents, planning, documentation and such (unit tests, ...) are 
needed, required before coding.
As well as a relation to the content, to know what the code needs to support 
and how it supports it :)
So clearly coordination with the "content leader".

> My main concern is that by using the current code base without a solid
> design map, the result would mostly be a "Crossfire with Qt extensions" -
> most griefs I have towards the current code are architectural, and I'm not
> sure an incremental approach would allow to really solve them.

Yes, so a rewrite from scratch with cut'n' paste is quite a possibility.
My opinion is that first we think about the design / architecture we want, 
then estimate / decide if it's better to do cut'n'paste, or merely adding to 
the code.

> Finally, from your message content, it is hard not to see the intend as
> being more "using Qt" than "providing something new". Although I strongly
> believe myself that the use of C++/Qt can lead to a more flexible, less
> complex code, I wouldn't go on Qt just for the sake of it: why you want to
> do that and with which planned advantages in terms of features/stability is
> what I'd want to be defined before judging on my position about this.

Some rationale I can see for using C++:
- the game structure (in my eyes) easily and almost naturally fits a class 
hierarchy : map, objects, player or monster controlling an object
- things like shared strings or stringbuffer are easier to write in C++ than 
C, and look "more natural" (again, to my eyes)

Concerning the choice to use an existing framework, I'd say we're making a 
game, not a framework, so using an existing one which does bring advantages 
is a big plus when applicable.

So why Qt:
- cross-platform
- well tested through KDE and many applications
- has all the basics we need: strings (including shared strings for memory 
reduction unless I'm mistaking), sockets, file / directory, threads and 
locks, multilanguage support
- modular so we can only use what we need (no GUI for server, definitely)
- easy to plug in GUI if needed with class coherence
- signal/slot mechanism that could be used for plugins or archetype reloading
- existing unit test framework (not that advanced, but enough for almost all 
our needs I think)


As for the features I'd see that would be easier to write in C++/Qt than 
current C code:
- dynamic archetype reloading - no need to restart the server or even collect 
archetypes
- possibly a distributed server architecture, with recovery mechanisms (server 
instance crashes, clients get routed to other ones with minimum content loss)
- multithreaded server, or at least some thread-related mechanisms, to 
avoid "lag by multiple meteor storm" issues



Of course we could do this in C, in C/GTK, with many things (Java, assembly 
language, whatever :)), I'm not saying C++/Qt is the reply to everything or 
maybe even the right choice here.

So to be honest, my proposal could be seen as: "let's redesign / 
rearchitecture the whole server to add nice features, and while we're at it 
let's use C++/Qt to simplify our life and make the code more compact!"


Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/69338c7e/attachment-0001.pgp