I think a combination of the two. The big view, to understand how it all works together and the deep dives to truly understand each part.

@jasongracesonofzeus

2 ай бұрын

Agreed. Alternating between the nitty-gritty in one episode and the big picture gameplay elements in the next seems like the right balance

@everybodyants

2 ай бұрын

Yeah, it's a good combination of both that works best.

@Alyxandrite005

2 ай бұрын

starting the video with a grand statement of what they're wanting to achieve, how it fits into the wider scope of the game, then getting all nitty gritty with the technical stuff I think is the best approach

@lFunGuyl

2 ай бұрын

To the contrary, this was my favorite episode. I am making my own Voxel Engine and the stuff about different blocks types stored in a small amount of memory was supremely helpful, and entertaining!

Having one video focusing on large scale changes followed by one focusing on technical small scale seems like the perfect mix; I enjoy seeing both

Please don't stop going into the technical aspects of development. It is very enjoyable seeing how you tackle the small challenges along the way

I would personally prefer these technical videos. As someone who loves seeing the science behind how everything is done, and an aspiring game dev myself, I absolutely love this format of video.

Quick note, anyone replying about whether you should deep dive into the technical stuff or not are the people that sat through the whole technical video like myself, so there is going to be a bias towards wanting technical videos since the people who didn't enjoy the in-depth look at the code will have left

@IncandescentGames

2 ай бұрын

good point classic survivor bias! I will be comparing how the videos perfrom too.

"Sometimes you need to see the bigger picture." Incandescent: *shrinks the picture.*

I like the more nitty-gritty stuff like this.

This last clip of you barricading yourself at sunset reminded me of the stress and anxiety of playing alpha Minecraft back in 2011... damn good times...

It's interesting how many design problems minecraft has already solved for you, in one way or another. Mojang provided proof that 16 colors are sufficient, and that you need not mix dyed blocks with half blocks. These globes are going to be lit. At first I thought the hexagons were a major design limitation, but the more i think about them the more excited i am to see what new shapes and styles can be made within. Hexagons are, after all, the bestagons.

@MelodiCat753

2 ай бұрын

Are there really no dyed slabs in Minecraft? I don't remember that being the case. It feels like a weird sacrifice to make.

@Wolfboy607

2 ай бұрын

@@MelodiCat753 There are the different colors of wood slabs, so in a way they are dyed, but they aren't actually related to or in the 16 colors of dye anyway, in this system they would be parsed as one block each. Which is is believe how minecraft treats them, and further serves my point.

@ETXAlienRobot201

2 ай бұрын

@@Wolfboy607 minecraft actually changed the ID system to accomodate having more block types. they're namespaced now. that takes considerably more memory than 2 bytes. unless they [hopefully] did some optimizations behind the scenes to reduce that at run-time.

@Wolfboy607

2 ай бұрын

@@ETXAlienRobot201 I didn't say a single thing about current minecraft block ID's, i just said that many (distinctly not "all") of the design problems are ones that minecraft has useful solutions for.

Really enjoyed the technical stuff. Seeing how things are made are the reason devlogs like these are interesting in my opinion

For you consideration: With the 8-bits for block type and 8-bits for variations strategy, you get 256 unique block types with 256 variations per type. But if you use all 16-bits for block types alone and represent each variation as a different type, then you can have anywhere from 16k block types with no variations, to 1 block type with 16k variations. Doing it this way means that if you have some blocks with fewer variations, then you can have more block types. You would just need to automatically generate the different variations of the blocks.

@davidrudpedersen5622

2 ай бұрын

Yes, i was thinking about this as well

@Pystro

2 ай бұрын

I was thinking about this as well, but I would use the highest byte for a "block group" ID, which determines how much detail is saved. A block group for the simplest blocks like "air" or "full grass block" would allow all 8 bits of the second byte to encode a separate block. (For 8 bits of group ID, 8 bits of sub-id and 0 bits of state information.) A block group for "colored plank stairs" would have 8 bits used for color, flip and orientation information, so each block group ID would be a separate block. (For 8 bits of group ID, 0 bits of sub-id and 8 bits of state information.) And you obviously would have any combination in between (like "colored plank blocks" which have only 4 bits of color information, where the remaining 4 bits can be for sub-ID's; and "colored plank slabs" which have a single "flipped" bit and 4 "color" bits, which leaves 3 bits for sub-id's). Also, making the "flip" information a single bit (with 2 states) may not fully work, as long as you treat slabs like in Minecraft. Minecraft has bottom slabs and top slabs, but it also has double slabs. I.e. 3 different states, not 2. Making a separate "double A, double B, ..." block for each type of slab may make it easier to handle stuff like opacity, but having the double variants be the same block ID as the single slabs may make it easier to handle textures, item drops, sounds, and more. Similarly, if you have blocks _with orientation_ that you want to be able to combine into a full block (say roof slopes), then you may want 12 values for flips/ orientations plus a 13th value for "two slopes that are combined into a full block". The system with a variable amount of state information will likely make it easier to have 3 states for slabs, as you can just have each sub-ID start at multiples of 3 (where 3N+0 is bottom 3N+1 is top slab and 3N+2 is double slabs) instead of cramming the flip information into a set number of bits. That way a block group for (non-colored) slabs can store floor(256/3)=85 different slab blocks, instead of 64 - or even worse - double slabs with no extra color or orientation information wasting a full 16 code points. And a block group for slopes can store 256/13=19 different slopes, instead of 256/16=16.

Hexagons make some things harder, but they make some things much, much easier, as well. The hexagon first blessed me with its' presence probably ten years ago, now. It has been one of the greatest gifts I have ever known.

i really love seeing both, the inner workings and the bigger, game design videos.

As a coder, I love seeing you problem solve through the finer details. It's really interesting and can show me new ways to look at things

This is very handy. I've taken a couple C++ courses in college, but most videos I've come across KZread still felt too abstract, so they weren't particularly useful to me. Most people stop at just the concept, but never show the actual implementations. Whether that's because they're afraid to show their code or they think it's too boring? Idk, but it would be so good to have more content like this.

One thing to look into for block data. Each chunk could have a local dynamic dictionary of every block type within the chunk, And the actual voxels themselves would just store the local index of the block in the dictionary. I believe modern Minecraft uses a system very close to this, And it's how the game has basically infinite block IDs. As an example, Say the chunk only has dirt and grass in it. The voxels in each chunk would just store the index of the corresponding block in the chunk data file. If you place a new block in the chunk, That block's reference would be added to the dictionary, And the ID would be changed to the index of that block. Likewise, Removing the last block of a type from a chunk would remove that block's reference from the dictionary.

@IncandescentGames

2 ай бұрын

Chunks are actually bundeled together into what i call zones when it comes to data (this greatly speeds up saving, loading and commpression). There are 32 by 32 chunks areas, so this would case an issue if someone tried to place all blocks in this area. I'm sure i will talk about that in a futre episode

@redo1122

2 ай бұрын

​@@IncandescentGamesyou could see how minetest(opensource minecraft clone) stores blocks

I love watching these! It's taught me so much on how to optimize data and now I can't stop thinking in bits and bytes

Genuinely this is an amazing project! And like everyone else seems to say, the technical aspect of it is really exciting, and I think there is something much more satisying into seeing all the work that has gone into a feature before we get a demonstration of it, it really puts in perspective things like this which would be otherwise fairly unremarkable. I can't wait to see where this project goes!

Awesome video, i love how you go into the technical details! But with the hexagonal blocks, i'm wondering how you'll go about making perfectly straight walls. Making a wall out of hexagons works well for structures like wooden cabins, but for more modern builds it might look odd and i was hoping you'd have an idea in mind regarding this.

@IncandescentGames

2 ай бұрын

There is a plan! Maybe next episode...

@marusiaskrynnyk7489

2 ай бұрын

@@IncandescentGames Hmm... Maybe something like minecraft wall blocks could work? They have a vertical base, and then a straight connection between two neighboring blocks. Glass panes and fences also work this way. They could be perceived as not solid blocks, but I think they might have some interesting usage in the hexagonal world

@OnlyKarlos

2 ай бұрын

I think simple triangle blocks would do the trick

@tciddados

2 ай бұрын

@@OnlyKarlos Yeah, rotatable triangles works in some cases, but that comes with its own issue, namely in three ways: - A triangle placed between two hexes to flatten their side needs its top texture to match the direction of the hexes' tops to look good. But there's no guarantee on whichever way the hexes' tex "grain" is going. Even if the hexes are placed vertically, their brick/etc tex could be going vertically, or diagonally up-right, or down-right, or any rotation. Which means that in a naive solution, each filler triangle needs 6 different tex variations, to visually match whatever you're attaching them to, separate from their 6 rotations -Only using triangles doesn't "evenly" smooth things out. Imagine a scenario of alternating lines of hex blocks / empty lines, where there's equal filled+free area. Now smooth the walls by placing triangles against them. You shrink the empty space and expand the filled space, making it uneven. Not the end of things, but also usually not desirable since it makes things look uneven. -In the above example, if the lines are 1 block wide, there's another issue: When you fill in a triangle on one side of an empty line, in order to fill in the wall on the opposite side, you would need to place a differently-rotated copy of that triangle in that same block. But the block's already taken up by another triangle. You'd need to then make variations for each type of triangle block that cover two triangles, and their texture rotations. And you'd really need more than that, for whatever combination of triangles within one block you may need. This doesn't even consider that you'd need a lot of texture permutations to cover everything, because the wall on one way could have a tex pointing one way, the other wall a different way, etc The ideal solution would be one that just doesn't use new blocks to fill in/straighten walls, I think. Rather than looking at a block location + drawing a hex block there, the system would look at the block location + adjoining locations, and determine whether to draw a hex block or a different mesh. The overall world data structure would stay the same, but it would involve a bit more overhead in the actual drawing step.

I absolutely love how this game is going. I feel like a part of this community, which not many other communities are able to do. keep up the good work!

I really like the small technical but also having an overview of the lager issues you solve is also nice.

This was a great episode. I'd love to see more of this small scale technical development

I really like the visual style of the game. The smoothness of the textures is really nicely balanced with their detail :)

Worth mentioning, but while the technique in the video is a very useful+easy way to tile textures on hexes, it's not optimal, since it's repeating data within the texture (around 2.5x). You can create a "better" texture if you manually draw with hex tiling in mind, but that's its own can of worms. It is doable though: for example, if you're drawing a simple texture / don't need too many tools, you can actually use blender's texture painting: Create a textured hexagon, array+offset it to tile the hexes, and then paint on the hexes. As you do, the presence of the arrayed hexes will make your brush bleed over on the edges properly as you paint, giving you a properly-tiling hex texture that doesn't repeat data in the tex. For more complex things though, you would have to take a multi-layer approach in something like photoshop, offset copies on different layers, and manually blend as-needed, but that has its own pitfalls. Also, as far as block data compression goes: I think you'll get a lot more mileage out of finding a scheme you like to bundle groups of blocks together, than packing individual block data like this + storing every block in a giant array, as your calculation assumes. The majority of data in large voxel worlds is taken up by large swaths of the same air block, or swaths of the same ground block, etc, so if you implement something like (for example) an octree, you'll probably see immense data/memory savings without even having to get into the nitty gritty tradeoff level of stripping individual bits. This adds a little bit of overhead in extremely "noisy" locations (like if a player creates a pixel art image), but that's very minimal vs the overall savings.

@IncandescentGames

2 ай бұрын

With this technique you get exactaly 2x repeating, however after you have all the edges seamless you can change what's in the center and have close to 1x repeating

@tciddados

2 ай бұрын

@@IncandescentGames That's fair, didn't think of combining the technique with post-work.

@flameofthephoenix8395

2 ай бұрын

Hm, what about run-length encoding? That would be interesting.

@tciddados

2 ай бұрын

@@flameofthephoenix8395 I actually do that in my own stuff (doing runs by columns), but I also have less optimization needs since I work on much smaller data sizes than in this video. I assume octrees would still be better than RLE for big minecraft worlds like this, since RLE is more finicky when it comes to efficiency of accessing the data.

@flameofthephoenix8395

2 ай бұрын

@@tciddados True, it probably would do okay at compression but actually getting the data back out may be a trick.

Just wishlisted the game. I'm gonna love the day the game drops!

I find this extremely interesting. I am new to the channel, and am very much at the beginning of my journey of in programming and gamedev. This level of insight is really informative and you explain it so clearly. I am interested in seeing more content like this, but I enjoy the less technical stuff too. Thank you for sharing and good luck with your project!

the blocks that are really far away could only store their average color in one byte, without their id. These blocks will just render a flat color, without texture. That would make it a very simple level of details, where blocks far away are stored in less memory, allowing blocs, that are closeby, to use more memory. that means there could be more block states and types. Also the bigger the render distance, the blocks rendered grow exponentially, so any LOD system will make a huge difference on memory usage

i realllyy enjoy the technical details personally, its super interesting and helpful to see how other people solve problems like this

Personally, I like of mix of detailed videos and more high level videos. I did enjoy this deep dive into the finer details of the system.

this is a completely tiny and inconsequential detail to nitpick, but i think it would be nice if the billboard-based tiles like grass and flowers used 3 planes instead of 2, aligning with the corners of the hexagons instead of a "+" shape. at the moment they just seem a bit inconsistent with the geometry around them, and it could also allow for them to appear to have just a bit more depth when viewed from different angles.

@IncandescentGames

2 ай бұрын

I did try that to start with but it looked really weird. I'll definatrly revisit in the future

Have you considered using variable width block representation? I recon you could actually fit the most common blocks in 1 byte and the vast majority in 2 bytes and then expand to a 3 byte width for weird combinations. A common block could be represented by a starting 0, then 3 bits for block type, 3 bits for rotation and slabs, and another 0. For less common block types, you could start with '10', then 10 bytes for block type, then the same 4 bits as before. For super rare block types, you can start with '11' and then some number of bits for block type, depending on how many you need. To represent painted block, you could set the final bit to 1 and then add another byte at the end for storing an 8 bit color. This ensures 8 common, unpainted blocks fit in 1 byte, common painted blocks fit in 2 bytes, uncommon blocks fit in 2 bytes (3 when painted) and rare blocks need 3 bytes (4 when painted).

I like the in the weeds details as well as the higher level overviews.

awesome

I love this! I also want to see some work on pentagonal blocks. I know we talked about that in the Discord for a bit and I'd love to hear more about your plans for them.

I am interested in how blocks behave in pentagons. How do they connect if they even do?

@IncandescentGames

2 ай бұрын

That sounds like a good short

Have you considered block palettes like minecraft does? It might help solve your issue with trying to store each voxel individually

I don't know if anyone else commented something similar but I think there could be room to add colored blocks with slabs. So instead of using the same 4 bits for color and orientation we could take from the number of blocks available. The first bit of the ID could note if the block is colorable or a variant (will get to that in a moment). This would leave 2048 different uncolorable blocks and 128 colorable blocks. If this is too many different colorable blocks then some IDs can be repurposed to be used for variants. For example, you could have 16 variants of stone and place that under the colorable IDs. The only issue with this idea is if more than 128 colorable blocks or more than 2048 regular blocks are planned.

These kinds of topics are really interesting in my opinion, I wouldn't mind if more dev logs went into the details like this.

I really like the detailed explanations. Definitely the series i look forward to the most on YT

This just makes me realise how incredibly intelligent this guy is because omg.

I liked this journey through the weeds

pretty cool project. I started making a simple Minecraft clone-like voxel project and watching a similar video with similar aspects helps me stay motivated. I think the technical aspects are some of my favorite parts about series like these, take a look at Sebastian league who does these coding deep dives, they are pretty informative, and visually showing what you mean and putting theory into practice will really help people understand it and become interested.

totally do these more specific episodes as someone like me who actually does programming and has programmed voxel engines this is very interesting and actually informative

These videos are awesome, I'm so hyped for the game!

awesome progress, and love the technical stuff as well

I love finer detail things! A mix of the two is awesome!

I have to say, I'm here to see the progress with the code too. Keep showing! Great series :D

great video, been loving this devlog so far! ive personally enjoyed seeing both the big-picture stuff and the small technical details and would love to see a mix of both in the future. Looking forward to the next one :)

This video is satysfying for some reason

I hope one day, this game comes to console, so I'd be able to afford it if and when it fully releases

As always you are so good to explaining. I love your work so much even if I am hyped each videos, you are making me go crazy by what you're doing in them.

masterful craftsmanship

I'm so excited for this game dude, its already wishlisted and imma keep coming back for more

The fine details are awesome to hear about!

Amazing work, great job explaining the block values, I found it very interesting!

Yayy another video :) keep it up!

Love these devlogs

Interesting way to encode block states. If I remember correctly, Minecraft has some manageable number like 13k block states (or perhaps it did a few versions ago) and they’re able to be represented by two bytes as they’re just enumerable. In chunk data they are pattern-stored which is a little different but you could realistically represent all blocks with a 2 byte integer. The vanilla game has support for modding that can add more block states so It never explicitly tries to encode it as 2 bytes.

color - instead of hardcoded colors, could point to an index in a color palette. the color palette could be dynamically created and stored in the closest chunk (/sub-chunk/super-chunk), sure that would add a bit more (possible) memory overhead onto it, but the list of "used colors" in the chunk could just be empty until something is colored. sure, it would still be limited in a way, but the practical limit would be way reduced, allowing to use 16 freely chosen colors per chunk. (note, that I have not thought at all about the shader side of this, how to send the correctly chosen color per block to the shader without destroying batching and so on. just brainstorming :D)

wow, that was very interesting

When your game comes out, I'm definitely buying this thing! Nice video!

i think you should be able to chisel each vetice off the block, so you can have nice walls, and weird pyramids. not sure it would work with your current system though. and if you middle click the block real block you chiseled with a block in the off hand, with a chisel in the main hand, you chisel the block in your hand to be the same as the one you're looking at

Definitely enjoying the detailed in-depth stuff and coding reviews, would prefer much more

about storing wall state in memory : in Minecraft walls have a lot of sates, but you only need three, for whether or not it connects to three deferent direction 1D example : [] | []=[] | []=[]=[] Boolean: connection to right? 0 | 1=0 | 1=1=0 with the model of the wall extending into another block

@IncandescentGames

2 ай бұрын

Walls state doesn't need to be stored it can be calculated very quickly using neighbours

@famillicraft8163

2 ай бұрын

@@IncandescentGames so when loading a new chunk all blocks update their neighbors? is Minecraft doing it very inefficiently? (and with only 6 neighbors)

Hell yeah sub-byte information!!

That looks great

I like the technical stuff :D

Yup, i enjoy. This stuff is cool. I might decide to do my game idea at some point, so its also useful to hear about it and see the code, since i mnow C# basics

I really enjoyed the structure of this video, however, I would have liked to see some more practical application of the concepts you explained in detail. Showing the debug block was really helpful for connecting the technical aspects to the practical one, but it would be nice to see a few other blocks expressing that as well. Especially blocks that will be more common in gameplay. Overall very good though! I’ve really enjoyed every update!

@IncandescentGames

2 ай бұрын

Stairs with use this will be in the next vido

are you planning on adding wall blocks which might function similarly to fences (with the connecting perpendicular placements) i think that that could allow for some really cool shapes with building (like smoother circles or smoother squares and rectangles)

@IncandescentGames

2 ай бұрын

Yes

@sketchi7472

2 ай бұрын

@@IncandescentGames omg looking forward to it!

Nice

1:46 My first guess to fix this would be have each block take up a different part of the texture according to its location in the world, if block A takes out this same chunk shown here then the one to the right would be split across the right hand side of the texture.

@flameofthephoenix8395

2 ай бұрын

Another solution would be to flip every other texture resulting in it being forcefully made to fit with the rest of the textures. Though, come to think of it, I don't know how well that would work with hexagons.

i like the details

Very nice!!

Instead of manually packing bits, what about an indexed palette system? (Like how PNG colortype 3 works.) In addition to the voxel array, each region can store a palette table that maps each 16-bit value to a larger block-state struct. That would free you from needing to be especially conservative and compact about how you represent block states, and it would also allow the game to have even more than just 65536 possible block/orientation/color combinations, so long as a player isn't insane enough to actually try to _put_ more than 65536 unique block types in the same region simultaneously. Even with 1k block-state structs, that's still only a 64M table per region. This would mean interposing some additional CPU-side algorithms on the voxel grid structure, but not _slow_ algorithms: Region load would involve populating a reverse hash-map to let you efficiently find an existing block ID to use to set a state already present in the region, and probably a refcount table to let you efficiently garbage-collect and reuse palette slots. Setting a block would mean searching the reverse map for the block state and inserting it into a free palette slot if not, but bulk operations like world-gen would only need to look up "stone" once and use the ID for bulk sets. Breaking a block has the most options, for how aggressive it needs to be about keeping the table compact. GPU side, it'd only need to be a forward lookup, a simple array index -- and even if a player _does_ manage to find a way to reach the limit of 65536 unique block types in a single region, that table would still only 64M per region.

@AJMansfield1

Ай бұрын

Just running with this train of thought: You might even be able to get away with reducing the bits-per-voxel down to _just 8_ if you implement palette table regions as a bounding volume hierarcy -- the answer to "what if someone tries to place a 257th type of block" is either "split the BVH cell" or "kick the player for cheating because an 8x8x4 cell only has 256 voxels". Sure, you're then spending probably several MB to store an elaborately-decorated player house, but that's a drop in the bucket compared to cutting the 4GB of stone and grass and caves down to just 2GB. And BVH's are a well-established graphics datastructure that you can _absolutely_ do accelerated on-GPU lookups into.

Yesss

Interesting! Fun to see the behind the scenes, I wonder how block-storage could be handled differently to not need to make compromises for slabs/stairs...

Bit packing is always interesting lol I'm looking forward to that mesh video. I'd also like to see window panes! I'd like to see how/if you affect lighting color with stained glass

In my voxel game I have blocktype class. When game starts I create all blocktypes for each block(it can be different to every block). Then I will just use references to these states, so for chunk 16x16x16 it will use 4096*4 bytes (4 bytes each reference). Doing so I have no limitations for what a block can be or what properties it can have. No limitation to blocktype count(ofc technically there is). I would say I have no limitations at all by using 4 bytes per block state instead of 2

@flameofthephoenix8395

2 ай бұрын

That is what I suggested he do. However, it seems that he actually has rotation and flipping variants of every block that isn't dyed.

Yay i always though this would be great because would help break the repetitive pattern, maybe an Einstein tile could be even better.

very nice

More of that, please!

The second part about storing block data was a bit hard to digest without visuals. Using simple diagrams could help :)

Suggestion: (this has probably already been suggested) Step height. So you can walk up slabs/stairs

Hexagons are the bestagons

I like the finer details. Big stuff too, of course. Tell us about both.

5:12 you could actually work with a texture that is twice as wide as the one you present in the video (i.e. 6 cells in 2x3 shape). Then you could tile it as shown in this part of the video. This would actually let you make textures that have no repeats within one hexagon straight out of the box.

@IncandescentGames

2 ай бұрын

If its twice as wide the diagonal edges don't align.

There's got to be a way to pack orientation and color into the same block... Maybe using an offset rather than a nibble? Like you set the block ID and then the next 16 are reserved for colors or orientation, or the next 256 for both. You'd either need to be super careful with the IDs or pack the IDs at compile, which would put the computation onto a variable width tree lookup though... I'm not sure how that would affect performance. Or maybe just use two bits to flag if theres and color and\or orientation offset? I don't know. Something in the back of my mind is niggling over the wasted potential...

also, i believe your tiled texture solution for the top of your hexagons is flawed in that it results in quite small textures and a ton of tiling. i believe warping the UV coordinates of the hexagons using the world space position of the individual hexagons would result in much better tiling, as you'd be able to have less texture tiling. this is pretty cool though ! i really like the pace of your vids and how you explain stuff, i'll join the discord right away !

Minecraft stores an index of block states in each chunk, and then 2 bytes to store each blockstate id, so it can use any blockstate

hexagons are the bestagons

I say focus on the big picture stuff for now and once you finished with all the big game mechanics and features you want to add and then focus on the finer details of how it all works.

🦁

I'm curious to see how you tackle the blocks around the corners of the world. The hexagons will be more distorted, plus you have those pesky pentagonal blocks to deal with too.

Interesting development with the thumbnail i have never seen hexagonal bricks. Im interested in how deep you can dig into a planet and how wold it look like if you went all the way to the core.

Have you considered making it so the tall grass texture is drawn on three intersecting planes(that would follow the hexagon’s diagonals) instead of two? I guess it would mean more textures to render at once, but I think it fits the hexagonal aesthetic more than the two-plane tall grass.

I think you could keep the technical videos, but you could also add some sort of changelog in the description or in a community post.

Very cool! Always love encoding data in binary flags like this. Did you consider variable-width encoding for the block data, akin to UTF-8? Most blocks won't make use of the flipped/rotated/coloured values, so by using a system like UTF-8, you could store many of the more common blocks like dirt or stone only in a single byte, opening up the opportunity for rarer blocks with more states that could perhaps use 3-4 bytes.

@IncandescentGames

2 ай бұрын

Yes i might do something like that if needed. But 4096 blocks is probly more than enough. Were more likely to be texture limited (currently max textures is 3096) textures do get reused on multiple blocks but some blocks take 5 difrent textures

@FreyrDev

2 ай бұрын

@@IncandescentGames I was really thinking about memory usage and blocks with more blockstates rather than just more types of blocks. Something like fences where you need a bit for each side's connection. If nearly all the blocks in the world are only using one byte because they don't have any states, then using 10 bits for the states of something like dyed fences doesn't seem that wasteful. Its definitely not _that_ much of a problem, I was just thinking of ways to lift the limit you had to place on number of blockstates without using too much memory.

You really only need the 4gb of ram if you've loaded a world where every block is filled and every block's neighbor is different, which is not the common way the data will be. You can use a compression scheme of sorts to encode large portions of contiguous blocks. Even just a simple run-length encoding would drastically decrease the memory required. Of course, that's going to cause trade-offs in other areas, but it's all trade-offs in the end regardless.

I absolutely love seeing the code as I'm about to start my level 3 games tech course, but maybe 2 separate video types would be good. 1 for the finer details of specific mechanics and 1 for the casual viewers who just want a progress check?