[crossfire] C++/Qt server version

Mark Wedel mwedel at sonic.net
Tue Nov 25 00:06:40 CST 2008


  Some various musings I wanted to write up before I forget about them :)  They 
don't directly relate to this conversation, but were brushed upon in certain 
messages.

Backward compatibility and rewrite: Given the number of maps and archetypes, it 
is certainly desirable that those still work - we don't want to have to go 
through and update every map just so it loads.  However, there could certainly 
be some maps using behavior that is undocumented, or there could even be code to 
handle certain things so they don't break.  But for some things, having clean 
code may be more desirable than maintaining some behavior that 2 maps use (and 
those 2 maps could get updated/fixed).

Shared strings:  While perhaps no reason to get rid of them, I also wonder how 
necessary they are now days.  They do simplify comparisons.  And with C++ and 
proper class descriptions, they can be made to be safe (have to use class 
functions to modify the name, and it knows to do the right thing).  But shared 
strings date back a long time in crossfire, to when systems had much less memory 
and this was more a concern.  They certainly do still save space, but the amount 
of space saved may not be worth the extra handling.  It should certainly be 
reviewed - many design decisions date back to when computers where much less 
capable than they are now, and may not make much sense.

Quick thought on features you mention:

Dynamic arch loading: This makes sense, especially if/when images want to 
include new archetypes/images/animations/whatever else.  Handling changing 
archetypes on a running server gets weird - need to have a fairly clear 
understanding what should happen there (if I'm fighting a monster and an arch 
reload happens and monster now changes, that would be odd)

Distributed server archetype: Need more details - having redundancy (client 
rerouting with minimal data loss) might not be worth the effort - have to make 
sure you don't have two servers trying to control the same area, recovery when 
one comes back on-line, etc.  But being distributed (this server is responsible 
for scorn region, this one for navar city, etc) to reduce load may make sense, 
with there being smarts to transfer character detail between those, etc.  In 
terms of server failure/crash, the client could improve that experience - most 
servers restart when they crash, so it is really to the client to pop up a 
window with something like 'connection lost - trying to reconnect (with spinning 
disk or something)'.

Multithread server:  I think this is a must - computers are moving more and more 
towards multiple cores, and less towards raw speed, and for crossfire to make 
use of those really requires multithreading.  I always thought that 
multithreading at the map level would make the most sense - this potentially 
lets one use many threads (and thus cores) and is probably the simplest way to go.




More information about the crossfire mailing list