Server architecture
From MountainfortWiki
Ghoulsblade (Talk | contribs) |
|||
| 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 | ||
| - | * | + | * 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 | ||
| Line 19: | Line 89: | ||
* backbuffer or copied border? | * backbuffer or copied border? | ||
* data partitioned threading? | * data partitioned threading? | ||
| + | |||
| + | === other similar implementations === | ||
| + | * minecraft server todo | ||
| + | * dust paper todo | ||
