Too much or not enough - Defining more blocks VS SubstanceMatters

chessandgo

Member
Contributor
Hunter
Should we make increasiningly more small usecase blocks, or adopt SubstanceMatters (https://github.com/Terasology/SubstanceMatters) for blocks with only slightly different behavior, or perhaps a blend. In this usecase, the Soils library

as it currently exists, https://github.com/Terasology/Soils/tree/master/assets/blockTiles/auto ,

we have 3 types of soil with 3 conditions. Average, Poor, Rich; Wet, Damp, Dry. Which is indeed nice, and gives us the benifite of multiple soil types for varied farming and biomes, such as different textures, how ever, they lack depth, and in order to create truelly dynamic soil, we're either going to have to define soil types by the thousands, or adopt SubstanceMatters.

For example, we could fit every soil type we currently have in one block, with the properties of how wet it is,and its quality. But theres no reason to stop there. Have each of those go on a scale of 0 to 99, and thats 1,000,000 (100*100*100) different soil types, vs, 9 (3*3). But theres still no reason to stop there. Add in specifics, stuff like, carbon, nitrogen, beneficial bacteria, calcium, magnesium, phosphorus,lime, bone meal, Vermiculite, blood meal, compost, manur, coir, coffee grounds, compost tea, biosoilds ,hydroabsorbant polymers, sphagnum moss, peat, mass, densitiy, etc. and you have a very high level functioning system to build dynamic farming and ecology off of. adding those all together and thats, 100000000000000000000000000000000000000000000000000 soil types, that can adjust themselves as plants take in and put out nutrients . How ever, that is a lot of data (well, stored, we could put it in slightly less than 22 bytes, but it depends on how the module/java is storing these values)


So perhaps, the extream is not the best. After all, if we do this we only have one texture. So perhaps, we need to create atleast a decent amount of soilblocks, in order to offload some of the data, and to allow different textures. (having a 100 (or more) blocks defined for wetness seems like a good standard, but then a plant drawing water out of blocks would have to change its ID)


If water remains a blocks, this would perhaps also be a good system for defining water pressure/mass/density, temp, contamintents, etc.






Perhaps this will also help us sort out the soil library with clear cut guidelines.. I'm planning to add sands to it, but perhaps those belong in the mineral library, or their own.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Moved to Dev Portal since this is more of a discussion than a module home :)

I think this is likely to be too specific - it'll depend too heavily on the modules involved / gameplay template / individual authors.

The use of the Biome per-block data available would likely be related too.

I'd like to see the block assets simply stick with realistic base types and maybe rough variants (like the soil dryness types). In some cases they might then be diversified via biome or other extensions in data (not appearance). Rather than substance matters, which is really more for having items take on the appearance of a particular material, I think we need a component module for advanced soil and mineral metadata. I've talked about that in the past but am unsure if I have notes in the forum, on my computer somewhere, or only in my head ..

First step is simply defining what base attributes we might want to track.

Down the road any resulting refined materials is a whole other topic on its own. There SubstanceMatters and any extended block metadata module would go into use.
 

manu3d

Active Member
Contributor
Architecture
Isn't this something that can be dealt with via facets? I'm not familiar with their inner working but by my understanding any property of the landscape can be provided by facets, right? I.e. the humidity of a given block could be provided by a HumidityFacet, its bacterial content by a BacterialFacet and so on?
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Facets are more high level: a river can be created by a facet, as can a tree, or a village, and so on. They guide world gen but do not store any block-level data (that comes after rasterizing facets into actual world)

Individual block details can be affected by facets alright (is this area supposed to be more fertile instead of arid?) but I think @chessandgo is hunting more for block metadata considerations. How you actually get to that point is less pertinent. More of a topic of how you distinguish between a fertile area and an arid one at a block definition level (for use in growth sims or mining output). If my understanding is correct anyway.

I think base block variants + expanded material metadata (mineral or soil type components) + the space we have in the biome id would cover a lot of the options. You don't need to persistently store entities with the expanded metadata components attached, but on breaking a block (or pulsing a growth system) you can do a check of the involved pieces to make any advanced considerations.

Not a super critical topic at the moment, but some high level design philosophy wouldn't be out of place to help guide.
 

manu3d

Active Member
Contributor
Architecture
So, for a given chunk, do facets cease to be usefel after rasterization?
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
So, for a given chunk, do facets cease to be usefel after rasterization?
I believe so, but @Josharias / @msteiger / @Florian / etc please correct me if I'm wrong.

This is one spot where we have more work to do. In the past efforts like those by @Nym Traveel got us climate simulators and all kinds of neat things. PlaTec may have extra data than what we import in a single layered height map. But we don't really have anywhere to leave that data (my understanding).

Facets are deterministic, they have to be for world gen to remain efficient and able to use static noise. But we need to be able to maintain world at a high level after generation. World/chunk entities get us part of the way there (pretty sure I'll be getting some details wrong here). If you have a river what chunks does it flow through and how much water does it carry? What happens if the player dams the river in one spot and it is redirected?

We need that kind of stuff to be able to create dynamic world maps and simulate stuff outside of loaded chunks (again, for efficiency you want to be able to simulate water flow without having to rely on block-level data)

Fertility changing over time and in turn impacting growth simulation (and what blocks might represent the details when chunks are loaded) would be another piece of the puzzle.
 
Top