FinalForEach – How Vertical Slabs Are Making Me Add Mod Support – Remaking Minecraft

Minecraft is made of blocks. Dirt, Grass, Stone All of these are cubes, but some have different   shapes like slabs, ladders, stairs, and torches. In my Minecraft clone, I render blocks by   generating the faces on the fly in code. But  for custom block shapes, this is unmaintainable,  

Since I would have to write and debug more  code every time I add a new block shape.  And so I decided to move the  information about blocks into data. Remember that blocks are made out of faces,  and each face is made up of vertices,  

But it would be horrendously tedious  to specify each vertex one-by-one   for a block, especially for more  complicated shapes like stairs.  In Minecraft’s resource packs, block models  are specified in JSON files by cuboids,   which abstracts away all the individual points.  We will be mimicking this system in our clone. 

However, this cannot handle shapes like slopes  and curves, but it will be a good starting point.  With this, we have our first block that  isn’t in the shape of a cube, a stone slab. But now that we are able to  support different block shapes,  

We can focus our attention on block states. Block states specify what properties a block   has at a point in time. For example,  a lever can be flipped on or off,   and these count as different states. In the case of a slab, we want it to be  

A bottom slab, a top slab, or a vertical slab . In the past, Minecraft had metadata for each   block such that 16 different states could  be supported. For each block position,   it allocated a nibble for each block  state alongside a byte for the block type. 

But now, there isn’t a hard cap on the  number of block states per block type,   with the only limitation is that all block  state combinations are loaded on start up.  How does it accomplish this  without consuming too much memory? 

Each chunk contains a block palette listing all  the unique block states within a chunk, and the   data in the chunk consists of indices pointing  to that palette rather than global block IDs.  This is the right compromise between  minimizing allocating memory for  

Block types, and allowing any block state. So we can adapt this system, and even apply   an additional memory optimization. As mentioned in the first episode,   we store data in layers, storing  single values where it is all the same. 

But we can go even further- if the layer  only contains block states from the first   16 values in the palette, which it often will,  we can store it in nibbles instead of bytes,   halving the memory usage per layer! With this, we can have different block  

States, including the coveted vertical  slab, with its different orientations. Back to the topic of JSON, it  is an easy, human-readable way   to define data which allows us to  decouple the model from the code,   which allows for the potential for custom  models via resource packs in the future,  

Without needing to create a mod in Java. But if we can define the model in JSON,   why not go a step further and define  all of the block’s properties in JSON?  By moving all content that is in the game  into data, it has several advantages. Firstly,  

The code becomes easier to maintain, since the  same common logic will be used for all the blocks.  Secondly, it means that we can create mods  to add custom blocks and safely distribute   them if you join a server with them installed. When running arbitrary code such as Java mods,  

There’s always a security risk, but making  mods out of data we remove that risk entirely.  Thirdly, by defining it in data, it  means that eventually we can make or   adapt tools to simplify the process. For  example, a GUI tool can be made to make  

A block without even knowing any JSON or code. If someone wants to make a Java mod to do more   advanced things with the game, they could  still do that, but we should minimize the   need for this wherever possible, to make  it easy to make and easy to distribute. 

As this project continues, I want to  define more and more things in data,   so that essentially mod support is  there by default, rather than tacked on.  About 2 weeks ago I asked you about your  favourite experience playing Minecraft,   and you gave me a lot of feedback  which was very useful to think about. 

Many of you emphasized exploring, which no  surprise, considering each new Minecraft   update of recent seems to focus on a particular  biome. This means that any clone that is to live   up to it must have plenty of content in the  world, or at the very least have a world that  

Is lively with lots of thought put into it. Others said building was important, but most   curiously building was often paired with the idea  of a limited block palette. Personally I think the   friction in building needs to be reduced- if you  have the resources and the creativity to imagine  

A building, more time should be spent choosing the  best outcome and less time placing one… block… at…   a… time. As far as block palettes go, it tells me  that blocks need to fill their own unique niches   and not be too similar with one another. Some said that the challenge of night was  

Important, and this resonates with me quite  a bit. When I originally bought Minecraft I   thought it was a mix between a sandbox and a tower  defence. Doesn’t mean that this clone will be a   tower defence, but I will be putting an emphasis  on the challenge in survival. Don’t worry about  

Mob griefing however, I don’t like the splattering  of endermen’s pickups or random creepers ruining   the terrain and your hard-built decorations. And of course, we can’t forget how many   of you want multiplayer! The right  friends can amplify the fun of a game,  

And rest assured I will be adding this to my game. Now for the comments you left on the last video:  Why light level 15? 15 may seem arbitrary, but it fits nicely   in 4 bits, and especially since I’m doing coloured  lights which are memory intensive on their own,  

It’s important to minimize that. However, I did  have an extra 4 bits in the short used to store   lighting calculations, so expanding to light  level of 31 is entirely possible. The bigger   concern then becomes the performance cost of  calculating light. 31 is not twice as bad as 15,  

It’s exponentially worse, given the worst case  scenario. But I will keep in mind to maximise   player freedom with light levels. On textures  First of all I’d like to thank everyone  who offered their expertise and texture   artistry towards this, it’s encouraging  to see that you want to contribute. 

However the sad thing is that from a legal  perspective I cannot rely on this because   of the likelihood that contributed textures  may be based on minecraft’s textures which   would bring me back to square one- unable to  redistribute it without violating copyright. 

As for music and making it open source,  there’s still a concern, but much less so.  If you recall Bukkit, it was killed off due to  a DMCA which happened since Mojang owned it,   but not the entirety of it’s copyright. This  means that if I work with others I have to  

Make sure that potential copyright  issues are resolved beforehand-   which requires some legal advice first. As the game gains it’s own identity I won’t   discount the possibility of working with others.  But for now, it remains a question for the future.  On patreon At the moment, I don’t  

Really have anything to give back, no private  server or exclusive content, and it wouldn’t   make any sense for me to restrict suggestions to  those who pay when I want to hear from everyone.   You should get what you pay for, so I wouldn’t  feel right taking your money at the moment. If  

You really do want to support me however, then  after your family, friends, and those in need,   pray for me. I know that’s out of the blue for a  devlog, but I wouldn’t ask if it wasn’t important.  Next time we’ll tackle placing and  breaking blocks, which was saved  

Until now due to all the backend work  regarding meshes, culling, and lighting.  If you want to see this, stay tuned.  Take care, and I’ll see you next time.