> 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 !]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire