Block Dynamics

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
So this design piece is way overdue, but finally a comprehensive view of what I have in mind along with references to related stuff out there

In short, as opposed to meta blocks that are "fancy" blocks with bigger concepts attached to them (like Portals or simple Doors) Block Dynamics are meant to make normal blocks more "lively" by adding more metadata to them (extra values for every block). Since they're expected to exist for every block I've put some thought into making them multipurpose based on the primary block type so no substantial block space goes wasted. The two two primary new data values are:

* Secondary resource (an "amount") - would cover liquid level in liquid blocks, moisture level in dirt blocks or plants, aquifer fun in certain layers, oil in certain stone layers, natural gas in others, moisture possibly in air blocks for weather effects. etc
* Support / integrity / pressure (an "intensity" of sorts) - would cover concepts like unsupportable blocks falling down, liquid pressure allowing advanced liquid features (think lava bubbling upwards in a volcano crater, or water being pumped through pipes), and possibly wind strength/force in Air blocks for more weather effects

In addition to these two big ones you could possibly consider lighting effects block dynamics too. Likely they'll all be stored in similar ways (initially in TeraArrays and TeraSmartArrays, maybe later in fancy metadata lookups), and they'll update as world time progresses (at different intervals). So ultimately similar processing systems would hit all these things. More details on storage suggestions over at viewtopic.php?f=4&t=173
(EDIT waaaay later, updated link)
While that may sound like a mouthful, it really is more of a foundation allowing all those crazy advanced systems at some point in the future. The basic systems (like block integrity) are actually fairly straight forward to implement, there's just a lot of tweaking to get the feel right. I did a proof of concept a little ways back

http://pastebin.com/uG4iQa37 - updated Chunk.generate() snippet
viewtopic.php?f=4&t=171 - original thread with a screenie showing said snippet enabled (EDIT waaaay later, I think this is the thread this was linked to)

.... *time passes*: argh, and it is midnight. Does it show I find fewer smaller chunks of idle time these days? And I'm not alone, seems like everybody was on spring break for the crazy hectic activity earlier. Will tweak this more tomorrow :)
 

ironchefpython

Member
Contributor
Architecture
How would this interact with a "modding" system?

There are three types of mods I'm thinking of that would add additional metadata to blocks.

(Every block) The hypothetical "Winter is Coming" mod assigns a temperature to each block, runs a separate thread to attempt to equalize temperatures between blocks, and when a water block falls below 0 degrees Celsius, converts it to an ice block.

(Some classes of blocks) The hypothetical "Cold Fusion" mod needs to track the amount of heavy water (deuterium) in each water block.

(Special blocks) The hypothetical "hot or not" mod allows users to rate specific individual blocks according to physical beauty.

Have you considered the mechanism for allowing additional metadata to be added to blocks, ideally at runtime?
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Welcome, ironchefpython, and thanks for the good question :)

I expect the exact way we store block metadata will change, and exactly to what I'm leaving up to the more wizardly types around these parts. The related architecture thread at viewtopic.php?f=4&t=173 has some suggestions, I'm honestly not sure which is best suited for modding.

At the same time I know Immortius is working on integrating some DB potential, which may offer us yet another option for storing and modding this sort of data.

The second and third scenarios may be better served with entity system backed single block components meant to store the extra data. We might need to performance test that when we get closer code-wise to having something to tinker with. For all I know the DB option might prove fast enough to use for all blocks period, but I'm somewhat dubious of that in favor of the byte-based block ID lookups.
 
Top