Multiple reference to the same object

Networking & Multiplayer
#1

Hi

I seem to have ended up in the situation where I need 2 access mothods to my game objects. The game area (think oct tree) that contains the objects needs to access all of them in one game tick (server side collision detection), this is a longish running task (8ms processing on the client with 201 objects), whilst at other times, I want access to just a single object (when a player sends an update). If I make every object a managed reference, then the player updates are scalable, they access a fine grained object, meaning other objects can also be updated at the same time in other transactions. When I come to do my game tick, I really don’t want to do 202 separate database reads, followed by potentially 201 writes when the server dictates the results of the collisions. I would like the sector to read the whole thing in in one go, do it’s work, and write it. This requires less accessing of the db, which should improve performance in the case where I need every object (which I do here).

On the flip side, this would mean that each time I get an update from a client, I need to get the whole sector out of the store.

What happens if I stick a bunch of GameObjects in an array list in the sector, and have a managed reference to individual objects attached to the ClientSessionListener?, does it work?, does it provide fast access in both situations?

The alternative, is to queue client updates and process them when the sector tick happens, but I already have situations where the sector is read to send to new players, and by queueing player updates up, new players would be out of sync before they even started. This might not be such an issue though, as player updates are also sent on channels at mch higher frequencies, but these are treated in the client as advisory, not authorative.

Cheers

Endolf

#2

No. This is a logical error that breaks the model and the server will scream bloody murder at you any time you try to save a managed object which contains direct Java references to other managed objects.

This is because to allow this would be very deceptive. You would’t get two different ways to access one object, you’ld get two separate and distinct objects; one that is part of the state of the list and one that is an independent managed object.

IF you wanted to have the same KIND of data in both places the thing to do is define a non managed object that is effectively your structure and \“wrap\” it in a managed object wrapper for storage as a managed object.

But honestly, what it really sounds like you want is not the same thing updated in two different places but a more intelligent structure for storing it all in Managed Objects so you don\'t have to be loading thousands of them every time.

Consider an octree to subdivide your objects into groups spatially (assuming this is a spatial game.) Also, consider a simplified collision geometry like a walk mesh for static geometry. This will scale better for many users, anyway.

#3

Thats what I was concerned about. My data is already (or will be) in a spatially devided structure, probably an oct tree, I guess I will have to find the optimum size of the node based on how many objects I want to get each time. I suspect that I’ll end up with a queue of player updates that have not been processed, and check this queue when updating the nodes in the tree. Otherwise I’m going to get in to troubles with the number of objects I read from the database, what ever size I end up with.

Endolf

#4

Well… im just talking out of my hat now but…

If your primary operations are spatial then thats probably how you want to think about organizing everything else.

Something I discovered in writing BHO was how important it was to decouple the large periodic action (the GameBoard ticks) from the input from the users. I also discovered that, although my first instinct was to queue all user input, in a game with such close synchronization it actually made more sense to throw out all but the last one recieved and to gate on the user\\\\\\\'s end when he could send another.

So what I did was have every user number his commands sent to the server sequentially. The serve tracks the last number processed. This way I can \\\\\\\“expire\\\\\\\” a command after its sued without actually having to share access to a data structure.

Again this is all very specific to how BHO works and the kind of game it is,

If you really need to queue, you might want to look into lock-free queuing structures and how these could be implemented inside the SGS. Its something we have on our list to do when we have time… (we\\\\\\\'re accepting donations of spare round-tuits :wink: ) Maybe a ring buffer? I’m imagining that could be implemented in a similar manner… hrmm… may want to try that as an evening experiment some time soon…