So I've been thinking about how to best link together Portals and portal blocks, and want to make sure I use solid architecture on it we can use for other stuff too.
Specifically, for testing if nothing else, I was curious how to best connect the event of placing or destroying a portal block with an add/remove of the Portal object linked to it.
One somewhat natural and elegant solution (at least I'm figuring that was Sun's original intent) seemed to be Observable - a meta-block object (like a Portal) could register to the appropriate block is cares about. Block go boom, Observable makes sure the meta-block object knows. And this would probably destroy the world as I imagine that would do horrible things to performance
So looking at the shiny new physics stuff I noted
And thought okay, maybe that would be a way to create/remove blocks while also adding a little extra meta-activity surrounding something like a Portal object. Only ever use the fancy methods if you're working with a fancy block - normal chunk-loading etc would be unaffected. That could work under controlled circumstances, where for instance the World or a Player is creating a new Portal by placing a portal block.
But what about uncontrolled interactions, like when Ben starts blowing up the world with explosives?
Or even a more simple example: the player attempts to remove a portal block. Currently that block is simply set to indestructible, and gets treated like any other block. If we knew it was a special block, we could use the special removeBlock(heybtwthisisaportal). But how do we know in the first place, without checking every block explicitly as stuff is done to it? Or is that not a bad idea anyway? And if it isn't, wouldn't that just be our own homebrew Observable?
On top of that comes the fun with Persistence. Blocks are currently just stored as bytes. Do we just Serialize meta-block stuff (since there's so relatively little of it), including the coord of any associated blocks, then load on startup? With the potentially tricky bit again being that chunk loading doesn't start until after game start...
Say, how do we persist the player currently? I also see a BlockObserver class with registration and stuff, hmm, maybe I'm missing something we already have
Specifically, for testing if nothing else, I was curious how to best connect the event of placing or destroying a portal block with an add/remove of the Portal object linked to it.
One somewhat natural and elegant solution (at least I'm figuring that was Sun's original intent) seemed to be Observable - a meta-block object (like a Portal) could register to the appropriate block is cares about. Block go boom, Observable makes sure the meta-block object knows. And this would probably destroy the world as I imagine that would do horrible things to performance
So looking at the shiny new physics stuff I noted
Code:
public void removeBlock(boolean createPhysBlock) {
But what about uncontrolled interactions, like when Ben starts blowing up the world with explosives?
Or even a more simple example: the player attempts to remove a portal block. Currently that block is simply set to indestructible, and gets treated like any other block. If we knew it was a special block, we could use the special removeBlock(heybtwthisisaportal). But how do we know in the first place, without checking every block explicitly as stuff is done to it? Or is that not a bad idea anyway? And if it isn't, wouldn't that just be our own homebrew Observable?
On top of that comes the fun with Persistence. Blocks are currently just stored as bytes. Do we just Serialize meta-block stuff (since there's so relatively little of it), including the coord of any associated blocks, then load on startup? With the potentially tricky bit again being that chunk loading doesn't start until after game start...
Say, how do we persist the player currently? I also see a BlockObserver class with registration and stuff, hmm, maybe I'm missing something we already have