Architecture: Meta-block updates

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
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 :D

So looking at the shiny new physics stuff I noted

Code:
public void removeBlock(boolean createPhysBlock) {
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? :cool:

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 :)
 

begla

Project Founder and Lead Developer
Contributor
Architecture
Logistics
I've already implemented a observer-pattern-style notification service for anyone who needs to be notified if the player removes or adds something to the world (that's what you've found there :)). It is currently used to speed up chunk updates if the player changes something in the world.

I think it should not influence the speed if we define a set of bytes that count as special blocks and add an observer-pattern directly to the world. Kind of as you've already mentioned...:

Code:
class Chunky  {

void setBlock(..., byte type) {
  ...
  
  if (isSpecial(type) {
    parentWorld.notifySpecialBlockChanged(blockInformation, ...);
  }
}

}
This method will be called anyway but since it is used for the general access of blocks in the world, the call has to be as fast a humanly possible. So our isSpecial method is the critical part. Fastest method would be an extended if expression.

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...
Anything special can be serialized in any form we like. But i'd like to find something really, really nice here... Like the Red Dwarf Server you've mentioned. :( The asynchronous start should not be that big of a deal. I hope. :)

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.
The player is not persisted at the moment. All that is created is a small XML file that stores some metadata: the name of the world in the save directory, the spawning point, the name of the world and, of course, the seed value.

Hope I did not forget to answer anything... :shock:
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Good stuff - nice start :)

Special bytes reminds me of what I was tinkering back in the last block thread, will review and play with it some!
 
Top