Adding Multiplayer, Colored Lights, and More | Coding Minecraft Devlog #2 

@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 :)

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 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

@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

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

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

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.

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

Thanks benpope! The minecraft tutorial series that I'm creating should hopefully do just that :)

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

@@Soulis98 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 :)

I have no plans of stopping anytime soon :)

180 seconds

I definitely will, it just takes a really long time to make anything significant haha

@@GamesWithGabe yeah, that would make sense, haha!

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

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! 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 :)

Do you play create mod?

Thanks! And for the inventory GUI I just used a couple of for loops and some ImGui style logic haha. If you've ever worked with a library like Dear ImGui it helps solving these types of problems. And if you take a look at the drag and drop implementation in Dear ImGui, you can definitely see where I get inspiration from :)

Making a database builder could simplify shapeless crafting by generating multiple recipes (9 in the case of a stick) at the cost of waaayyy more recipes to cross check. You could possibly categorize the recipes by the first item id encountered to reduce the number of recipes the engine needs to cross-check?