PC Alpha 21 Dev Diary

Status
Not open for further replies.
22 hours ago, Laz Man said:

Tune in, in about 3 hours from now.

I was finally able to watch this and came away feeling great about the future of the game. A lot of cool things to look forward to.

  • While a little disappointing that bandits are looking unlikely for A21, I like that both Rick and Joel want bandits (a critical feature) to be more fully baked and fleshed out when eventually released.
  • They snuck in a little bit of news in that there are a handful of QoL changes coming to the game. I could have misinterpreted, but it sounded like at least a few of these are coming in A21. I would love to hear more about that.
  • One of those QoL changes (again, sounded like it is coming for A21, but I could be wrong) is an update to the UI. Rick mentioned a graphic designer wsa working on that (as a side note, I hope by graphic designer, he meant UX designer. Two very different things. Whoever it is, hopefully they have experience in UX) Regardless, I think most players would agree this is an area that needs some love.
  • The story details they shared are probably what got me the most excited. They couldn't share a lot, obviously, but the way they described how the story could potentially unfold is a bit different than what I've imagined. So far the ideas they have shared have me looking forward to that content now more than ever.
  • Lastly, their comments regarding performance improvements make complete sense from a development standpoint. While we as players sometimes gripe about the poor performance in some cases, focusing on performance enhancements just does not make sense when systems and assets are still being finalized. That would likely result in wasted dev time and resources.
These are just my observations and I know not everyone shares my optimism, but I'm really looking forward to the next year as they get closer to gold.

P.S. - Also can't wait to hear about their new projects!

 
  • Lastly, their comments regarding performance improvements make complete sense from a development standpoint. While we as players sometimes gripe about the poor performance in some cases, focusing on performance enhancements just does not make sense when systems and assets are still being finalized. That would likely result in wasted dev time and resources.
It's worth noting that Joel states they have a desired timeline for A21 release to tie in with external factors (I'm betting a dime to a dollar that's 'in time for the holidays and associated Steam sale' but he's not that specific) but they'll delay A21 release past that desired date if they cannot bring performance up to an acceptable level with the new features added in. His tone doesn't indicate they're having especial performance problems with the new content, just that this is standard practice for a deployable release (which it is).

It does highlight the 'damned if you do, damned if you don't' nature of optimising before feature lock, though. If they do too little, the game would be nigh unplayable on most systems. If they do too much, alphas would be coming out at a significantly slower rate than they currently do. Either way they get flak from vocal members of the community.

Im looking forward to the next 3 years as they get closer to gold ;)

completely fine with me, honestly.
I'm guessing you'll only start demanding gold once working showers are in.

 
I like the idea of the chunk reset timer, but am happy it is off by default on SP.  I don't mind it resetting cities after a while, but I don't want it to reset things I build or dig in the world.  I like to add things to the world to make it interesting and only being able to lock 2 things (using LCB and bedroll) isn't enough.  For example, in my current world, besides my base and horde base, I created a long tunnel through a large hill, paved it and cemented it and put a parking lot on the other side with picnic tables and an over look deck area with a sign before the tunnel saying REST AREA.  I also made a small camp area after digging a hole through a large boulder and making a  path through with sand to the road.  I plan to make something in a couple islands as well.  I'd hate if I wasn't able to do this without it resetting on me and default on is a good way to forget and lose everything you have done.  If it could be limited to only reset cities/towns, that might be okay, but still best having it off.

 
One big problem with water flowing naturally into open spaces is that someone would have to define for the now thousands of blocks how permeable they are for water in what direction. And it even can depend on what block is adjacent.

I.e. a plate would not allow water through the plate but past it. And a plate with a hole would act differently if another plate behind it had the hole at the same or a different place.
I think that could be simplified. If one can shoot through it, then water can also flow through.

 
I guess the problem is primarily not about that/how water could flow, but more considering its overall amount in those cases.

If it flows into an adjacent block, will it leave the block it was in before? Will it split it half the amount (one half stays, one half flows)

Or does it "double up" and exist twice, one in the one block and one in the next?

How do you prevent long term that water doesn't fill up the whole map, or trickle away to bedrock and leave a complete dry map. 

Especially that example given by the devs ("there will be no waterfalls") is a good example for what I mean.

If water flows down, there has to be a certain given amount at the top side (lake or whatever).

When it flows over time, that lake would dry up and the lower landscape would be flooded.

It couldn't be refilled by for example rainstorm, because over time it would submerge the whole region.

So there would have to be a mechanism to tell the "bottom" water to disappear...but how to determine that/when/how without making it weird,

especially cause a player can dig down everywhere.

And it also can't flow down and also stay up in the lake, that would fill up the complete map (and create lots of exploits I guess)

 
Last edited by a moderator:
I guess the problem is primarily not about that/how water could flow, but more considering its overall amount in those cases.

If it flows into an adjacent block, will it leave the block it was in before? Will it split it half the amount (one half stays, one half flows)

Or does it "double up" and exist twice, one in the one block and one in the next?

How do you prevent long term that water doesn't fill up the whole map, or trickle away to bedrock and leave a complete dry map. 

Especially that example given by the devs ("there will be no waterfalls") is a good example for what I mean.

If water flows down, there has to be a certain given amount at the top side (lake or whatever).

When it flows over time, that lake would dry up and the lower landscape would be flooded.

It couldn't be refilled by for example rainstorm, because over time it would submerge the whole region.

So there would have to be a mechanism to tell the "bottom" water to disappear...but how to determine that/when/how without making it weird,

especially cause a player can dig down everywhere.

And it also can't flow down and also stay up in the lake, that would fill up the complete map (and create lots of exploits I guess)
 how does water work in minecraft? how do they get away with the way it works without causing any big performance hitches. water in that game atleast obeys the laws of gravity

 
I guess the problem is primarily not about that/how water could flow, but more considering its overall amount in those cases.

If it flows into an adjacent block, will it leave the block it was in before? Will it split it half the amount (one half stays, one half flows)

Or does it "double up" and exist twice, one in the one block and one in the next?

How do you prevent long term that water doesn't fill up the whole map, or trickle away to bedrock and leave a complete dry map. 

Especially that example given by the devs ("there will be no waterfalls") is a good example for what I mean.

If water flows down, there has to be a certain given amount at the top side (lake or whatever).

When it flows over time, that lake would dry up and the lower landscape would be flooded.

It couldn't be refilled by for example rainstorm, because over time it would submerge the whole region.

So there would have to be a mechanism to tell the "bottom" water to disappear...but how to determine that/when/how without making it weird,

especially cause a player can dig down everywhere.

And it also can't flow down and also stay up in the lake, that would fill up the complete map (and create lots of exploits I guess)


Faatal said 1) water is finite and 2) "It flows into neighbor blocks that are marked to allow it, like into air blocks" and 3) "Water can fall"

Water will not drain to bedrock because full blocks like earth blocks will not be marked to allow water to flow into it.

As water is finite and flows into neighbor blocks it will only leave the block it was in if there are no partly filled blocks available. Water would just be defined by one bit and essentially a block would be fully water filled or not.

But I would guess that water is at least 2 or 3 bits and therefore would have 3 or even 7 water levels so you can have water flowing naturally and with less blockiness into neighboring blocks.

I think that would be a good question to @faatal : How many bits in a block are reserved for water level or is it only 1 bit (on/off) ?

 how does water work in minecraft? how do they get away with the way it works without causing any big performance hitches. water in that game atleast obeys the laws of gravity


It does in 7D2D as well (in principle), but very slowly and often with blocks not getting updated. Just like the SI of buildings where often blocks stay floating

 
that cool "easteregg" POI at the southernmost edge of the navezgane map has some nice outside landscape with cascading water, which does a really good job of "simulating" a flowing river if you ask me.

 
It does in 7D2D as well (in principle), but very slowly and often with blocks not getting updated. Just like the SI of buildings where often blocks stay floating
It definitely does.

Learned that the hard way btw.

First played DF and put a bunch of raincatchers on top of my base (was the "present box POI"), because I assumed those would have either an "empty" or "filled" state and then I can get some murky water out of it to "reset" it to empty.

The amount of overflow messed up the whole base.

I could literally swim up to the rooftop like 20blocks from ground (using the totally submerged ladder was still faster tho) 😅

 
that cool "easteregg" POI at the southernmost edge of the navezgane map has some nice outside landscape with cascading water, which does a really good job of "simulating" a flowing river if you ask me.
Do you have a pic of that poi? I haven't played Nav since I first bought the game and not familiar with the map at all. 

 
Faatal said 1) water is finite and 2) "It flows into neighbor blocks that are marked to allow it, like into air blocks" and 3) "Water can fall"

Water will not drain to bedrock because full blocks like earth blocks will not be marked to allow water to flow into it.

As water is finite and flows into neighbor blocks it will only leave the block it was in if there are no partly filled blocks available. Water would just be defined by one bit and essentially a block would be fully water filled or not.

But I would guess that water is at least 2 or 3 bits and therefore would have 3 or even 7 water levels so you can have water flowing naturally and with less blockiness into neighboring blocks.

I think that would be a good question to @faatal : How many bits in a block are reserved for water level or is it only 1 bit (on/off) ?

It does in 7D2D as well (in principle), but very slowly and often with blocks not getting updated. Just like the SI of buildings where often blocks stay floating
The water voxel is 16 bits. It is a mass value. Water and blocks can both be in a voxel. Water looks at blocks to see if it can flow through. Rotation/shape of blocks is not a consideration as it would be complex and possibly very slow.

Games'n'Grumble said:
Do I understand correctly that you can enable this function in SP, and it will work almost like a loot update function, but for chunks? Does this mean that the updated chunks will be unloaded from the system memory and will be generated anew (trees, nests, stones, etc., except POI) when the player comes there, facilitating the computer's work?
This will remove the chunk's data and when you visit it again, it is recreated as it was before. Some parts may randomize, like grass, but parts like POIs should come back the same. This will reduce save game sizes, which is actually needed for console, as our worlds can get huge and max out your save space.

This feature will be off by default in all cases. Safer than having players getting areas reset for no apparent reason.

 
Status
Not open for further replies.
Back
Top