About the *crafting table algorithm*. A lot of you have pointed out that it is grossly inefficient, and I should swap it out for some hash and compare algorithm. This is true, but let's do a little thought experiment. According to the table here: www.agner.org/optimize/instruction_tables.pdf, it looks like comparing two 32 bit integers takes about 3 cycles for Intel Sandy Bridge (an i5 processor), assuming no cache misses etc. You need to move two numbers, which requires 1 cycle each (also ignoring reciprocal throughput), then compare, which takes 1 cycle (ignoring reciprocal throughput). My crafting table consists of a 16 bit number for the item id, and an 8 bit number for the item count for each slot. So, let's round it up to 32 bits and assume comparing two slots is the same as comparing two 32 bit numbers. That means it takes around 3 cycles each to compare two slots. If I compare my crafting table to one recipe, that's 9 slot comparisons total, or around 9 x 3 = 27 cycles. So, if I go ahead and say that I have 1,000 recipes to check against, then that's a whopping 27 x 1000 = 2,700 cycles. On an Intel i5 with a clock speed of 1.6 GHz, or 1.6 billion cycles per second. One frame of a game is 16ms, so lets say we have 1.6 billion * 0.016 = 25,600,000 cycles in one frame of our game at 60fps. This means that checking if the user got 1 recipe out of 1,000 possible recipes would take around 0.01% of our total frame time, or around 1.69 microseconds :). If we have 10,000 recipes, that would take around 0.1% of our total frame time, still not even 1% of our processing power in one frame. Now of course this ignores cache misses and all that stuff, but the point I'm trying to make is brute force is not always the worst solution. It's often the simplest algorithm, which it definitely is in this case, which leads to less bugs. Keep in mind that I only run this algorithm when the player updates a block in the crafting table. Human reaction speed is around 0.186 seconds at its fastest according to Google. In other words, they probably won't be clicking fast enough to ever have a lag spike because of this algorithm. Collin Ames did some calculations with cache misses taken into account in the comments, and calculated it to around 20 microseconds for comparing 1,000 recipes if you're interested :) I *always* profile my code *before* trying to optimize stuff, and my hottest path is anything that has to do with updating a chunk. One chunk is 16x16x256=65,536 blocks, each 64 bits. That's a much much larger loop than checking a crafting recipe, and that's where I focus most of my attention when optimizing my code (it also turns out to be the hottest path every time I profile it). So, when I completed this algorithm, and it didn't show up as a hot path, I moved on to other problems since I only have so much bandwidth as a solo developer :) TLDR; Don't assume where the hot paths in your code are, profile it. You'll learn way more that way ;)
@Harrison I definitely have the same problem of optimizing stuff that probably doesn't matter :pain:. And the hashing is still an awesome solution that's pretty straightforward and I wish I would have thought of :). It's also pretty simple, so I'll go ahead and implement it if I have some spare time, but when I coded this my gut feeling was "this probably won't effect performance as much as most of my other code", and I probably should have verbalized that a bit better in the video :)
try to check what minimun ingredients at look up table are in the grid (careless of position) And you get busted a lot of recipes with one shot, then brute force it as before and the amount of test will be less
I want to start out by saying that it's great to see your analysis of this, and you have a good process for solo development. I'm just responding to this as a thought experiment :) IMO, there are two flaws in your logic that make the original implementation unjustifiable: 1. You talk lots about the performance of this algorithm. Let's assume that Collin is right, and this takes 20μs to compare 1,000 recipes (b/c I'm a lazy programmer and don't want to do the math myself). If you expand that information to your 10,000 recipe example, it's now taking 1.2% of your processor cycles at 60Hz. I'm not sure why 1% of a frame at 60Hz is where you drew the line, but that's already quite substantial for what should be a cheap algorithm, and it's entirely possible to go over 10,000 recipes with recipe variations in modded Minecraft. 2. You say "[Brute force is] often the simplest algorithm, which it definitely is in this case, which leads to less bugs." The only way this could possibly be true is if you've never heard of java.util's Map class (or C++'s std::map). This class trivializes recipe checks so much that I can write the Java implementation legibly in a youtube comment: recipeMap.containsKey(currentRecipe). There's no way that an iterative method could be simpler or have fewer bugs than a single function call from a standard library. A couple other corrections (though they don't change your argument much): 1. You say "Human reaction speed is around 0.186 seconds at its fastest according to Google. In other words, they probably won't be clicking fast enough to ever have a lag spike..." Here, you are looking up information that doesn't measure what you're talking about. What you're looking for is clicks per second, which seems to top out around 14 clicks/sec. That results in one click about every 0.07 seconds, which means this algorithm could run three times in a single frame at 60Hz, tripling its cost to 3.6% of your budget in the worst case. 2. You say "One frame of a game is 16ms." This is obviously false, but I understand that you meant to say "I'm targeting 60Hz for this game." Your rounding (16.66... -> 16) also causes your estimates to be more conservative, so there's no problem there. The underlying assumptions you're making, though, are increasingly problematic. More and more consumers are buying displays that support 120Hz and variable refresh rates, and new consoles are taking advantage of these features. To support both VRR and people who don't use V-Sync, you should be looking at your frame pacing (time between frames) as well. Also, just a general comment on profiling - there are times when you'll have to profile one specific scenario to "light up" a code path. This specific code path isn't run for 99.9% of frames, so it obviously won't show up as a hot path if you profile with normal gameplay. That doesn't mean that players won't notice it when it does show up, and if you wait until you get user feedback ("Every time I craft something, my mouse lags"), it will probably take a lot longer to figure out what's happening.
@@dallasjohnson2635 maybe I should have phrased the original comment as "this is just some napkin math to illustrate a point" haha. I appreciate the response, but I'm just trying to illustrate that this algorithm runs on such a small data set that it's not worth my time to optimize it for a microsecond (at most) performance improvement per frame. A lot of people like to look at one specific algorithm, but a game is thousands of algorithms running simultaneously, and it's _always_ better to look at the algorithm _in context_ :) 1. I chose 1,000 recipes as a crazy outrageous number that I'll most likely never reach. According to the Minecraft wiki minecraft.fandom.com/wiki/Crafting#Recipe_system there are only 379 recipes in vanilla Minecraft as of 1.16. So I think I have plenty of time before I begin reaching 1-10,000 recipes lol 2. I think this is a bit disingenuous. Sure the API for a Java Map or C++'s std::unordered_map is simple, but you still have to implement the equality operation to ensure that it knows how to check if two recipes are the same (which is the same code I wrote anyways). You also have to implement a good hash, otherwise the map doesn't help much at all, and can often be just as bad as a regular linear search, check out this SO question stackoverflow.com/questions/1757363/java-hashmap-performance-optimization-alternative . This requires a lot of extra knowledge and implicit complexity. For your last two comments, I am targeting 60 fps, maybe I'll target a higher frame rate in the future. And once again, the reaction speed was just for napkin math to do some quick comparisons :) And when I profile, I do target specific events when I'm profiling a certain section of code (Visual Studio allows you to actually select the time period you would like to profile which is very helpful in this regard). My point was that comparing crafting recipes is literally orders of magnitude less then simply iterating over one chunk (400 recipes compared to 65,536 blocks in one chunk). There's usually 12 x 12 x 3.14 chunks in the game at the default settings (that's around 29,600,000 blocks, 74,000 times larger than all the recipes). This means that if a player is going to be noticing lag, it's most likely going to be when doing anything with chunks. All this to say, yes I know the hash is a better algorithm. But right now, as my code is, I'm not going to spend a bunch of time optimizing an algorithm for a few more microseconds per frame. If the requirements change, and I have to find 1 recipe out of 10,000, then I'll change the algorithm :)
I love this Minecraft has a very old lighting system that I wish they can change or update, is almost been the same for years now, and I love any mod that had dynamic lighting for Minecraft
I literally just want coloured lighting, ive had a concept I've wanted to make for forever but I cant cus no matter which mods and shaders I install, I cant find any that allow coloured lighting
@GamesWithGabe, Bro stick to one subject video. You're all over the place and your title was about multiplayer. And you're wrong @ 7:17. UDP packets never disappear into the void. They arrive at their destination in the wrong sequence which can be resolved by using a hybrid of TCP and UDP.
I appreciate the feedback @Battosai Jenkins! And I was referring to dropped packets at 7:17 which is a pretty common issue with UDP jvns.ca/blog/2016/08/24/find-out-where-youre-dropping-packets/#:~:text=lost%20on%20the%20way%20out&text=The%20Linux%20kernel%20deals%20with,So%20you%20will%20drop%20packets. . And I titled this video about multiplayer because that's what the bulk of it was about haha. This is a devlog and I want to cover everything that I've done in the past few months, but I also want to give weight to the most difficult feature I implemented over that time period
You can actually use both TCP and UDP. Just connect to a server twice on two different ports. We used that in our own multiplayer. We sent important messages like player join notifications and chat messages on one and player position data on the other Instead of sending packages every single frame and delaying them you can just send them more rarely and interpolate between received results. It's a lot easier on the server and delay is as short as possible. Once you received a package where player started moving in certain direction you can just complete that movement until new package arrives, when you will just correct player's course to align with new data Also slabs are horizontal in Minecraft :)
Yes. And it seems wrong to me using only one of them, since UDP is better for some features than TPC. Voicechat or moving the playes in some games for example
Haha yea, the time I spent on it reflects how long it actually took me to code it. Crafting took a couple days, colored lights and custom blocks took a week, and multiplayer took 3-4 weeks :D
idk what engine you are using, but I have tried to clone the minecraft inventory system before. IT IS HARD. The amount of work you did to not only get its base functionality working, but even more subtle features is not unnoticed. You're a legend.
Crafting matching would had been better (and much faster) by using hashes. Will just be a hashmap search. A formula like sum((x^y*materialtype))%something would work for the key.
@@GamesWithGabe Yeah just simply match the materials your crafting with a subset of "possible" recipes for the given materials, then just loop through that smaller subset of craftable recipes.
as Marc said, using hashmaps would do the trick. Just build a database at the start of the game (or once everytime you add new recipes) that contains grouped recipes based upon their ingredients, when you match all the ingridients that you have in your crafting gui with the "group" that uses said materials, then loop through all possible recipes inside that caches group. This should reduce from O(N) to O(log N)
@@mrmaniac9905 Was thinking on an even simpler way, with a continuous hash, you just have to store all possible recipes on a hashmap using sum(x^y*materialtype) as hash function. Then just start with a current hash of 0 and an empty crafting grid, everytime a material is added on a position, calculate (x^y*materialtype) add it to the current hash, and every time it's removed, substract it. After every click, just search the hashmap. If there's a matching recipe, it will be returned.
@@framegrace1 Ah, I see what you're saying, that's actually very smart. That in theory would work in constant time. I'm actually gonna implement that in my own game.
4:45 the solution is do the calculation on your side, then checking with the server, and if it is wrong, the server corrects you, this is commonly known as rubber banding.
Rubber banding is a side effect of client prediction that is incorrect from the server. You can avoid rubber banding with interpolation to make perceived latency less noticeable. Of course, this compromise also means that hit boxes aren't accurate and optimistic updates can cause data loss (i.e. crafted item wasn't received or verified correctly by the server) in high latency servers.
@@LuisCassih It will definitely will feel bad when you have a long latency. I don't know how Valorant client prediction works and when it kicks in. But a common practice is to use server reconciliation to solve desynchronization issues by sending a sequence number with the data, which can then be used to reconcile commands later on the client. Then reapply those commands that haven't yet been predicted by the client. That way it doesn't need to re-run commands that have already been predicted, while ensuring consistency with the server for both high and low latency players. This is how QuakeWorld (and Half-Life et el.) works.
The more technical term for rubber banding is rollback netcode, since if you do something the server doesn't like you get "rolled back" to whatever the server saw last
Awesome video as always! I would love to see more in-depth technical videos on a single feature with those animations, you do a great job of explaining this stuff
it feels weird to be following the game engine tutorial series and then seeing you here on the present with a different vibe. Good progress on the game! And the video is also a masterpiece
This is so cool. I love the breakdowns of techniques and reasonings. Although you lost me when your started talking about feeding data to the gpu, because that's high level stuff there mate. I find It's hard going from some coding classes, game design c# and python to actually implementing and creating something all by yourself.. Great videos.
Amazing video, thank you for explaining what you did every step of the way. Someone who is an amateur like me can understand everything you’re talking about, and that’s just amazing to me :) keep up the great content, loving these dev logs
This was surprisingly easy for me to understand, especially the multiplayer and lag compensation segments!! Usually I really suck at understanding something like this but you explained it very well. :)
I've been following this series just because the vids randomly appear at my yt homepage. I finally subscribed, and I'm looking forward to the new project!
Making my complete own version of Minecraft is something I've really wanted to do as well, but I have very little programming experience. It's nice to see someone else actually achieving it though!
Thank you robot overlords for shoveling me in this direction. I don't have the spoons to watch this right now (ironically, I'm learning to code a minecraft datapack and occasionally yelling at brackets i SWEAR I counted before) but it's now in my "to revisit later" playlist.
Great work on this so far. At some point it would be good to see a non constant velocity when moving, using acceleration and deceleration, in Minecraft this is subtle but it makes a big difference. Another thing I can suggest is to work out the longest time a player takes to ping on the server and set the buffer time accordingly; if two players on the same LAN network have to deal with 300ms of ping it could be quite annoying. For a larger server you'd probably want to take the median ping of all players and set the time to that, so one player having a hugely high ping does not affect everyone else too much. Also, consider that players can cheat as the clients are just telling the server where they are going, the server is not confirming or denying whether this is possible or not. Some games solve this by only sending what inputs are being given and the server confirming what should happen, while the client predicts what it believes should happen.
My brother also mentioned adding a quick acceleration to the player controller haha. And I'll be adding some anti cheat mechanisms and stuff in the future, as well as some more intelligent buffer times for all the players :)
Thanks for your videos, really I learn a lot. Right now I’m not working as programmer but I have a plans to create a game and all this information will help me in the moment when I start to create my game. Thanks a lot.
This is amazing! Making your own game out of this is brilliant, finally someone has that idea! I've seen so much potential in these Minecraft copies devs make, but they never try to actually make a game out of it that would be better than Minecraft, something different. There's so many things I wish Minecraft would be like, but it never happened. From simple things like improved physics to more realistic crafting to making cubes smaller, so that there's a lot more options to create things and how they would look like. Also, congrats on making multiplayer possible, I bet it wasn't easy. UDP is the best choice and there are also different types of UDPs like RUDP. I just think about if 300 ms of buffering would be good enough for PvP for example. I imagine CoD MP has figured this out in much more complicated way. They are probably checking who fired first and what were the real locations on their client side, but somehow it has to calculate probability most likely. And there are also problems with hacking and all that crap. There also have to be the distance prioritization to sync player's location. Multiplayer is just very difficult to make. Anyway congrats on making your AO, that's very hard as well! I love the progress!
Thank you so much for the awesome comment! I do imagine the CoD devs have some insane code for multiplayer PvP (at least I hope they do haha). The multiplayer is still definitely a WIP in my game right now as well, so we'll see if I completely change it in a month or two 😁
Wonderful video! I'm not a game developer by any means, but the way you put the video together is very entertaining! I've subscribed and can't wait too see where you take the project! Don't push yourself though, your mental and physical health is much more important! Good luck with the game!
A full 3 minutes is 180 seconds; 240 is the windows default of 4 minutes. the true default is anywhere from 5 minutes to 15 minutes, depending on the RFC / standard you're going by.
ambient occlusion is actually really simple. less light reaches occluded surfaces, so they appear darker. surfaces are occluded when they are partially covered. i think its actually extremely reasonable that the more a surface is covered, the less light would reach it.
Thanks! I use the manim library for my animations, which grant Sanderson developed and the community had created a version based off of. So full credit to 3blue1brown for the awesome software :)
to optimize the checking for the stick recipe you could just check the middle row, and if you find nothing that matches, then discard it, if you find a plank, check above and below it, and if it matches make sure all the unchecked other slots are empty. Doing it this way would make it so you only need to check every slot once.
Good stuff. I'm trying to make a LEGO game for myself. Coming from zero game dev experience, this stuff gets confusing/frustrating but then there are those brilliant moments of clarity when things work perfect. I'm currently trying to create a master flight template so I can just customize flight attributes and control ship specific animations.
The fact this guy is taking the chance Mojang or Microsoft dont come and give you a: naughty boy message saying go to court now kid is brave You hav my respec
4:17 This section doesn't sound right to me, the round trip does not affect the time between packets. If you send a packet 60 times per second you wouldn't see a difference in time between each movement at 1/2 the round trip time. You would just see their movement at 60 times per second (ignoring dropped packets) with a delay of 1/2 the round trip time as that is how long it takes for those packets to get there. The only way you would see something like 5fps for that example would be if you actually waited for an ack before sending a new position packet. 8:00 I'm really confused as to why this is considered an issue. It's 3 minutes before we consider the connection to be dead and kick the player, you should have something like this implemented to handle a situation where the game is improperly closed such as the user's computer turning off from a storm. Something unclear to me as you're using a buffer and unreliable packets for position, is whether you timestamp the positions in the buffer or wait for it to fill to update the visible position. If you're just waiting for the buffer to fill you can have issues from dropped packets causing the positions updates to slowly increase in delay. The buffer solution also sounds like it may have been picked for Quake for reasons other than smooth movement, with dropped packets it may still appear choppy unless interpolation is added.
Yep that's true, sorry if I misconstrued that first part :) At 8:00 I'm alluding to the fact that with TCP it has to continue retrying to send that missing packet. If you missed a packet like a player position update, that data really doesn't matter since it's most likely out of date anyways by the time you realize that you missed the packet. But TCP will continue blindly retrying to send that data until it receives it because of the way the protocol works, and that will create a buildup of other unsent packets since they are all waiting for that one missing packet. (Yes I know that TCP probably sends the newer packets as well and just reorders the packets client side once it retrieves all them) I do timestamp positions :). They get inserted into the buffer in the correct order and I also interpolate between the two nearest packets whenever I'm playing the position back client side. Unfortunately when uploading content to YT, it's usually best to gloss over a lot of details to make the video more interesting. I was also trying to condense over 3 months of research and work into a 20 minute video, and as a result it's going to be missing a lot of details because it's impossible to relay all the information in such a short video :)
I agree. I feel ashamed when I'll use several MB of ram to do a relatively simple task instead of coming up with a smart solution like they had to do when they had a few KB of ram haha
@@GamesWithGabe I'm a noob, but I'm wondering if it's worth it to optimize tasks in a way that uses very little memory? Would it make the game run better? I'm curious how to optimize an app or a game as much as possible and if it's worth the labor to do that?
Very interesting. I've done multiplayer before, (with an engine, and without an engine) but, I've never actually known the differences between UDP and TCP :)
Finally minecraft clone which is not a total bullshite. Couple of things: make sure to actually test multiplayer with slow connection (e.g. using vps). Original Doom multiplayer was bad because Karmack had fast cable.
I always thought that the secret within multiplayer games is that the data you give and receive is from dedicated places in your place or country. Add to that some prediction, interpreting and compressed data, also perhaps cache like method.
This clone is the closest looking one to Minecraft, might be because the guy's following the same path Notch did. Hoping you'll get yourself 2.5 billion and nothing controversial in the way!
5:00 though this is correct, remember, our world is not shaped that way. Instead of crossing the entire map, it would simply connect to the left of us.
Amaaazing! I personally love minecraft in the way you can build factories, but mods only carry it so far Interested in the way you will take this gamestyle
me:hmm i wonder how would world look like if gabe time traveled back to 2009 into a parallel universe where notch never created minecraft,then to release his minecraft clone in c++ to the public gabe in the video few seconds later:and the ansver might surprise you,it's time travel
reading your pin, processors do operate at that speed, however you don't want to take the java only programmer approach to developing a large project. ideally you want to set some kind of goal for your calculations so that you can target specific hardware to hit specific load times on single threaded operations unless it is handling multithreaded. having a budget and saying each task should fit in is a much more realistic point of view for dev work flow. that being said, if you are using a i5 nebula max plus rewards program generation as your target platform that is perfectly okay. the rest makes more sense for a database on a multiplayer server. speaking of the crafting 3x3 grid. so for array based communication what I have seen in dev workflow for accessing grid like information would be packaging things into more then 1 array. so for a 3x3 grid you could do 3 arrays (so 3 rows each checking the boxes. simplify it further with empty space being its own null bit to save space and load speeds for massive que systems) instead of running a single operation that brute forces the whole thing. while speed wise the performance in todays hardware is not all that noticeable but when things are coded like that and the crafting system has 10,000 recipes in it, splitting workloads helps quite a bit in a scalable sense. an example for this being really useful is having an item builder tool that lets players make items with templates directly on the game itself with a multi server function that loads that into the DB. 100 people making 50 items each means that load will get big fast. while it is more work to write, that's just how code kind of works in the long run unfortunately for better quality results.
The internet infrastructure is outdated. Every path would need to be replaced and additional paths would need to be added for additional users. Mainly the entire internet needs to be rewired with Fiber Optic cabling. For those who don't know, FOC is a special material that uses light. Google had implemented their own internet service using this wire. Their bandwidth peak was 1Tbps. This bandwidth speed is very important. Unfortunately there is competition when it comes to internet service. Even more unfortunate is that some places block additional providers from entering. Starlink fixes this problem but not the bandwidth speed problem. Satellite is one of those things that works to connect people, but not ideal for online gaming.
hey dude if you plan to make your own separate game from Minecraft, make sure you check Minecraft's legal documentation to make sure you won't get into trouble. Other people have gotten into trouble for making very similar games to Minecraft and it doesn't help that your game started OFF as a Minecraft clone
i like how his graphics look better then minecrafts or they look like a very good texture pack and if this game was for download i would 100% get it!!!
That would be awesome :D . I'm currently coding a self-updating game launcher so that I can distribute the game. I'll leave a community post once I have it working so that people can download the game and play it :)
@@GamesWithGabe 🙌🙌🙌 I know coding is really much time consuming expecially when you stuck in some part where you don't understand it and you looking for answer taking some break time could help for future progress, 🙌 it's amazing that you achieve to this level, also the idea to convert your project to your own game title is nice idea
I heard that on cellular connections, you should consider TCP for games, due to last-hop retransmit abilities being better than anything you could build yourself on top of UDP
Your valid craft check is O(n) at the minimum, maybe even O(n^2), you could definitely speed this up with something like a trie. Larger memory allocation, but definitely worth it when expanding recipes.
Interesting. You can check out the pinned comment for more info. The tldr is I don't plan on improving the algorithm right now because it would be a performance gain of a few microseconds a frame at most. Which, for all intents and purposes, is negligible at this time :)
@@GamesWithGabe If it ain’t broke, don’t fix it. Nothing wrong with that, especially considering your original code is probably more legible to yourself.
You probably already noticed, but the different block types don't work with the ambient occlusion. Maybe the blocks could all be divided into 8 and have the same system used on the block divisions.
GamesWithCube: I basically go through all the possible recipes then start checking to see if any of the recipes match what the recipe should be... Me, an engineer: But what if you have 2,147,483,647 recipes???
btw people even in 2019 had internet download speeds of 1.4 gbs if I’m not wrong. I do remember my friend being able to download anything within seconds just with the 900 mbs
I would rather build the recipy matching like a convolution. Store the items as a byte, 3x3 matrix can be represented as linear array. And then apply And operator or something like that with all combinations available
This is all really cool. I wonder if you could do a similar video to your Technical Feat video on how 1.18 is a feat too, and how it's changed even more than we know about
About the *crafting table algorithm*. A lot of you have pointed out that it is grossly inefficient, and I should swap it out for some hash and compare algorithm. This is true, but let's do a little thought experiment.
According to the table here: www.agner.org/optimize/instruction_tables.pdf, it looks like comparing two 32 bit integers takes about 3 cycles for Intel Sandy Bridge (an i5 processor), assuming no cache misses etc. You need to move two numbers, which requires 1 cycle each (also ignoring reciprocal throughput), then compare, which takes 1 cycle (ignoring reciprocal throughput). My crafting table consists of a 16 bit number for the item id, and an 8 bit number for the item count for each slot. So, let's round it up to 32 bits and assume comparing two slots is the same as comparing two 32 bit numbers. That means it takes around 3 cycles each to compare two slots.
If I compare my crafting table to one recipe, that's 9 slot comparisons total, or around 9 x 3 = 27 cycles. So, if I go ahead and say that I have 1,000 recipes to check against, then that's a whopping 27 x 1000 = 2,700 cycles. On an Intel i5 with a clock speed of 1.6 GHz, or 1.6 billion cycles per second. One frame of a game is 16ms, so lets say we have 1.6 billion * 0.016 = 25,600,000 cycles in one frame of our game at 60fps. This means that checking if the user got 1 recipe out of 1,000 possible recipes would take around 0.01% of our total frame time, or around 1.69 microseconds :). If we have 10,000 recipes, that would take around 0.1% of our total frame time, still not even 1% of our processing power in one frame.
Now of course this ignores cache misses and all that stuff, but the point I'm trying to make is brute force is not always the worst solution. It's often the simplest algorithm, which it definitely is in this case, which leads to less bugs. Keep in mind that I only run this algorithm when the player updates a block in the crafting table. Human reaction speed is around 0.186 seconds at its fastest according to Google. In other words, they probably won't be clicking fast enough to ever have a lag spike because of this algorithm.
Collin Ames did some calculations with cache misses taken into account in the comments, and calculated it to around 20 microseconds for comparing 1,000 recipes if you're interested :)
I *always* profile my code *before* trying to optimize stuff, and my hottest path is anything that has to do with updating a chunk. One chunk is 16x16x256=65,536 blocks, each 64 bits. That's a much much larger loop than checking a crafting recipe, and that's where I focus most of my attention when optimizing my code (it also turns out to be the hottest path every time I profile it).
So, when I completed this algorithm, and it didn't show up as a hot path, I moved on to other problems since I only have so much bandwidth as a solo developer :)
TLDR; Don't assume where the hot paths in your code are, profile it. You'll learn way more that way ;)
@Harrison I definitely have the same problem of optimizing stuff that probably doesn't matter :pain:. And the hashing is still an awesome solution that's pretty straightforward and I wish I would have thought of :). It's also pretty simple, so I'll go ahead and implement it if I have some spare time, but when I coded this my gut feeling was "this probably won't effect performance as much as most of my other code", and I probably should have verbalized that a bit better in the video :)
try to check what minimun ingredients at look up table are in the grid (careless of position) And you get busted a lot of recipes with one shot, then brute force it as before and the amount of test will be less
I understood some of these words. :)
I want to start out by saying that it's great to see your analysis of this, and you have a good process for solo development. I'm just responding to this as a thought experiment :)
IMO, there are two flaws in your logic that make the original implementation unjustifiable:
1. You talk lots about the performance of this algorithm. Let's assume that Collin is right, and this takes 20μs to compare 1,000 recipes (b/c I'm a lazy programmer and don't want to do the math myself). If you expand that information to your 10,000 recipe example, it's now taking 1.2% of your processor cycles at 60Hz. I'm not sure why 1% of a frame at 60Hz is where you drew the line, but that's already quite substantial for what should be a cheap algorithm, and it's entirely possible to go over 10,000 recipes with recipe variations in modded Minecraft.
2. You say "[Brute force is] often the simplest algorithm, which it definitely is in this case, which leads to less bugs." The only way this could possibly be true is if you've never heard of java.util's Map class (or C++'s std::map). This class trivializes recipe checks so much that I can write the Java implementation legibly in a youtube comment: recipeMap.containsKey(currentRecipe). There's no way that an iterative method could be simpler or have fewer bugs than a single function call from a standard library.
A couple other corrections (though they don't change your argument much):
1. You say "Human reaction speed is around 0.186 seconds at its fastest according to Google. In other words, they probably won't be clicking fast enough to ever have a lag spike..." Here, you are looking up information that doesn't measure what you're talking about. What you're looking for is clicks per second, which seems to top out around 14 clicks/sec. That results in one click about every 0.07 seconds, which means this algorithm could run three times in a single frame at 60Hz, tripling its cost to 3.6% of your budget in the worst case.
2. You say "One frame of a game is 16ms." This is obviously false, but I understand that you meant to say "I'm targeting 60Hz for this game." Your rounding (16.66... -> 16) also causes your estimates to be more conservative, so there's no problem there. The underlying assumptions you're making, though, are increasingly problematic. More and more consumers are buying displays that support 120Hz and variable refresh rates, and new consoles are taking advantage of these features. To support both VRR and people who don't use V-Sync, you should be looking at your frame pacing (time between frames) as well.
Also, just a general comment on profiling - there are times when you'll have to profile one specific scenario to "light up" a code path. This specific code path isn't run for 99.9% of frames, so it obviously won't show up as a hot path if you profile with normal gameplay. That doesn't mean that players won't notice it when it does show up, and if you wait until you get user feedback ("Every time I craft something, my mouse lags"), it will probably take a lot longer to figure out what's happening.
@@dallasjohnson2635 maybe I should have phrased the original comment as "this is just some napkin math to illustrate a point" haha. I appreciate the response, but I'm just trying to illustrate that this algorithm runs on such a small data set that it's not worth my time to optimize it for a microsecond (at most) performance improvement per frame. A lot of people like to look at one specific algorithm, but a game is thousands of algorithms running simultaneously, and it's _always_ better to look at the algorithm _in context_ :)
1. I chose 1,000 recipes as a crazy outrageous number that I'll most likely never reach. According to the Minecraft wiki minecraft.fandom.com/wiki/Crafting#Recipe_system there are only 379 recipes in vanilla Minecraft as of 1.16. So I think I have plenty of time before I begin reaching 1-10,000 recipes lol
2. I think this is a bit disingenuous. Sure the API for a Java Map or C++'s std::unordered_map is simple, but you still have to implement the equality operation to ensure that it knows how to check if two recipes are the same (which is the same code I wrote anyways). You also have to implement a good hash, otherwise the map doesn't help much at all, and can often be just as bad as a regular linear search, check out this SO question stackoverflow.com/questions/1757363/java-hashmap-performance-optimization-alternative . This requires a lot of extra knowledge and implicit complexity.
For your last two comments, I am targeting 60 fps, maybe I'll target a higher frame rate in the future. And once again, the reaction speed was just for napkin math to do some quick comparisons :)
And when I profile, I do target specific events when I'm profiling a certain section of code (Visual Studio allows you to actually select the time period you would like to profile which is very helpful in this regard). My point was that comparing crafting recipes is literally orders of magnitude less then simply iterating over one chunk (400 recipes compared to 65,536 blocks in one chunk). There's usually 12 x 12 x 3.14 chunks in the game at the default settings (that's around 29,600,000 blocks, 74,000 times larger than all the recipes). This means that if a player is going to be noticing lag, it's most likely going to be when doing anything with chunks.
All this to say, yes I know the hash is a better algorithm. But right now, as my code is, I'm not going to spend a bunch of time optimizing an algorithm for a few more microseconds per frame. If the requirements change, and I have to find 1 recipe out of 10,000, then I'll change the algorithm :)
That plan to make your own game based on the engine is really exciting. That ambient occlusion really makes it look good.
Thanks Asher! And yea I figured it was time for me to try to actually create a game instead of just a fancy tech demo haha
@@GamesWithGabe What's next, mobs or smth?
@@memelord4006 nah i think that ai would be too hard for now
@@somefish9147 isn't it literally just a shader + a normal unity game
@@somefish9147 the ai on the mobs on Minecraft its dumb, it wouldn't be so hard
I love this
Minecraft has a very old lighting system that I wish they can change or update, is almost been the same for years now, and I love any mod that had dynamic lighting for Minecraft
I literally just want coloured lighting, ive had a concept I've wanted to make for forever but I cant cus no matter which mods and shaders I install, I cant find any that allow coloured lighting
Rethinking voxel may work for colored lights but they are under development
This channel is criminally underrated.
@GamesWithGabe, Bro stick to one subject video. You're all over the place and your title was about multiplayer. And you're wrong @ 7:17. UDP packets never disappear into the void. They arrive at their destination in the wrong sequence which can be resolved by using a hybrid of TCP and UDP.
I appreciate the feedback @Battosai Jenkins! And I was referring to dropped packets at 7:17 which is a pretty common issue with UDP jvns.ca/blog/2016/08/24/find-out-where-youre-dropping-packets/#:~:text=lost%20on%20the%20way%20out&text=The%20Linux%20kernel%20deals%20with,So%20you%20will%20drop%20packets. . And I titled this video about multiplayer because that's what the bulk of it was about haha. This is a devlog and I want to cover everything that I've done in the past few months, but I also want to give weight to the most difficult feature I implemented over that time period
@@battosaijenkins946 chill
Glad it was recommended. Been trying to find more things like this for ages.
@@battosaijenkins946 bro chillllllll
I love these types of video's just because it's a good way to get to know new interesting concepts
You can actually use both TCP and UDP. Just connect to a server twice on two different ports. We used that in our own multiplayer. We sent important messages like player join notifications and chat messages on one and player position data on the other
Instead of sending packages every single frame and delaying them you can just send them more rarely and interpolate between received results. It's a lot easier on the server and delay is as short as possible. Once you received a package where player started moving in certain direction you can just complete that movement until new package arrives, when you will just correct player's course to align with new data
Also slabs are horizontal in Minecraft :)
sup, do you have any tips how to start understanding how to code multiplayer
@@seekyunbounded9273 The video explained a lot, you can google search the rest
@@seekyunbounded9273 by now you can probably use chatgpt
this TCP and UDP thing is actually what minecraft does
Yes. And it seems wrong to me using only one of them, since UDP is better for some features than TPC. Voicechat or moving the playes in some games for example
Threw this on while playing minecraft. I could listen to this guy ramble all day, seriously.
You said "Surely, I can achieve the same thing right now" right as I noticed how long that chapter is.
Haha yea, the time I spent on it reflects how long it actually took me to code it. Crafting took a couple days, colored lights and custom blocks took a week, and multiplayer took 3-4 weeks :D
idk what engine you are using, but I have tried to clone the minecraft inventory system before. IT IS HARD. The amount of work you did to not only get its base functionality working, but even more subtle features is not unnoticed. You're a legend.
Crafting matching would had been better (and much faster) by using hashes. Will just be a hashmap search. A formula like sum((x^y*materialtype))%something would work for the key.
Ooh thanks for this insight Marc! I don't know why I didn't think of that haha, but I'll definitely be adding this to the code :)
@@GamesWithGabe Yeah just simply match the materials your crafting with a subset of "possible" recipes for the given materials, then just loop through that smaller subset of craftable recipes.
as Marc said, using hashmaps would do the trick. Just build a database at the start of the game (or once everytime you add new recipes) that contains grouped recipes based upon their ingredients, when you match all the ingridients that you have in your crafting gui with the "group" that uses said materials, then loop through all possible recipes inside that caches group. This should reduce from O(N) to O(log N)
@@mrmaniac9905 Was thinking on an even simpler way, with a continuous hash, you just have to store all possible recipes on a hashmap using sum(x^y*materialtype) as hash function. Then just start with a current hash of 0 and an empty crafting grid, everytime a material is added on a position, calculate (x^y*materialtype) add it to the current hash, and every time it's removed, substract it.
After every click, just search the hashmap. If there's a matching recipe, it will be returned.
@@framegrace1 Ah, I see what you're saying, that's actually very smart. That in theory would work in constant time. I'm actually gonna implement that in my own game.
I hope you achieve your goals man all of this is really impressive I hope I will be a good programmer like you one day
You will be a legendary one.
I agree with Ozzy's script! Good luck with your programming endeavors, and I'm sure you'll do some great things :)
@@GamesWithGabe thank you
@@professor_ozzy thank you
@Buis Bo Going great! I had some mental issues lately but I have my big programming projects that I am constantly working on :)
4:45 the solution is do the calculation on your side, then checking with the server, and if it is wrong, the server corrects you, this is commonly known as rubber banding.
Client side prediction
Rubber banding is a side effect of client prediction that is incorrect from the server. You can avoid rubber banding with interpolation to make perceived latency less noticeable.
Of course, this compromise also means that hit boxes aren't accurate and optimistic updates can cause data loss (i.e. crafted item wasn't received or verified correctly by the server) in high latency servers.
@@dealloc that's why the hit reg feels horrible in games like Valorant which is heavy on client prediction.
@@LuisCassih It will definitely will feel bad when you have a long latency. I don't know how Valorant client prediction works and when it kicks in. But a common practice is to use server reconciliation to solve desynchronization issues by sending a sequence number with the data, which can then be used to reconcile commands later on the client. Then reapply those commands that haven't yet been predicted by the client. That way it doesn't need to re-run commands that have already been predicted, while ensuring consistency with the server for both high and low latency players.
This is how QuakeWorld (and Half-Life et el.) works.
The more technical term for rubber banding is rollback netcode, since if you do something the server doesn't like you get "rolled back" to whatever the server saw last
Awesome video as always! I would love to see more in-depth technical videos on a single feature with those animations, you do a great job of explaining this stuff
Thanks benpope! The minecraft tutorial series that I'm creating should hopefully do just that :)
8:03 “240 seconds, that’s three minutes!”
I’m learning so much from this video
180 seconds
it feels weird to be following the game engine tutorial series and then seeing you here on the present with a different vibe.
Good progress on the game! And the video is also a masterpiece
This is so cool. I love the breakdowns of techniques and reasonings. Although you lost me when your started talking about feeding data to the gpu, because that's high level stuff there mate. I find It's hard going from some coding classes, game design c# and python to actually implementing and creating something all by yourself.. Great videos.
Never thought I'd find the clearest explanation of TCP/UDP in a damn minecraft video. Well done!
Ayyyyyooooo I saw this on my "home" page and I just knew I'd love it. Subbed at 00:07, this is gonna be a blaaaaaast
Amazing video, thank you for explaining what you did every step of the way. Someone who is an amateur like me can understand everything you’re talking about, and that’s just amazing to me :) keep up the great content, loving these dev logs
Your ability to simplify complex concepts is amazing. I hope to build that super power.
This was surprisingly easy for me to understand, especially the multiplayer and lag compensation segments!! Usually I really suck at understanding something like this but you explained it very well. :)
I've been following this series just because the vids randomly appear at my yt homepage. I finally subscribed, and I'm looking forward to the new project!
Making my complete own version of Minecraft is something I've really wanted to do as well, but I have very little programming experience. It's nice to see someone else actually achieving it though!
Your devlogs are really inspiring to small developers like myself. Please keep making these videos! 🙏
I definitely will, it just takes a really long time to make anything significant haha
@@GamesWithGabe yeah, that would make sense, haha!
Thank you robot overlords for shoveling me in this direction. I don't have the spoons to watch this right now (ironically, I'm learning to code a minecraft datapack and occasionally yelling at brackets i SWEAR I counted before) but it's now in my "to revisit later" playlist.
i learnt more in this video than i did in most of my ICT classes, amazing vid!
Omg, manim always makes me so happy to see! Good video!
Great work on this so far. At some point it would be good to see a non constant velocity when moving, using acceleration and deceleration, in Minecraft this is subtle but it makes a big difference.
Another thing I can suggest is to work out the longest time a player takes to ping on the server and set the buffer time accordingly; if two players on the same LAN network have to deal with 300ms of ping it could be quite annoying. For a larger server you'd probably want to take the median ping of all players and set the time to that, so one player having a hugely high ping does not affect everyone else too much.
Also, consider that players can cheat as the clients are just telling the server where they are going, the server is not confirming or denying whether this is possible or not. Some games solve this by only sending what inputs are being given and the server confirming what should happen, while the client predicts what it believes should happen.
My brother also mentioned adding a quick acceleration to the player controller haha. And I'll be adding some anti cheat mechanisms and stuff in the future, as well as some more intelligent buffer times for all the players :)
I have only the very barebones basics of coding so far, but this video still gave a ton of cool insights for the future!
Dude, I love you. I really wanna see more of this game building process. Hope you all the best
Thanks for your videos, really I learn a lot. Right now I’m not working as programmer but I have a plans to create a game and all this information will help me in the moment when I start to create my game. Thanks a lot.
Bro really had me watching the entire video without understanding shit, the explanations were awesome the video was even more awesome good job
Just found out about your channel, this content is really good! Please continue on making these!
I have no plans of stopping anytime soon :)
This could turn out amazing! I can't wait to see what kind of things you end up doing with it!
This is amazing! Making your own game out of this is brilliant, finally someone has that idea! I've seen so much potential in these Minecraft copies devs make, but they never try to actually make a game out of it that would be better than Minecraft, something different. There's so many things I wish Minecraft would be like, but it never happened. From simple things like improved physics to more realistic crafting to making cubes smaller, so that there's a lot more options to create things and how they would look like. Also, congrats on making multiplayer possible, I bet it wasn't easy. UDP is the best choice and there are also different types of UDPs like RUDP. I just think about if 300 ms of buffering would be good enough for PvP for example. I imagine CoD MP has figured this out in much more complicated way. They are probably checking who fired first and what were the real locations on their client side, but somehow it has to calculate probability most likely. And there are also problems with hacking and all that crap. There also have to be the distance prioritization to sync player's location. Multiplayer is just very difficult to make. Anyway congrats on making your AO, that's very hard as well! I love the progress!
Thank you so much for the awesome comment! I do imagine the CoD devs have some insane code for multiplayer PvP (at least I hope they do haha). The multiplayer is still definitely a WIP in my game right now as well, so we'll see if I completely change it in a month or two 😁
Block story was really cool, it has its problems but I loved it when I played it years ago
I've seen enough "I remade minecraft but this and that" videos. This is much more entertaining in my opinion.
Holy its good to see where the project went.
Wonderful video! I'm not a game developer by any means, but the way you put the video together is very entertaining! I've subscribed and can't wait too see where you take the project! Don't push yourself though, your mental and physical health is much more important! Good luck with the game!
A full 3 minutes is 180 seconds; 240 is the windows default of 4 minutes. the true default is anywhere from 5 minutes to 15 minutes, depending on the RFC / standard you're going by.
These devlogs are very good quality!
Very good video! I don’t do any gamedev but I find these so interesting!
just imagine how cool the modding community would be!
I would love to see the tutorial detailing time, ticks, etc for multiplayer. Can't wait!
This is cool and I don’t know a thing about programming or game dev. 😂 Very informative, best of luck w the rest of the labor on this project
ambient occlusion is actually really simple. less light reaches occluded surfaces, so they appear darker. surfaces are occluded when they are partially covered. i think its actually extremely reasonable that the more a surface is covered, the less light would reach it.
Feels like I'm watching a 3blue1brown video, great editing!
Thanks! I use the manim library for my animations, which grant Sanderson developed and the community had created a version based off of. So full credit to 3blue1brown for the awesome software :)
to optimize the checking for the stick recipe you could just check the middle row, and if you find nothing that matches, then discard it, if you find a plank, check above and below it, and if it matches make sure all the unchecked other slots are empty. Doing it this way would make it so you only need to check every slot once.
Imagina creating algorithms for almost every crafting recipe. That wouldn't be very efficient
@@t4g2s It would take some time to create, but it can increase performance
@@m4rt_ I think it would be better Tham creating bruteforcing
Good stuff. I'm trying to make a LEGO game for myself. Coming from zero game dev experience, this stuff gets confusing/frustrating but then there are those brilliant moments of clarity when things work perfect. I'm currently trying to create a master flight template so I can just customize flight attributes and control ship specific animations.
15:35 One of my best CS professors said "everything can be solved with enough layers of indirection"
Very cool project! Can't wait to see more
I would be very interested to see notch giving insight into this. That would be really cool
this is just awesome
The fact this guy is taking the chance Mojang or Microsoft dont come and give you a: naughty boy message saying go to court now kid is brave
You hav my respec
4:17 This section doesn't sound right to me, the round trip does not affect the time between packets. If you send a packet 60 times per second you wouldn't see a difference in time between each movement at 1/2 the round trip time. You would just see their movement at 60 times per second (ignoring dropped packets) with a delay of 1/2 the round trip time as that is how long it takes for those packets to get there. The only way you would see something like 5fps for that example would be if you actually waited for an ack before sending a new position packet.
8:00 I'm really confused as to why this is considered an issue. It's 3 minutes before we consider the connection to be dead and kick the player, you should have something like this implemented to handle a situation where the game is improperly closed such as the user's computer turning off from a storm.
Something unclear to me as you're using a buffer and unreliable packets for position, is whether you timestamp the positions in the buffer or wait for it to fill to update the visible position. If you're just waiting for the buffer to fill you can have issues from dropped packets causing the positions updates to slowly increase in delay.
The buffer solution also sounds like it may have been picked for Quake for reasons other than smooth movement, with dropped packets it may still appear choppy unless interpolation is added.
Yep that's true, sorry if I misconstrued that first part :)
At 8:00 I'm alluding to the fact that with TCP it has to continue retrying to send that missing packet. If you missed a packet like a player position update, that data really doesn't matter since it's most likely out of date anyways by the time you realize that you missed the packet. But TCP will continue blindly retrying to send that data until it receives it because of the way the protocol works, and that will create a buildup of other unsent packets since they are all waiting for that one missing packet. (Yes I know that TCP probably sends the newer packets as well and just reorders the packets client side once it retrieves all them)
I do timestamp positions :). They get inserted into the buffer in the correct order and I also interpolate between the two nearest packets whenever I'm playing the position back client side.
Unfortunately when uploading content to YT, it's usually best to gloss over a lot of details to make the video more interesting. I was also trying to condense over 3 months of research and work into a 20 minute video, and as a result it's going to be missing a lot of details because it's impossible to relay all the information in such a short video :)
the math parts and coding parts of this video is too smart for me to understand 🙃
Release the multiplayer background guide video!! Been so interested in all these topics and would to implement them myself. Cheers!
Really cool, learning about these multiplayer solutions! I feel like programmers had to be so much smarter back in the day
I agree. I feel ashamed when I'll use several MB of ram to do a relatively simple task instead of coming up with a smart solution like they had to do when they had a few KB of ram haha
@@GamesWithGabe I'm a noob, but I'm wondering if it's worth it to optimize tasks in a way that uses very little memory? Would it make the game run better? I'm curious how to optimize an app or a game as much as possible and if it's worth the labor to do that?
@@Slydime917 It just feels better and works better on lower end PC's
Very interesting. I've done multiplayer before, (with an engine, and without an engine) but, I've never actually known the differences between UDP and TCP :)
Really cool, you should make a tutorial on how to implement multiplayer in the java game engine!
you really inspire me to make a game from scratch like you do ( Not completly from scratch as I want to use OpenGL :p )
Finally minecraft clone which is not a total bullshite. Couple of things: make sure to actually test multiplayer with slow connection (e.g. using vps). Original Doom multiplayer was bad because Karmack had fast cable.
I am not smart enough to understand half of what you were saying but it's super cool seeing it happen
I always thought that the secret within multiplayer games is that the data you give and receive is from dedicated places in your place or country. Add to that some prediction, interpreting and compressed data, also perhaps cache like method.
This clone is the closest looking one to Minecraft, might be because the guy's following the same path Notch did. Hoping you'll get yourself 2.5 billion and nothing controversial in the way!
17:00 this really sounds like idea I had basically minecraft + dont starve in short
I think using a hashset to determine the recipe would be more efficient if you were to have a large number of recipes
I hope they implement RGB lighting into vanilla at some point in the future.
Yey, it looks like someone is about to recreate minecraft but whit out all the controversial updates :D
now i realize how much effort was put into those free "minecraft" games on the app store when i was 10
" hopefully in 1080p "
me in 240p * awkwardly watches to the side *
IPX for the win, best protocol for multiplayer!
That crafting table comment your very smart my sir bc I understand 0 of that info but I'm high and that sounds right too me
5:00 though this is correct, remember, our world is not shaped that way. Instead of crossing the entire map, it would simply connect to the left of us.
Have you finished watching the video? ;)
Underrated channel
Amaaazing!
I personally love minecraft in the way you can build factories, but mods only carry it so far
Interested in the way you will take this gamestyle
Do you play create mod?
really cool concept for a game!
Java is honestly so great for game development all it needs is some tutorials to teach us noobies thank you for this
me:hmm i wonder how would world look like if gabe time traveled back to 2009 into a parallel universe where notch never created minecraft,then to release his minecraft clone in c++ to the public
gabe in the video few seconds later:and the ansver might surprise you,it's time travel
reading your pin, processors do operate at that speed, however you don't want to take the java only programmer approach to developing a large project. ideally you want to set some kind of goal for your calculations so that you can target specific hardware to hit specific load times on single threaded operations unless it is handling multithreaded. having a budget and saying each task should fit in is a much more realistic point of view for dev work flow. that being said, if you are using a i5 nebula max plus rewards program generation as your target platform that is perfectly okay.
the rest makes more sense for a database on a multiplayer server.
speaking of the crafting 3x3 grid. so for array based communication what I have seen in dev workflow for accessing grid like information would be packaging things into more then 1 array. so for a 3x3 grid you could do 3 arrays (so 3 rows each checking the boxes. simplify it further with empty space being its own null bit to save space and load speeds for massive que systems) instead of running a single operation that brute forces the whole thing. while speed wise the performance in todays hardware is not all that noticeable but when things are coded like that and the crafting system has 10,000 recipes in it, splitting workloads helps quite a bit in a scalable sense. an example for this being really useful is having an item builder tool that lets players make items with templates directly on the game itself with a multi server function that loads that into the DB. 100 people making 50 items each means that load will get big fast. while it is more work to write, that's just how code kind of works in the long run unfortunately for better quality results.
Imagine having family members who are capable of helping you build a game.
The internet infrastructure is outdated.
Every path would need to be replaced and additional paths would need to be added for additional users. Mainly the entire internet needs to be rewired with Fiber Optic cabling.
For those who don't know, FOC is a special material that uses light. Google had implemented their own internet service using this wire. Their bandwidth peak was 1Tbps. This bandwidth speed is very important.
Unfortunately there is competition when it comes to internet service. Even more unfortunate is that some places block additional providers from entering.
Starlink fixes this problem but not the bandwidth speed problem. Satellite is one of those things that works to connect people, but not ideal for online gaming.
hey dude if you plan to make your own separate game from Minecraft, make sure you check Minecraft's legal documentation to make sure you won't get into trouble. Other people have gotten into trouble for making very similar games to Minecraft and it doesn't help that your game started OFF as a Minecraft clone
Umm 8:01 I’m pretty sure 240 seconds is four minutes not three
btw if that's supposed to be seattle or tacoma on the internet map it's a bit off if it's supposed to be portland it's nearly there
i like how his graphics look better then minecrafts or they look like a very good texture pack and if this game was for download i would 100% get it!!!
This look awesome!!
Minecraft Java Edition Servers use TCP for server information only and UDP for the actual gameplay stuff. Opening to LAN only uses UDP afaik.
Im ready to start test this game and make videos about it
That would be awesome :D . I'm currently coding a self-updating game launcher so that I can distribute the game. I'll leave a community post once I have it working so that people can download the game and play it :)
@@GamesWithGabe 🙌🙌🙌 I know coding is really much time consuming expecially when you stuck in some part where you don't understand it and you looking for answer taking some break time could help for future progress, 🙌 it's amazing that you achieve to this level, also the idea to convert your project to your own game title is nice idea
I heard that on cellular connections, you should consider TCP for games, due to last-hop retransmit abilities being better than anything you could build yourself on top of UDP
Your valid craft check is O(n) at the minimum, maybe even O(n^2), you could definitely speed this up with something like a trie. Larger memory allocation, but definitely worth it when expanding recipes.
Constant time lookup, as you'd be traversing or indexing through your trie depending on block placed.
Interesting. You can check out the pinned comment for more info. The tldr is I don't plan on improving the algorithm right now because it would be a performance gain of a few microseconds a frame at most. Which, for all intents and purposes, is negligible at this time :)
@@GamesWithGabe If it ain’t broke, don’t fix it. Nothing wrong with that, especially considering your original code is probably more legible to yourself.
I don't know about other games, but Minecraft does not send packets at 60fps, in fact, movement packets are handled by tick, so at 20tps.
You probably already noticed, but the different block types don't work with the ambient occlusion. Maybe the blocks could all be divided into 8 and have the same system used on the block divisions.
Ah, yes. A clone of Minecraft which is secretly a clone of RubyDung. The cycle continues.
GamesWithCube: I basically go through all the possible recipes then start checking to see if any of the recipes match what the recipe should be...
Me, an engineer: But what if you have 2,147,483,647 recipes???
Seriously tough, I believe you've implied that you use a hashtable for that.
btw people even in 2019 had internet download speeds of 1.4 gbs if I’m not wrong. I do remember my friend being able to download anything within seconds just with the 900 mbs
I would rather build the recipy matching like a convolution. Store the items as a byte, 3x3 matrix can be represented as linear array. And then apply And operator or something like that with all combinations available
Minecraft uses a combonation of TCP and UDP thats why when you port forward a server you have to port forward UDP and TCP
This is all really cool. I wonder if you could do a similar video to your Technical Feat video on how 1.18 is a feat too, and how it's changed even more than we know about
Great! You're doing a great thing!
I don't understand how the buffer thing works, how can you reduce latency by intentionally adding latency? Can someone explain?