Blocks - Classes or Types?

[Cervator]

So it has been a ways since my Java dev days and I'm rusty

I'm now torn between the developer half of my brain and the automation half.

With the thought of ending up with a lot of subtly different blocks over time (geology concept), is it better to do one class per unique block, or generic block type classes with exact properties loaded from somewhere else? I like the object-oriented nature of one class = one unique block, but my automation-side screams "risk of higher maintenance!" when thinking about making dozens of slightly different ore blocks - should one facet change for a pile of them at once one day.

Currently it looks like all the specific blocks are direct children of the Block class. Should the goal perhaps be to come up with a small superstructure of block type classes, so if we do get one class = one block for everything at least if an attribute affecting all trees change one day we can edit it once in an abstract TreeBlock class that all types of trees inherit from? Or are the benefits of one class = one block low enough to where it would make more sense to only have one TreeBlock class and just instantiate with with different properties based on what kind of tree we're generating?

I'm happy to give building up a viable class structure like that in my branch while tinkering with geology, but thought I'd ask for some thoughts first

 

[begla]

Yes, of course. We should change the architecture for the blocks. I designed the current architecture to be fast and easy to implement. Not to be scalable.

Currently there is only a handful of properties. The color value (while some blocks take their color value from a special texture based on the humidity and temperature), rendering properties, the position of the texture in the texture atlas and so on. Most of them are primitive datatypes.

The best way would be to move the primitive properties to the base class "Block" and load them from a XML structure. Extended properties, like the variable color of some blocks, can be implemented using subclassing. This would lead to only one class for most of the blocks at the moment, while the grass and leaf blocks get an unique class which provide the lookup functionality for the color value.

I will implement this. But lets get the concept down first... Thoughts?

 

[Cervator]

Not sure yet, thus the thought to tinker a bit. Important topic since I imagine it'll have a major impact on networking / data transfer in particular

For geology and related "layers" of generating the fun stuff inside a Chuck you'd probably also be reading the surroundings to base stuff on. Like basing the size of a Peat deposit on the size / proximity of a river or other water source.

Over longer-term in multiplayer it might be worth tracking if a specific player has "touched" a block (for anti-griefing, estate marking, scoring, etc)

In something like Red Dwarf Server you just make sure everything is Serializable and the framework pretty much handles the rest as far as networking goes. But I'm not convinced that's the most efficient way to do it, even if it is easy.

Must tinker and review - might not have a lot of time to do that for a bit, busy with normal work and prep for an IT startup event in town this weekend

 

[begla]

Okay, take your time and let me know when you got a good idea!

The current "Block" classes are only used as a simple way to store the global properties of the blocks. The actual chunks contain byte values. The block types are saved using a complete byte (so we got a maximum of 256 possible block types) while lighting data is split into two nibbles to reduce the memory overhead (which makes a total of 16 different shades).

For the things you mentioned in multiplayer we'll need some sort of database to store additional data.

 

[begla]

Thinking of... I'll have to add a nibble array for storing additional block data in the near future, so we can store for example block states (pressure plate down/up, grass block covered in snow and so on).

 

[Cervator]

Could an array like that also be used to store a sub-block setup? Say if you gain the ability to chop one block into 2x2x2 smaller blocks, any one block with a set config of any of those 8 could be remembered? Custom blocks / furniture /stairs / stuff like that

Although I imagine that opens a bigger can o' worms..

 

[Cervator]

Looking a bit at the code during my lunch break, that's totally not cheating

I get how the blocks work better now, makes sense. Byte corresponds directly to the block type in _blocks and each block specific class just overrides behavior methods so to say. How are the nibbles stored / used?

For extended data any chance a second chunk file could be used to store actual class data per block? That wouldn't load unless needed (everything for rendering stored in the main byte array or the fancy nibbles). That's probably my rust talking and would either be impossible or bloat-city

At just 32 bytes per block that would make each chunk about two MB, wee. And yeah, something like "owner" would have to be a DB key reference anyway..

 

[begla]

Could an array like that also be used to store a sub-block setup? Say if you gain the ability to chop one block into 2x2x2 smaller blocks, any one block with a set config of any of those 8 could be remembered? Custom blocks / furniture /stairs / stuff like that

Although I imagine that opens a bigger can o' worms..

The current arrays are used in the chunks can only be used for blocks that can be perfectly aligned in the overall grid. Things like smaller physics enabled blocks have to be removed from the grid and rendered separately and thus have to be stored separately.

But if you mean to create something like a miniature, for that those data structures can be used perfectly. This would be nothing more and nothing less than a miniature version of the current world in the world. :shock: I'm thinking about your blueprint concept.

 

[begla]

Looking a bit at the code during my lunch break, that's totally not cheating

I get how the blocks work better now, makes sense. Byte corresponds directly to the block type in _blocks and each block specific class just overrides behavior methods so to say. How are the nibbles stored / used?

For extended data any chance a second chunk file could be used to store actual class data per block? That wouldn't load unless needed (everything for rendering stored in the main byte array or the fancy nibbles). That's probably my rust talking and would either be impossible or bloat-city

At just 32 bytes per block that would make each chunk about two MB, wee. And yeah, something like "owner" would have to be a DB key reference anyway..

Exactly. For the nibbles I've created a special 3D byte array class which can be initialized with a size (like any normal array) but uses only half the space in the end. Java does not allow data types smaller than one byte, so I had to create an array with half of the amount of byte values defined by the initial size and save the 4-bit data split across the available bytes in the array. So one byte contains two 4-bit values split across the nibbles. The class is just responsible for mapping the requested position to the right nibble.

Creating a second chunk file can be problematic since the memory usage can become quite problematic quite fast. So, if you ask me, we're going to be limited to simple 4-bit values (16 states per block) which can be interpreted differently for each block type. But this is solely related to blocks in the world grid.

Minecraft, for example, stores even entities on a per chunk basis (at least in the alpha level format). I would not do that... Those could be stored in an external file which contains the entity information (position and type for example) on a global basis (not on a per chunk basis).

If there is anything in the world, which differs from normal blocks, it should be treated as an entity. The blocks in the grid are only built the way they are to be rendered efficiently. But it does not hurt to render some more entities in addition to the blocks and store them somewhere else. At some places it might even become transparent if it is normal block or something special like a physics enabled block. In Minecraft sand, for example, is removed from the voxel-grid, rendered and animated independently and put back into the grid at the new positions when the animation/movement finished.

 

[Cervator]

More musings from a quick post-lunch walk (which I didn't finish before you posted again, so might read jumbled now!):

Most the world will be made up of PrimitiveBlocks which correspond directly to one of the existing 256 slots in the main byte array and do nothing special other than override behavior methods and stuff.

For advanced blocks start at the end of the byte values and define block 255 as a special block that subclasses into more fun stuff of a particular type (say trees, although I'm not sure trees need to subclass..). When the world then runs into a byte value 255 it defers to a secondary data structure like a fast Collection of some sort or even a DB. That avoids writing a second chunk file as you only store expanded data for each special block.

If we need to know something about a specific block you'd pull out an object matching a key made up by the index of the location in the world - finish calc, done, move on to next block.

I might be getting "what's up with this one block" mixed up with "here's a custom fancy type of block but we're not talking about one exact block in the world" - but I'll sort out my head sometime and put something clear in the wiki, this is just brainstorming

Now, one type of special block might be a blueprint mini block, and yeah, that's where it gets fun! Take stairs as an easy example. They can be made out of assorted different materials, but say you prototype one at full size in a workshop that allows you to place exactly 2x2x2 full-size blocks in a particular spot, then hit a button or what not to say "Make me a smaller block that looks like this"

New block generates which at this point could be made up by 8 bytes - each byte corresponding to the PrimitiveBlock values as that's what the block is made up by. Shrink the original texture a bit and tadaa, you've got a two-step stairs block that can now be saved with a particular ID somewhere and be re-usable as a blueprinted item. A CompositeBlock maybe?

Get a fancier workshop that takes more effort to construct and maybe now you can miniaturize better and do a 3x3x3 block. Make stairs again and this time you end up with a 3-step stairs block made up of 27 byte references to specific PrimitiveBlocks. Exactly how a 2-step vs a 3-step stairs block would compare or be useful I dunno.

I'm sure there are better ways to optimize that like require only one material type, but I'm just trying to think in concepts for now

For instance after defining a set of stairs like that it gets that ID and you use that instead of worrying about which mini-blocks make it up each time...

So now that I've written that "Entities" get introduced, wee - more stuff to look into a bit then and learn more

Could probably do the stairs with nibbles instead of bytes for starters, if you'd be limited to make stairs out of 16 different types of materials... which might not work, nor matter if you just define the individual blocks in a blueprint structure once rather than in the world for every single instance of the block...

At what point does the memory conservation efforts start running into processing limits tho? It's got to be a trade-off with a balance somewhere. You could use individual bits in some places if you really wanted to.

Adding a bit on workshops you could have a container as part of it where you put material for the mini blocks, it then gets grabbed from there when you hit the button. Maybe there's a preview screen of stored blueprints you can scroll through to tell the machine what block you want to generate. Better workshops increase the efficiency of material consumption. The most rudimentary type of workshop could cost 100% of the original block structure to create a single mini-block giving incentive to make better workshops.

Maybe eventually you could do red-stone like wiring inside 10x10x10 workshop blocks, miniaturizing what in MineCraft takes a whole engine room into a single block. Tho at some point you need to ensure that the graphical representation of the mini-block doesn't overwhelm the world. Perhaps a new texture could be generated per custom block (a composite of the parent blocks) and stored somewhere?

Incidentally, I love the idea of solid tiny blocks (of copper!) as "wires" like that rather than a weird flat texture that takes up a whole side of a block, but I can only imagine how much easier and efficiency plain textures are...

 

[Adeon]

I'd like to expess my opinion on the way to store the data of the block
I think we should use only one basic class instead of a set of classes.
And we may use xml format for storing the data of the block.
This will give a user a more simple way to add a new block type.
But unfortunately there's one problem. We'll have to read the catalog from xml during every loading of the game.
In this case we can solve the problem the following way - we'll read all the xml only once. Then we'll serialize the resulted array into one file.
And during all the following loadings we'll only have to watch the fingerprint of the catalog from xml.
And if it hasn't changed since the passed loading of the game we'll read from our "cache"

 

[Cervator]

Do you think that's "future-proof" in a multiplayer situation where you could have hundreds of custom blocks?

 

[begla]

Do you think that's "future-proof" in a multiplayer situation where you could have hundreds of custom blocks?

I'm currently migrating the system to a XML-structure based approach so we can evaluate the concept. I'll also provide a look up mechanism so we don't have to juggle with byte values all the time...

Storing the blocks somewhere else in addition to the XML structure will not be necessary. I don't like the idea of storing something somewhere twice.

 

[Cervator]

Keep an eye out for any DB fun related to the XML structure setup then, in case we go that way in the future for multiplayer and what not

 

[begla]

Done. Works flawlessly and fast (but needs some further testing). Blocks can be access via the title or directly using the id. I've also added a new property to define liquids (so swimming in lava is possible ). Quicksand for example could be added very easily too.

It is possible to define a color source (0: directly uses the color offset, 1: uses the biome's color * color offset, 2: uses the biome's foliage color * color offset). This allows the definition of different types of leaves for example (dark and bright ones).

This is the new XML file...

<blocks>
    <block id="1" title="Dirt">
        <property name="textureOffset" x="2" y="0"/>
    </block>
    <block id="2" title="Sand">
        <property name="textureOffset" x="2" y="1"/>
    </block>
    <block id="3" title="Stone">
        <property name="textureOffset" x="1" y="0"/>
    </block>
    <block id="4" title="Wood">
        <property name="textureOffset" x="4" y="0"/>
    </block>
    <block id="5" title="Tree trunk">
        <property name="textureOffsetTop" x="5" y="1"/>
        <property name="textureOffsetBottom" x="5" y="1"/>
        <property name="textureOffsetLeft" x="4" y="1"/>
        <property name="textureOffsetRight" x="4" y="1"/>
        <property name="textureOffsetFront" x="4" y="1"/>
        <property name="textureOffsetBack" x="4" y="1"/>
    </block>
    <block id="6" title="Grass">
        <property name="colorSource">1</property>
        <property name="textureOffsetTop" x="0" y="0"/>
        <property name="textureOffsetBottom" x="2" y="0"/>
        <property name="textureOffsetLeft" x="3" y="0"/>
        <property name="textureOffsetRight" x="3" y="0"/>
        <property name="textureOffsetFront" x="3" y="0"/>
        <property name="textureOffsetBack" x="3" y="0"/>
    </block>
    <block id="7" title="Snow">
        <property name="textureOffsetTop" x="2" y="4"/>
        <property name="textureOffsetBottom" x="2" y="0"/>
        <property name="textureOffsetLeft" x="4" y="4"/>
        <property name="textureOffsetRight" x="4" y="4"/>
        <property name="textureOffsetFront" x="4" y="4"/>
        <property name="textureOffsetBack" x="4" y="4"/>
    </block>
    <block id="8" title="Ice">
        <property name="textureOffset" x="3" y="4"/>
        <property name="translucent">true</property>
        <property name="blockForm">2</property>
    </block>
    <block id="9" title="Water">
        <property name="textureOffset" x="15" y="12"/>
        <property name="blockForm">2</property>
        <property name="hardness">-1</property>
        <property name="penetrable">true</property>
        <property name="renderBoundingBox">false</property>
        <property name="bypassSelectionRay">true</property>
		<property name="translucent">true</property>
		<property name="castsShadows">false</property>
		<property name="liquid">true</property>
    </block>
    <block id="10" title="Lava">
        <property name="textureOffset" x="15" y="15"/>
        <property name="luminance">15</property>
        <property name="blockForm">2</property>
        <property name="hardness">-1</property>
        <property name="penetrable">true</property>
		<property name="castsShadows">false</property>
		<property name="liquid">true</property>
    </block>
    <block id="11" title="Leaf">
		<property name="allowBlockAttachment">false</property>
        <property name="textureOffset" x="4" y="3"/>
        <property name="colorSource">2</property>
        <property name="translucent">true</property>
        <property name="noTessellation">true</property>
    </block>
	<block id="12" title="Dark leaf">
		<property name="allowBlockAttachment">false</property>
		<property name="colorOffset" r="0.8" g="0.8" b="0.8" a="1.0"/>
        <property name="textureOffset" x="4" y="3"/>
        <property name="colorSource">2</property>
        <property name="translucent">true</property>
        <property name="noTessellation">true</property>
    </block>
    <block id="13" title="High grass">
		<property name="allowBlockAttachment">false</property>
        <property name="colorSource">2</property>
        <property name="blockForm">3</property>
        <property name="renderBoundingBox">false</property>
        <property name="translucent">true</property>
        <property name="textureOffset" x="12" y="11"/>
        <property name="penetrable">true</property>
    </block>
    <block id="14" title="Medium high grass">
		<property name="allowBlockAttachment">false</property>
        <property name="colorSource">2</property>
        <property name="blockForm">3</property>
        <property name="renderBoundingBox">false</property>
        <property name="translucent">true</property>
        <property name="textureOffset" x="13" y="11"/>
        <property name="penetrable">true</property>
    </block>
    <block id="15" title="Large high grass">
		<property name="allowBlockAttachment">false</property>
        <property name="colorSource">2</property>
        <property name="blockForm">3</property>
        <property name="renderBoundingBox">false</property>
        <property name="translucent">true</property>
        <property name="textureOffset" x="14" y="11"/>
        <property name="penetrable">true</property>
    </block>
    <block id="16" title="Red flower">
		<property name="allowBlockAttachment">false</property>
        <property name="colorSource">2</property>
        <property name="blockForm">3</property>
        <property name="renderBoundingBox">false</property>
        <property name="translucent">true</property>
        <property name="textureOffset" x="13" y="0"/>
        <property name="penetrable">true</property>
    </block>
    <block id="17" title="Yellow flower">
		<property name="allowBlockAttachment">false</property>
        <property name="colorSource">2</property>
        <property name="blockForm">3</property>
        <property name="renderBoundingBox">false</property>
        <property name="translucent">true</property>
        <property name="textureOffset" x="12" y="0"/>
        <property name="penetrable">true</property>
    </block>
    <block id="18" title="Hard stone">
        <property name="hardness">-1</property>
        <property name="textureOffset" x="1" y="1"/>
    </block>
    <block id="19" title="Cobble stone">
        <property name="textureOffset" x="0" y="1"/>
    </block>
    <block id="20" title="Brick">
        <property name="textureOffset" x="7" y="0"/>
    </block>
    <block id="21" title="Coal">
        <property name="textureOffset" x="2" y="2"/>
    </block>
    <block id="22" title="Silver">
        <property name="textureOffset" x="1" y="2"/>
    </block>
    <block id="23" title="Red stone">
        <property name="textureOffset" x="3" y="3"/>
    </block>
    <block id="24" title="Gold">
        <property name="textureOffset" x="0" y="2"/>
    </block>
    <block id="25" title="Diamond">
        <property name="textureOffset" x="2" y="3"/>
    </block>
    <block id="26" title="Glass">
        <property name="translucent">true</property>
        <property name="textureOffset" x="1" y="3"/>
    </block>
    <block id="27" title="Bookshelf">
        <property name="textureOffsetTop" x="6" y="5"/>
        <property name="textureOffsetBottom" x="6" y="5"/>
        <property name="textureOffsetLeft" x="3" y="2"/>
        <property name="textureOffsetRight" x="3" y="2"/>
        <property name="textureOffsetFront" x="3" y="2"/>
        <property name="textureOffsetBack" x="3" y="2"/>
    </block>
    <block id="28" title="Cactus">
        <property name="translucent">true</property>
        <property name="noTessellation">true</property>
        <property name="blockForm">1</property>
        <property name="textureOffsetTop" x="5" y="4"/>
        <property name="textureOffsetBottom" x="5" y="4"/>
        <property name="textureOffsetLeft" x="6" y="4"/>
        <property name="textureOffsetRight" x="6" y="4"/>
        <property name="textureOffsetFront" x="6" y="4"/>
        <property name="textureOffsetBack" x="6" y="4"/>
    </block>
    <block id="29" title="Color black">
        <property name="textureOffset" x="1" y="7"/>
    </block>
    <block id="30" title="Color blue">
        <property name="textureOffset" x="1" y="11"/>
    </block>
    <block id="31" title="Color brown">
        <property name="textureOffset" x="1" y="10"/>
    </block>
    <block id="32" title="Color green">
        <property name="textureOffset" x="1" y="9"/>
    </block>
    <block id="33" title="Color purple">
        <property name="textureOffset" x="1" y="12"/>
    </block>
    <block id="34" title="Color red">
        <property name="textureOffset" x="1" y="8"/>
    </block>
    <block id="35" title="Color white">
        <property name="textureOffset" x="0" y="4"/>
    </block>
    <block id="36" title="Torch">
		<property name="allowBlockAttachment">false</property>
        <property name="textureOffset" x="0" y="5"/>
        <property name="blockForm">3</property>
        <property name="luminance">15</property>
        <property name="translucent">true</property>
    </block>
</blocks>

 

[Cervator]

Cool. Saw it pop up in the code earlier. Won't get time to tinker/test until after the weekend tho, the local startup event I'm attending starts in about 4 hours and lasts for the whole weekend. On the plus side I hope to dig up some potential new friends to help out with fun stuff like this

 

[begla]

Cool. Saw it pop up in the code earlier. Won't get time to tinker/test until after the weekend tho, the local startup event I'm attending starts in about 4 hours and lasts for the whole weekend. On the plus side I hope to dig up some potential new friends to help out with fun stuff like this

Potential new friends! Yey!

 

[Cervator]

Startup event went alright, although I picked team poorly after my pitch turned out to be out of place (wasn't a pure IT crowd as I had expected, more than half were completely non-technical idea-only people). I helped a group with a rewards points system for networking small businesses and what not, but I think there was too much businessy talk and too little technical. We ended up presenting a giant powerpoint and no product, despite me making a working prototype - alas!

Still haven't caught up on sleep. I don't regret it though, I've made some more contacts, and will start attending monthly entrepreneur meetings hoping to find more. Didn't catch a specific big group I had hoped to work with, with the secondary sneaky plan to introduce them to Blockmania when not focusing on the main app. But I think it'll just be a question of doing it over a longer period instead.

Should finish decompressing in a day or two, then I'll fight down the beast known as git integration with IntelliJ and figure out how to properly start working on the code here

 

[begla]

Startup event went alright, although I picked team poorly after my pitch turned out to be out of place (wasn't a pure IT crowd as I had expected, more than half were completely non-technical idea-only people). I helped a group with a rewards points system for networking small businesses and what not, but there were too many business types stuck about a decade back. We ended up presenting a giant powerpoint and no product, despite me making a working prototype - alas!

Still haven't caught up on sleep. I don't regret it though, I've made some more contacts, and will start attending monthly entrepreneur meetings hoping to find more. Didn't catch a specific big group I had hoped to work with, with the secondary sneaky plan to introduce them to Blockmania when not focusing on the main app. But I think it'll just be a question of doing it over a longer period instead.

Should finish decompressing in a day or two, then I'll fight down the beast known as git integration with IntelliJ and figure out how to properly start working on the code here

Cool! Let me know if you need any help with that. My new semester just started and I'm working on two projects at my university. So I got not as much time for Blockmania for the time being, but the project still has the highest priority for me.

So please don't wonder if I'm not commiting twenty times a day. I'm still on it.

 

[Cervator]

Thought popped up while taking to a friend (who of course I'm trying to convert to a contributor eventually!)

MC has 1 mined block = 1 placed block with almost infinite player inventory (can keep mining for ages and take up little to no space)
DF has 1 mined block <= 1 placed block depending on miner skill, but pretty easy to skill up dwarves to = 1 for most materials - but the blocks drop to the floor and lay around causing a mess with no super solid ways to store them in vastly less space

That doesn't cover gems which realistically should be far smaller and essentially are in both games (even if MC stone blocks are the same "tiny" size as far as inventory goes when I'm not sure they should be)

MC is very easy but sort of silly, while DF is overly accurate in wasted space. Neither does any related physics.

Going back to the possibility of having 1 mined block split into 2x2x2 smaller blocks for some limited realism, ability to physics-enable the blocks to make them realistically tumble around, and introduce a "cost" to re-assemble normal sized blocks - I wonder if it could make sense to have the 8 smaller blocks actually be sized to make up a big block again only as 3x3x3 or 27 total blocks with only 8 produced per block mined? Probably with variations on the target material

Thought is that there's "waste" in mining blocks, which could be indicated in getting less than a full block from mining one (getting 8 blocks sized at 1/27th each would be a yield around 30%), then having to mine more to be able to re-construct big stuff. In a pure creative game that would really suck, but in a resource gathering focused game with the angle of minions to help do the mining and crafting for you...

You could then also introduce more realistic inventory & storage options, and have the mined blocks temporarily physics-enable for a satisfying jumble of rocks thanks to them being smaller in an open space (you wouldn't see much movement replacing a metric block with 2x2x2 physics-blocks that together are the exact size of the hole they got mined out of...). Minions could pick them up, but have a limited inventory so they'd need to drop off occasionally, with the player having a larger but still distinctly finite inventory as well.

Another related angle is smashing things with bigger things, like the delicious "catapult vs wall" instance resulting in a yummy mess...