Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualwodinoneeye

Posted 21 February 2014 - 06:49 AM

It gets nasty.  Each chunk needs to maintain a border area (to a depth of any significant visible actions/events) for all of its adjacent chunks.  You then maintain a shadow copy there of any significant objects within that border area of that other chunk (you have some kind of subscription to channel updates to THIS server machine...) .   Every time something happens to those potentailly visible objects in the other chunks, the current chunk has those shadow objects updated with whatever significant state/event happenings are specified by your game mechanics..    You can now do basic visibility checks and projectile pathing and send client update info )object positions/events) without having to constantly transmit requests for that info to the other chunk's server.   Needless to say, that the quicker the updates are maintained between servers, the more accurate the interactions will be.   

 

When a players client institutes actions against a shadow object that action event would be (pre?) routed to the other server to take effect (it may would maintain full details to do all game mechanics calculations including with object beyond that border area which may have effects)  Results of the inetactions then get forwarded to the subscribing chunks.

 

Chunks completely out of range of a players viewing could be LOD'd down in running priority (with catch up and switching back to full detail when the player does move within range).

 

 

Now it gets fun when you have chunks with players in them being 'high priority realism' and others (adjacent)  with 'low priority abstraction'  and beyond them chunks being rolled out or being ready to be rolled into main memory when a player gets close enough.  There then would be breaking/establishing of the 'subscriptions' in a fluid manner.

 

Note-  at a grid 'corner' you can have you object in three other chunk's "shadow" lists (or worse if you have irregular chunk layouts)

 

 

 

A little more fun is : if you have seperate CPU cores running the chunks and having the update pipes either go to a whole nuther machine or just (shunt) to a different core/process space on the same machine.   At one time I did some research on lockless queues to try to minimize overhead for this kind of thing. But then I also had (many) seperate server AI nodes to run NPC units, and like a player's client, each 'smart' object could traverse between chunks and potentially maintain its own world view of many chunks it had visible.


#1wodinoneeye

Posted 21 February 2014 - 06:43 AM

It gets nasty.  Each chunk needs to maintain a border area (to a depth of any significant visible actions/events) for all of its adjacent chunks.  You then maintain a shadow copy there of any significant objects within that border area of that other chunk (you have some kind of subscription to channel updates to THIS server machine...) .   Every time something happens to those potentailly visible objects in the other chunks, the current chunk has those shadow objects updated with whatever significant state/event happenings are specified by your game mechanics..    You can now do basic visibility checks and projectile pathing and send client update info )object positions/events) without having to constantly transmit requests for that info to the other chunk's server.   Needless to say, that the quicker the updates are maintained between servers, the more accurate the interactions will be.   

 

When a players client institutes actions against a shadow object that action event would be (pre?) routed to the other server to take effect (it may would maintain full details to do all game mechanics calculations including with object beyond that border area which may have effects)  Results of the inetactions then get forwarded to the subscribing chunks.

 

Chunks completely out of range of a players viewing could be LOD'd down in running priority (with catch up and switching back to full detail when the player does move within range).

 

 

Now it gets fun when you have chunks with players in them being 'high priority realism' and others (adjacent)  with 'low priority abstraction'  and beyond them chunks being rolled out or being ready to be rolled into main memory when a player gets close enough.  There then would be breaking/establishing of the 'subscriptions' in a fluid manner.

 

Note-  at a grid 'corner' you can have you object in three other chunk's "shadow" lists (or worse if you have irregular chunk layouts)


PARTNERS