Suppose I wanted to make a massive open-world style game in real time that works completely in the browser, and I wanted to use Firebase for this.
Let safety questions also be left aside; I will ask them later. (=
Players start at (0,0) and can move in any direction. I spatially hash the world so that any given x, y coordinate becomes the only (or nested) key that I can use to create refb firebase:
var getKey = function(x, y) { return Math.floor(x / 100) + ':' + Math.floor(y / 100); } var key = getKey(currX, currY); var ref = new Firebase('https://whatever.firebaseio.com/world/' + key);
Something like that. When a player moves around the world, I'm sure I will need somewhere between four and nine links to Firebase alive in order to get the changes. This can double or triple depending on how I structure the data: are other players stored in the world/
tree or somewhere else? That kind of thing.
I do not want the playerβs browser to receive updates that it does not need. I would like to "outdate" old links when a player moves, so the browser does not spend resources on frequent conversations about distant environments of the world.
Is it enough to let the ref instance go out of scope and get a GCed? Or is there something else I have to do to notify ref that I no longer want to use it?
Another thing I was thinking about was not worrying about how many links there are, but tracking on
callbacks. When a player goes out of range of a certain part of the world, I could off
perform any callbacks. Would it be enough for my links to stop talking to Firebase?
source share