Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New version of crossfire: thoughts on distributed maps




It may be early to start talking features, but hey ;)

I've often thought about the way the maps are used in crossfire; I think
the current scheme is definitely wrong, and I have some ideas on what
may be nicer.

The problem with the current map loading scheme is that you must have
all maps on a local filesystem: every crossfire server must allocate 5M
of disk space just for maps and archetypes.  Maps are just like any
other data object in a distributed system: they want to be accessible to
all of the distributed servers whilst behaving in a coherent manner: if
one person fixes a map, everyone should see it, etc, etc.

My thought is that maps should be searched for locally. However, if the
map cannot be found locally, then a network request should be made for
the map.  Using what protocol? HTTP of course! :-).  Maps would have to
be cached.

But this would be incredibly inefficient and horrible, I hear you say. 
Well, possibly.  But there are many techniques to fix this, the most
obvious being prefetching (in other thread of the server/client of
course, so you continue to play while it prefetches) all maps accessible
from the current map. Simple.

The net access of maps is fairly trivial to do. The problem comes when
you access a new map which contains some new archetypes, ones that
you're server/client doesn't know about.  Currently, this core dumps the
server or performs other likewise interesting effects.  Ideally,
archetypes should be loadable on the fly, from the same source as the
maps.  i.e. 
	Get map from source X,
	for all objects in map
		check archetype
		if !exists(archetype) then
			add to list (archetype)
	endfor
	if list is non-empty then
		Get archetype list from source X
	endif

Graphics would have to be similarly treated.

A simple way of implementing this right now is to change the loadmap
routine to use http to retrieve the maps (and assume that all archetypes
must exist).  This will work immediately, with no modification to the
maps, so long as the http root is set appropriately (i.e. the root of
the map tree should be "file://localhost/crossfire/maps" instead of
"$crosslib/maps").

This is for the current crossfire system.  With a true client/server
model, a different approach may be taken: the crossfire game could be
considered to be one huge global game (not lots of different servers). 
When a particular client requests a map, it looks to see if anyone else
is playing that map. If so, then it connects to that server.  If not,
then it becomes server for that map.  This is a more complex system, but
it could be very interesting to play.  To be truly playable, perhaps
this system should be implemented on a per-map basis, so that often used
maps are replicated and only the more interesting/complex maps become
globally coherent with this mechanism.

Nick
Nick Williams                          E-mail: njw@cs.city.ac.uk (MIME and ATK)
Systems Architecture Research Centre,  Tel: +44 71 477 8551
London, EC1V 0HB                       Fax: +44 71 477 8587