It’s a good idea as far as getting more feedback goes, but I doubt it would speed things up a bit. Remember that you’d need to organise the release and feedback collection (and the expectations of players) of/on the unstable builds, an that takes time as well.
2 Likes
Yeah, this is a common misconception about releasing unstable builds to the public – it often makes the process take significantly longer, rather than creating a shortcut to a successful prototype.
While I don’t think @SirAstrix was implying something so reductive as “use unstable builds to save time”, I reckon that someone, somewhere is getting pretty close to saying it. I’ve seen it splashed around on other forums so often, I pretty much assume that the sentiment is found everywhere there’s an Early Access/indev release in progress.
But getting back to your point: yes, the feedback cycle does add time to the whole process. And while that feedback can be invaluable, sometimes it’s just… not. Sometimes it’s a common-sense observation, sometimes the feedback is already out of date by the time it’s collated/read, and sometimes it’s not detailed enough (or worse, it’s left vague on purpose to avoid hurting anyone’s feelings) to be much help.
A great example of this is with Oxygen Not Included, the current masterpiece underway at Klei, who have a long and proud history of successes in the Early Access environment. They know pretty well what they’re doing by now, and ONI is already very popular. But, controversially, the top brass at Klei decided to break their Early Access process down into two groups – the public release, and a very limited group for much more experimental and unstable releases on a much shorter cycle. Their reason, boiled down to the simplest terms, is that they were getting so much feedback that it became impossible to keep up with it, and a lot of it was duplicated or not helpful. So, they decided to turn to a select group of players who had given a lot of useful feedback to them in the past, and use those guys to test out the janky experimental builds, while keeping everyone else on the stabler releases. This allows most of their players to build with a version of the game which is functional, and they can have fun with things like developing “meta” strategies or engineering new ideas (and these are core parts of ONI’s gameplay, so they’re crucial things to be trying out during Early Access); while the players who are reaaaaaaally interested in cutting-edge releases and testing things like bugs and experimental ideas can do that without exposing everyone else to the sheer craziness which comes with that territory.
Anyway, that’s just one example of how another group is making use of different release builds to get different kinds of feedback. How applicable it is to Stonehearth is something the devs would need to consider, although I’m sure that if they floated the idea of having a more experimental branch (I mean even more than Unstable!) there would be plenty of us who’d want in. And hey, there may well come times when it’s worth releasing a few different “side” branches, each with a different set of ideas for a new feature, to see which works best for the largest group. But taking that road means keeping multiple branches in play at the same time, so it’s something I’d expect the devs would want to avoid unless there was a really clear benefit, or there were really strong pushes towards multiple different ideas for the same system. E.g. if they really can’t decide between a couple of iterations of the building UX, that would be a way to put things to a fair vote – let players try the different options via different experimental branches. However, I suspect that in most cases the team will have a “best” candidate in mind before they even think about pushing anything to the experimental branches, and the cost/benefit ramp probably makes keeping multiple experimental branches up a prohibitively expensive/difficult option.
Still, food for though 
4 Likes
…eh…I kinda was. My thought was that, instead of doing 50 prototypes and figuring out what worked best, by dropping those on us, they could squall that number down some, by getting feedback on why the first 10 did or didn’t work. None the less, I didn’t think of it in the way you put it, nor of the feedback time @nikosthefan stated. Sorry about that.
1 Like
Hey, no harm in throwing the ideas around mate – and it’s nice to see someone reading and learning from it, hahah!
That kind of “crowd-sourced rapid prototyping” works great in a much earlier phase, where the community of supporters isn’t so large as to become unwieldy. However, these days, the Early Access scene is so large that it quickly becomes impractical to throw around those experimental builds.
But if team Stonehearth find a way to make it work, I’m totally down to take part in some rapid protoype experiments… and it can’t hurt for them to have a think about it.
3 Likes
I agree with this. 
3 Likes
Did I miss this somewhere in the updates? I distinctly remember a friend asking me if I recommended Stonehearth, and I told him that it’s a fantastic game but it’s still afflicted with a bit of Early Access-itis, using water as an example. But, I added, they’re fixing the water soon, and it’ll be a great investment once those systems are sorted out. A year later, water is still broken, and I have egg on my face in front of my friend. Please, communicate these things! Or, if you have and I missed it, allow me to eat this here crow.
3 Likes
Sorry about this. @Albert has been working on water for a very long time now. He sits there swearing a lot at Albert from 2 years ago.
5 Likes
I know that your recent poll indicated that people aren’t too into knowing technical details, but I was wondering if @Albert could indulge me / us (if y’all out there?) as to some of the complexities with the water system. Minecraft has a working water system, right? It was imperfect but didn’t seem too complicated. Is there anything Team SH is wanting to accomplish with water that would make Minecraft’s approach ill suited for Stonehearth? Not to diminish Albert’s own achievements, of course, but as a developer myself, I find it’s often easier to adapt a premade solution than to code my own from scratch.
2 Likes
Minecraft water is nothing near our water. Our water is more like terraria water.
In minecraft, you place a water “block” and it spreads a little but continue there. If you place it on top of a mountain it will “magically” flow down infinitely.
Here, if you would place a “water block” at the top of a mountain, the water would flow down, leaving the top of the mountain dry, accumulating only at the bottom.
4 Likes
I’m hoping that at least some of the water blocks will act like you mentioned with Minecraft. I want to have flowing streams and rivers, as well as the possibility of ponds and lakes and oceans.
3 Likes
There is nothing wrong with our water, we actually have a very realistic water physics. Wanting something like Minecraft would actually impose limitations to it.
We already have ponds, lakes and even oceans and rivers if you count mods. The only problem is that water is bugged. Remove the bugs and it is perfect, missing only springs and sinks.
5 Likes
This is true; yet, I can’t get past the desire to see flowing water-falls around my settlement ^^
Unless something is about to change and I am not aware of it, I do not think water falls will be possible with the water physics in Stonehearth (due to the upper “pond” or whatever eventually being drained).
2 Likes
Yep, me too.
We first need water springs to generate water, else the top part is drained. And then the sinks to eliminate the excess, else you flood the bottom areas.
4 Likes
Waterfalls used to work quite well, they just ran out eventually. I’d like pumps myself, but even just rain that refilled lakes (hopefully with limitations to stop mass flooding 
) could be enough to get continually running waterfalls once all the water bugs are fixed.
The game did, or at least used to, have a concept of sources and sinks, back when @chessmaster42 wrote the mod revealing water before it was ready. I wouldn’t bet on them being in and working after the water bugfix, though. Maybe after they start working on water gameplay.
3 Likes
Flooding would add a new challenge to the map. Could be quite fun.
3 Likes
Assuming it was easy to manage when treated correctly, and there was plenty of warning, I whole-heartedly agree! Passive evaporation would be a good start, but there would need to be a way to make sure that oceans and large lakes don’t simply evaporate to nothing. I reckon the simplest option is that if a body of water reaches a certain size (with a minimum depth), it no longer evaporates, so it’s possible for players to create an artificial lake or outright move a body of water without losing most of it. However, if a body of water is drained onto a floodplain, it will spread out and evaporate quickly… although it might drown the plants and mobs in the area.
2 Likes
A source in the permanent lake would do the trick to counter the evaporation.
Unfortunately that would mean a lot of constant/regular updates to the water, so a huge number of water blocks would be updating at short intervals – in other words, massive memory sink.
A great comparison would be against the old memory drains created by un-solve-able pathfinding queries, and how they’d stack up until the game couldn’t run anymore. Imagine an equal or greater number of queries to check whether a water block should evaporate or not – even if the frequency is lower (say once per day), that’s still going to hurt whatever computer is trying to run it all.
It’s not just the direct cost for evaporation simulation either, there will be unintended side-effects. One which springs to mind is the fact that every block which is removed due to evaporation will cause all outstanding/paused pathfinding queries to try again (because the terrain is being updated), so that’s a carry-on/snowballing effect.
And on a more basic level, how can we be sure that a source in the lake will actually match its evaporation? What if the player decides they want a waterfall, so now there’s not just evaporation but also a direct drain (presumably much faster), which feeds into a new lake/pond that is itself subject to evaporation?
I’ve been thinking that one viable way to handle flooding and evaporation I’ve seen in other games is to have two different kinds of water – “permanent” and “temporary.” The permanent water is what makes up lakes, rivers and oceans, while temporary water is created by rain and probably some other sources.
But even with that idea, you still have the fundamental issue that either the temporary water collects + evaporates causing large water movements and therefore high processing costs; or else you have an infinite amount of water entering and it doesn’t evaporate, which means the whole map eventually fills up and turns your town into a mini Atlantis!
I suppose another option is to look at the ratio of water to non-water blocks nearby to determine evaporation – something like “evaporation chance = 1/no. water blocks within 3-block radius of block in question”, so a block surrounded by water wouldn’t evaporate (assuming there’s some rounding, e.g. <1% = 0%) However, that means your evaporation checks have to check a lot of blocks nearby, which is an even more massive processing sink.
One game which sort-of solved this issue was Towns, which used the “mix of permanent and temporary water” solution. Rivers, large lakes and oceans were generated using the permanent water (it was called “water_inf” in the game files), and this water also worked as a source block to spawn the other temporary kind of water. However, it only did so in tiles which were adjacent horizontally to itself, so it avoided the Atlantis scenario… unless you accidentally flooded your mine tunnels, or intentionally built a “fountain tower” to raise water high into the air. Because the water_inf didn’t evaporate, it only had to update when the terrain did; and since the game updated the entire map at once (which, AFAIK, is exactly what Stonehearth does) there was no perceptible difference in performance – unless, of course, you tried to intentionally mine out a massive number of blocks adjacent to water all at the same time… and that wasn’t easy to do anyway, so I doubt it’s a problem many players will run into hahaha! The regular/temporary water would evaporate at a consistent rate, with clearly defined levels – level 1 being a tiny puddle, and IIRC level 6 was a full block’s height. However, there was a 7th level, which looked identical to the 6th one, but at level 7 a block was no longer subject to evaporation. Effectively, that was saying “the source is replacing water at the same rate as evaporation is taking it out”, and once a body of water reached level 7 across all blocks it became static, i.e. a still/calm lake or river or whatever.
Unfortunately, Towns worked on a tile-based grid rather than a true voxel system, so the water blocks operated very differently to how Stonehearth’s water does. I do know that the Towns devs called their water volumetric, which I believe is the same term applied to Stonehearth’s water blocks, so there’s probably a fair bit which applies to both; I suspect however that Stonehearth’s water will end up being more complex and, hopefully, more robust and accurate (and prettier!) as a result.
That’s why I think there should be a way for the game to “ignore” water blocks with a suitably low chance/reason to evaporate, so it’s only small bodies of water and the edges of puddles which shrink. This leads to a reasonable approximation of a natural-looking process – large lakes with deep shores won’t shrink, or if they do it will be very slow, while wide and flat pools/flooded plains will start shrinking slowly and then the shrinkage will speed up (and of course the player can speed it along heaps more by draining the edges of the floodplain or pumping it to spread it out.) In Towns, the water was functional even if it looked janky because of its discrete levels. In Stonehearth, the greater level of detail offered by the voxel engine can hopefully avoid the same jankiness, and make it easier to move water over large distances since the change in height can be applied far far more gradually – rather than dealing with Towns’ limit of 7 visible steps between empty and full, in Stonehearth the water will be able to evenly occupy wide, shallow areas or deeper, smaller areas and behave appropriately.
I also think that evaporation should be paused on flowing water, partly as a pure convenience measure (i.e. save the devs effort) and partly to make it easy for players to create flowing streams and waterfalls. In Towns, there was nothing more annoying than having water evaporate while it was in transit to its final location.