[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