Server architecture

From MountainfortWiki

Jump to: navigation, search
(Created page with "== info == The server needs to be multithreaded to be capable of simulating catplosions and fluid dynamics. == some notes == === jobs and their data access patterns === * gravi...")
 
Line 3: Line 3:
The server needs to be multithreaded to be capable of simulating catplosions and
The server needs to be multithreaded to be capable of simulating catplosions and
fluid dynamics.
fluid dynamics.
 +
 +
== world simulation step ==
 +
 +
* simulate world (terrain oriented jobs, ie. water, tree growth)
 +
** threadpool (task stealing) that handles all jobs of this simulation step
 +
** each job has read access to the complete world back buffer
 +
** each job has exclusive read/write access to one chunk'S front buffer
 +
** multiple jobs writing one chunk are queued in the same thread
 +
** after all threads are finished the front buffer gets copied onto the back buffer
 +
** each thread has messagebuffer, jobs the thread can write to the message buffer,
 +
*** after all threads are finished,
 +
*** the messages in the message buffer are written to the global message system
 +
** fluid manager : (not every frame?) fluid simulation jobs are spawned by a manager for "awake" blocks (awake can be triggered by sim-job when water reaches edge : messagebuffer)
 +
** light manager : not every frame, placing a torch triggers "awake"/recalc
 +
** simulation has a fixed frames/second speed
 +
*** not all jobs need to calculate themselves every frame
 +
* jobs writing terrain must mark (messagebuffer) the terrain as changed for network messages to be generated
 +
* spin lock : busy-waiting for lock to avoid sleep, if maxfps long wait needed : sleep as job.
 +
* to avoid ram->cpucache bottleneck, attempt to process the same chunk-coordinates in the same thread (across multiple frames?)
 +
** the simulation code of one chunk is implemented in lua
 +
 +
== object simulation/think ==
 +
 +
there are 3 types of objects : mobiles(players,enemies,animals), items(stuff to pick up), buildings (workshops, bridges, doors..)
 +
 +
* every worker thread has own lua state, and global single-threaded mode also. (objects may not have local state, all must be in property name-value list)
 +
* access via metatable. object orientation via dummy-object setting metatable according to object type (property)
 +
 +
* complex structures and can be stored in properties via serialisation (ie json)
 +
* objects can have tags/groups
 +
* objects get messages with time-of-delivery (e.g. think again in 5 seconds, get poison damage, idle wandering animals)
 +
* every message triggers a job (jobs are written in lua)
 +
* priority (starttime) queue of messages
 +
* key-value lists for object properties, backbuffered, objects write themselves using message-buffer (update aka value-change)
 +
* fight/wound etc : send message to object (allows e.g. big blob spawns small blob)
 +
* inter object communication via message system
 +
* read only access to properties of every object
 +
* query objects in range (by type) (optionally flag that object always wants query sightrange in think step)
 +
* object manager creates and destroys objects, you need to send him which one you want to kill
 +
* pathfinding (one path-finding request isn't calculated in a parallel way, but multiple path-finding requests can be run at the same time (no-global-data structures, fully re-entrant?))
 +
* ticker/timer to generate whatever timed messages (ie think message each 30 sec)
 +
 +
== remaining super singlethreaded stuff ==
 +
* complete singlethreaded part
 +
* handles network (send/recv/listen/accept)
 +
* handle complex things like falling trees (we can move this into the multihreading section if its to expesive)
 +
* worldsave/load
 +
 +
 +
== usecases ==
 +
 +
* drawbridge (changes terrain, managed as building)
 +
* fight between two mobiles
 +
* ai/decide-what-to-do : see and attack nearby enemy, cat-mating...
 +
* weather : rain produces small water ponds
 +
* player empties water bucket on area (awake fluid manager in this block)
 +
* lumberjack a tree (event based in single-threaded step)
 +
* cavein (check when solid tile is removed, if unconnected, apply gravity and deadly force)
 +
* closed-door-for-pathfinding, idea : change terrain (parameter)
 +
 +
== later if neccessary, not needed for first prototype ==
 +
 +
* object jobs that can run multiple frames ? (complex ai, pathfinding etc... )
 +
* world jobs that can access more than one chunk (treefall? area? cavein), in separate step after all the 1-chunk jobs are done
 +
** needs to avoid concurrent write access to overlapping area
 +
 +
== glossar ==
 +
 +
* world : terrain infos consisting of tiles in chunks
 +
== some notes ==
== some notes ==
Line 10: Line 80:
* vegetation, rw on complete map, slowakei
* vegetation, rw on complete map, slowakei
* monster, r on complete map, rw on monster mobiles
* monster, r on complete map, rw on monster mobiles
-
* patzfinding, r on complete map  
+
* pathfinding, r on complete map  
* lighting, r on complete map, w on lighting infos
* lighting, r on complete map, w on lighting infos
* weather, r on complete map, w on weather infos
* weather, r on complete map, w on weather infos
* collision/movement, r on complete map, w on mobiles
* collision/movement, r on complete map, w on mobiles
 +
 +
=== questions ===
 +
* is it necessary to keep consistens snapshots of the data over multiple steps?
 +
* backbuffer or copied border?
 +
* data partitioned threading?
 +
 +
=== other similar implementations ===
 +
* minecraft server todo
 +
* dust paper todo

Latest revision as of 17:45, 13 May 2012

Personal tools