Lets Code A Multiplayer Voxel Game in C++ - Breaking And Placing Blocks

hello everybody and welcome back in this episode I want to implement the ability to break in place blocks into our box of worlds but first of all let's take a look at what we've done so far and see if there's any way that we can improve it in the last episode we made it so chunks are created by the server and then they get sent to the clients of the game but as you can see we have to wait around 16 seconds for these chunks to even start having their meshes built and then rendered so before we start adding anything else we should first of all work out why this is happening and then fix it in the end it turned out to be a networking issue as when the server is sending chunks to all the clients it's sending the entire thing at once which is just overflow 2 kilobytes in size and this is what turned out to be the main cause of the issue so let's talk about why that is our game is constantly listening for these chunk dates packets which are being sent from the server in large amounts as you can see here but due to the way that networking works for these packets which are client they are handled by the operating system first and I'll put into something called a socket receive buffer which is a place in memory where things received over a network go into waiting to be used by your program the issue is this buffer is very limited in size so for example on Linux by default it can store just a few hundred kilobytes which is enough to store less than 10 chunks when this buffer is filled up and more chunk packets keep coming they get dropped meaning they never reach our program and as a result of this the server us to keep resent in these chunks until the client finally acknowledges that they have received them and this whole process could take a very long time which is why it takes a wife the client to receive enough chunks to start building and rendering the meshes the way they solve this problem is to compress the chunk before sending over the network but this needs to be done in such a way that we do not lose any of the block Deeter when doing so one approach for doing this is called a run length encoding this means starting with the first block of the trunks array you count how many blocks of the same type are in a row and once you reach a different block type you repeat the process until it's done for the entire chunk and what you're left with is an array of block IDs followed by how many of that block were in a row in the best case where the entire chunk is just drawing the same block type this can reduce the size of the block data from photo to kilobytes to just 3 bytes in some cases though the chum could actually be ironically larger than the uncompressed chunk but I'm not too right though because that's very unlikely to happen and a better way could be found later anyway so now I go ahead and run the game as a result of simply compressing the chomp data before sending it the world is now being rendered and generated basically straightaway so yeah that's exactly what one and a lot better than before so anyways now that the issue is fixed it means we can safely add some more features to our game such as the ability to place and remove blocks but first of all we should have a look at how the current block system works and how we can sort of adapt it to allow for editing of the voxels so first of all the client receives the trunk data from the server uncompressed as the chunk and then adds that chunk position to a queue of trunk updates where these trunk updates are a list of positions which chunks do not have their meshes built for them yet so once per frame this list is iterated through and if a chunk is found with all of its neighbors a mesh is built for that chunk and these chunks need to have all of their neighbors so that when the mesh is being built for it in knows how to handle the chunk edges and then finally these trunk measures are on buffered and finally rendered so all that really needs to be done to allow this to work with Vox were editing is to find which chunk the player is editing and an add that chunk to the chunk update list and then it should just work with the current system already so how did he find this chunk that the player is trying to either add a block to or remove a block from to do this we can use a ray cast from the players current position when they click their Mouse this ray cast is given the players current rotation and a step forwards until a block is intercepted with when the player left clicks it means replacing that block were there and when the player right clicks it means stepping the raycast back a little bit and then putting a block there such as grass the position of this block can then be converted into a chunk position and then added into the chunk update list so now if I go ahead and run the game I am able to reef blocks from the world and also place blocks but unfortunately there is still one more problem and that is when I dig sometimes a hole appears in the world and this is because of chunk hedges as when I'm updating the chunks I'm only updating the ones where the blocks were edited but these surrounding chunks are not updated this problem can be solved by checking if the block position is at the edge of the chunk and if it is then you add that chunk neighbor into the chunk update list as well after doing this there's no more holes in the world the final thing to do of this is making it so that if you're a naughty player game then everyone else is able to see you adding or removing blocks so the way I did this is when the player edits they block in the world it would send a message to the server and this message would say the block position of the edit and what block they either add or removed and once the server receives this message it would update the chunk on the server side and broadcast the block updates all of the connected clients this might look a little bit strange though and that's because the client who created the original block update is also receiving that broadcast but this is done on purpose because it allows the server to a sort of authorize that block update before sending it back to them so for example if the client is trying to cheat in the holding a stone block but they're trying to place a diamond block or something the server just simply wouldn't let that happen so anyways after doing more of this if one of the players starts breaking or placing blocks in the world then all of the other players are able to see it as well in other words we basically have a bootleg minecraft classic now but we're still missing quite a lot of stuff such as terrain generation but yeah that's going to be a job for another time so anyways quick shout out to my patreon supporters Thank You Killick regime and Colin McNeill II Timothy Gibbons Timmy Schroeder Allen Nando's Ben sayers Michael Kirsch Lucas Durham burger Nate Brown and Knoblauch hi Mona thank you all very much for the support as always link to the source code is in the description below so yeah once again thank you for watching and I'll see you all next time

Channel: Hopson

Views: 73,174

Keywords:

Id: fqdTj27xVMM

Length: 6min 4sec (364 seconds)

Published: Fri Jan 17 2020