There are a couple of different reasons why I think this, at least in my opinion. Here are my top five reasons why.
You'd think with an indie studio like Mojang, they would offer more meaningful content than what we actually got.
This just proves why, in my opinion, AAA games will always be superior to indie games, and that's not to throw any shade at the latter. However, when I first bought this game (I actually got the Bedrock Pocket Edition first on Christmas of 2012, ten years ago, while I got the original Java Edition seven days later on the very first day of 2013, January 1st), I expected a whole lot more from that title. Being a gamer who's played the likes of Lego Creator and Dino Island (yes, that game exists), I genuinely expected Minecraft to expand on those formulas even more, with the ability to fully build both in form and function. Fun fact: I actually left a review on Metacritic on Minecraft stating its flaws at least two years ago, and I'd have to go with Whitelight's opinion on the fact that the "you can build anything you want" idea is only half-true.
I expected to be able to pivot blocks using motors and levers, and even rotate sets of blocks to create dynamics such as large ships and robotic arms. However, this sadly wasn't the case for me. By discontinuing Minecraft after 1.20, we won't have to worry about features we actually wanted never actually getting implemented, because development would've stopped altogether. I think that Mojang deserves a vacation, perhaps a permanent one at that.
They never actually fixed the problem with obfuscated code forcing people to "update" mods just to get them working on other versions.
The problem is getting truly ridiculous, and you'd think with an indie studio representing the savior of gaming, they would actually be considerate of people that would love to mod or hack the game to create different experiences. But unfortunately, obfuscating the code makes it harder for people to actually mod the game itself, and I highly doubt that the obfuscation is even really necessary. I know it's to help prevent people from pirating or cracking the game for free, but it just seems like overkill to me, especially with such a massive and vibrant modding community surrounding Minecraft. By discontinuing development on Minecraft, people won't have to worry about updating to new versions anymore, especially if Mojang were to insist that their obfuscation of code helps with preventing piracy.
Mojang has had a track record of practically promising features for the game itself, yet never actually implementing them.
Trust me, I've seen Minecraft's history, even if I was a relatively late user starting at Christmas of 2012 and the very beginning of 2013, that is. Even the relatively later versions such as 1.19 have had their share of issues; I mean, most frogs don't eat fireflies, but we don't have to be totally realistic with the feature set. Yet at the same time, 1.7 introduced Acadia wood with the wrong species, and therefore the wrong color. I know this because of a thread I've seen a long time ago on this forum. It still irks me to this day that they would have no clue which Acadia trees belonged where, and I'm willing to bet that they've stood by their idea even though people have pointed it out otherwise. And yes, the color is ugly and could've easily been avoided with a little more research on Mojang's part.
Another feature that was not only "promised" back in 1.5, the Redstone Update, yet not delivered until 1.8, but even then, was so difficult to understand that you'd think it was broken, was minecart coupling. To add insult to injury, this feature is entirely absent in Bedrock Edition -- my preferred edition of Minecraft to play on -- and so is the furnace minecart. Although personally, this is more of a blessing than a curse, as there's nothing complicated to "learn" here, that word being used loosely because it's practically impossible to figure out without a guide or YouTube video.
AAA can just build better games anyway. I've seen this from experience.
One game that I've been fond of as of late is Pokemon Legends: Arceus. Playing it today, it feels much more like what indie games could've been than the actual games themselves. It actually gives you a reason to set out for a destination in the morning, just as one example. Now, I know that people tend to say that AAA has either been making poor content for a while now, or has never made good content, to begin with, and that indie games are the way to go for the future, but the ugly truth is, a lot of what indie games are built off of comes from the internet, and with today's internet, a lot of false information, especially about AAA game development studios, goes around like a swarm of locusts eating the farmers' crops.
In other words, the ugly truth is that indie games are based on a lot of false information you might see on the news, or see from what you thought was a "good friend" of yours. The truth is, AAA is still just as good as ever; they're still trying to find new ideas for their games and content. By going ahead and ending Minecraft's development on 1.20, the game can not only be considered "finished", as we will see in the final bullet point, but we won't have to worry about any disappointment anymore. And like I said before, the game never felt like to me a properly polished experience here.
The game never really felt "finished" to us, but rather, like a program still in development to this day.
This issue and the reason why development should stop at 1.20 is what irks me the most. You'd think with all these updates, the game would actually have been finished a long time ago, and we would look forward to seeing new content as time went on. But unfortunately, reality shows that it's simply not the case. As mentioned in the first bullet point, we actually expected more from Mojang than just a mishmash of features with no real rhyme or reason that they're even together, to begin with. Put simply, ending development on Minecraft by 1.20 will ensure a truly finished product.
BONUS: There are other games like Minecraft that have done better in certain areas than others.
I know this is a little unrelated but bear with me here. Survivalcraft, my favorite game like Minecraft for its sheer realism, feels like the real world and puts otherwise-fantasy features in a realistic manner, such as diamond items and supernatural creatures. Total Miner allows you to copy and paste blocks easily with no fuss whatsoever and even Minetest has that hobbyist's touch to it. Even AntVenom once stated that it could be better than Minecraft, which isn't entirely wrong, given the context that Minecraft could come off as at times. Overall, there are just newer and better games.
Overall, it seems like a shame that in my humble opinion, Minecraft should end development by 1.20, but the truth is, lots of my friends like Ryan and Mason have permanently moved on from Minecraft, and have not looked back since. This is because they've seen similar issues with the game besides what I just told y'all about, and I'd have to agree with them wholeheartedly.
It's also worth checking out my mod for Bedrock Minecraft called Order of the Stone, which can be found in my signature. Thank you very much.
FAQs
"Minecraft deserves to keep being updated, perhaps forever."
This leads to my disclaimer: I'm personally completely fine if the game is still being updated past 1.20; I just personally feel that Minecraft is better off not being updated anymore past 1.20. If you don't understand what I'm talking about, please read through the post again.
"Your statements are invalid; indie games have a lot more creativity than AAA."
Unfortunately, that's where I'll have to disagree with you. I could never separate myself from games such as those on WildTangent and even mobile games such as Township, since they really felt like the real thing. Also, there's no such thing as a valid or invalid opinion; everyone has their idea on how things should go, and I'd highly recommend you respect my opinion. I'll certainly respect yours, will I not?
"I don't understand you. You're just plain crazy."
Then fine with me. If you're still willing to think I'm crazy after reading through this ugly truth, I'm not going to argue with you anymore; you're entitled to your own opinion, and I'm entitled to mine. And the Minecraft Forum has seen many similar complaints much like this one. And now, enough said.
Rollback Post to RevisionRollBack
Order of the Stone - A mod idea of what Minecraft could've been had it been developed by a team with more expertise; by professional developers and producers.
I know it's to help prevent people from pirating or cracking the game for free
Ironically, you don't even need to mod the actual game to pirate it - the launcher itself is what actually enforces it, either by adding a "-demo" parameter to the game if you haven't bought it (fun fact: versions prior to 1.3 do not recognize this so they actually allow you to play the full game - as even documented on the Wiki - all "cracked" launchers need to do is omit this to allow any version to be played in non-demo mode).
As for the server itself, it is entirely free to download (as all the game files are, actually - just check out https://mcversions.net/, which directly links to the files on Mojang's servers) - and there is actually a setting which lets you disable online authentication - which is all a "cracked" server actually is, and is also clearly documented on the Wiki, and elsewhere (why Mojang hasn't removed such an easily exploited setting is beyond me, I've heard it is so server admins can get on in the event they can't normally login for some reason; as for pre-1.3 versions, they may just not care since they are so outdated they may as well be a stripped-down demo version, otherwise, they could just prevent you from changing versions if you have a demo account):
If one tries to play a demo version before 1.3 from the launcher using a non-premium account, they can play the full version. This is because 1.3 is the version that added the demo mode to Minecraft, so earlier versions do not have the code necessary to recognize that they are in the demo.
online-mode
Setting this variable to off purposely is called "cracking" a server, and servers that are present with online mode off are called "cracked" servers, allowing players with unlicensed copies of Minecraft to join.
Thus, obfuscation literally does nothing at all to secure the game against unlicensed usage. My main issue with it is that it makes (vanilla) crash reports impossible to understand unless you have access to deobfuscation mappings, or somebody else had figured out what the issue is, or the error message is clear enough; what does this even mean (division by zero - but where? What is "bit.b"?)
java.lang.ArithmeticException: / by zero
at blt.b(SourceFile:814)
at bao.ak(SourceFile:801)
at bao.f(SourceFile:728)
at net.minecraft.client.main.Main.main(SourceFile:148)
Otherwise, it hasn't bothered me since I simply stopped updating at 1.6.4, with everything after that basically a separate game (if you consider how I version my own mods, based on major updates to world generation, 1.0.0-1.6.4 would be "Minecraft 1.0", 1.7-1.17 is "Minecraft 2.0", and 1.18+ is "Minecraft 3.0"), so there is no issue with having to update mods, which also must be updated because of internal changes to the game's code; the main reason why so many mods stopped updating at or were slow to update past 1.7.10 is not because of obfuscation but because of major internal changes, same for 1.13.
Also, I don't think it is correct to call Minecraft an "indie" game anymore, it hasn't been developed by a single person for well over a decade (there is a subset of players who consider versions up to Beta 1.7.3, when Notch was still dominant, "golden age", with everything since then going in a completely different direction from its original vision). Others consider the Microsoft buyout to be the end of the indie era; by this measure 1.8 was the last "indie" version (though I'd put it at 1.7 at the latest due to major changes in how the game is coded since 1.8).
Your first point seems a bit all over and confuses me. It almost seems contradicting in some ways, so can I ask for some clarity?
You say Mojang is an indie company. I disagree with this. It's not quite indie anymore. Mojang and Riot are two examples that may have both been indie companies at the start of the 2010s, but not really anymore. In fact, one of the one things you state in the same point is the slow pace of content/change over time, and the company becoming larger, having been bought out by a parent company, and having its processes shift is a result of this growth. That's a separate subject on its own, but company size does not linearly equal rate of change potential.
Anyway, you state Mojang being a small company is why we should expect faster content changes. This can go the other way, too. While indie titles might be more likely to take risks (as opposed to big publishers who take the safer, more profit likely route, resulting in less originality), it's rare a fully polished idea comes out of an indie title that perfects an evolution of the formula. That's a very tall ask, and I think you're underestimating the accomplishment of Minecraft, anyway. Back then, something like that wasn't seen before, and the tech for it wasn't really there before (at least not in the way Minecraft did it). There's a reason a simple concept with a simple look came relatively late.
Remember; this just started as some project by one person. It just happened to blow up. You're putting a lot of expectations on what it should have been in my opinion.
Also, huge disagree on indie versus triple A. The indie scene is thriving and has been carrying PC gaming the last decade or so, and then some. Triple A gaming has become more hit or miss for me over time. It's okay in recent years but back before things like Steam really allowed for greater possibilities with indie developers, the gaming market was much more bland and limited in my opinion. I find most of the weight of the (in my opinion) current boon of PC gaming is being carried by the indie segment, and it's not even close.
I can't speak much to the modding/coding parts of point two.
As for three, I disagree. Version 1.19 is rather infamous for that (but it also gets dragged down by the chat thing), but that aside, I disagree. I'm not saying it never happened aside from then, just that I don't think it was at all a big issue besides that one point. And Mojang has expressed learning from it that time. Minecraft has a history roughly a dozen years in making. There's inevitably going to be some things hinted at that time that don't end up getting added. It's just inevitable.
For point four, huge disagree, and I said above since you mentioned this at the opening of your post (I'm replying as I read it). I don't play on the console side if that helps explain my stance, but on the PC side, indie gaming is thriving and in my opinion PC gaming is going through a sort of golden age as of late. Triple A games? Let's see, remakes, remakes, poor ports, same formula again and again, more poor ports that make Minecraft blush, not-technically-a-remake-but-still-the-same-formula, and... remakes, etc. And like you, I'm not "throwing shade" at all those things. I actually don't mind the recent "remake" boom. There's a certain era of gaming (namely PlayStation/PlayStation 2 era, so late 1990s and early 2000s) that stand to gain so much from remakes due to the fact that those games are in that era were a lot of them had low resolution, non-widescreen assets and aged poorly. Go newer and things go HD/widescreen, and super old pixel stuff didn't age quite as bad either. So there's justification to remakes. I loved the remake of Resident Evil 2 (and even to an extent, 3, even if it was underwhelming comparatively). Both are games I paid full price for up front and I don't do that for triple A games often these days. My biggest gaming wish right now is that Final Fantasy IX (totally not the best game ever or anything...) remake rumors come true. And there's been some original ideas on the triple A landscape too. But I can say this. Thank goodness the triple A landscape isn't the only thing we have. In fact, a big company bought up a smaller one here and you saw what happened. It just got monetized more and you can argue the originality slowed down even more. Big budgets can sometimes bring more possibilities, but I think you're dismissing potential of indie titles by outright stating triple A titles just do things better. They don't necessarily, and being beholden to big, publicly traded publishers/companies comes with its own set of drawbacks.
This just sounds like a "I'm disappointed with it, but can't move on, so I'd rather its development stopped". That's your opinion. There's plenty of people who AREN'T disappointed with modern versions. Version 1.18 (and to an extent, 1.16) reinvigorated my passion for this game. 1.13+ is just a different era, and a much better one in my own opinion. Not everyone thinks modern versions are perfect. FAR from it. But nor does everyone think it's a disappointment that needs to end. Again, FAR from it. But if you're disappointed with it, just acknowledge that and stay to versions you enjoy and/or move on from the game. It doesn't need to formally stop for that to happen. Other games are out there.
As for bonus point 6, that's good! Whenever something big comes (the original Doom I guess), all these clones rush to try their take on the idea. Minecraft, by no means, stands above everything else in the sandbox space in every single regard. Far from it. But I disagree that just because it's older or because other things do things better in some ways, that it should stop. The thing is, a continually developing game for this long is such a rare thing that it's hard to say WHAT Minecraft should be. It';s mostly games as a service (League of Legends) or MMOs (which are also games as a service) that get continual development for so long. But a single purchase game being updated, and constantly, for over a decade? It's a rarity. So there's not much established in that regard to compare to on what Miencraft SHOULD be. Some think it's changed too much, not too little.
As for people moving on, yeah? That happens. Things ebb and flow, peak and decline. That's everything. People were saying the same sorts of things back in the earlier 2010s about Minecraft. People wanting to move on from it is anecdotal, and the game needing to just pack up shop because some people feel that way isn't necessarily any more true now than it was back then.
Sorry if that seems a bit scattered, but I read it in chunks and then posted my thoughts, as I wanted to give input on what seemed like a constructive subject that had some time put into it. I don't agree with many of your points, but I don't necessarily think you're wrong either, and sort of get where you're coming from. But it sounds like you've just started moving on, but have been unable to do so. Your thoughts about the game being that it's declining is leading you to feel it should just stop and end on a higher note rather than a lower note, to make it easier for you to move on and live with things. I don't agree with it though. Plenty of people, myself included, still enjoy the modern game.
I think updates should stop until they fix the bad performance so many people are having on their PC's with this game
they don't seem to focus on optimizing the game and how it runs on different sets of hardware anymore, they just rush updates out in part due to impatience of other people who expect them to come out quicker, but I think this is wrong, I think it is far more important to give developers time to finish a product before they release it.
If they can't eliminate the performance issues on people's PC's that meet or exceed the recommended requirements, then they should hire some people who can, while I am not a programmer I do know there are other people in the Minecraft community who have created mods, people who have benchmarks to show what more could be done to make sure the game runs at playable frame rates regardless of what is going on in player worlds.
While it is a gamer's responsibility to ensure the normal operation of their device, they can't really do anything about software which isn't being efficient with the hardware they're running it on, except for to simply not use it. And all PC's no matter the hardware have limits, we can't just blame people's PC's every time they are complaining about an fps drop in a game, sometimes it isn't that simple as they could have high end machines and still be having the same problem. As Princes_Garnet has explained in a different thread, people have had these sorts of problems with Minecraft even on PC's with the fastest desktop CPU's in them, so it's clearly not anything to do with the hardware anymore, it's more the case Mojang just being inefficient with their software engineering or cutting out things which don't need to be running in the game at all times.
But if they don't optimize their game then it doesn't really help that we get more content added to the game,
it could potentially make things worse and until there is enough pressure from the fandom to encourage Mojang
to release updates that massively reduce lag spikes on even PC's with mid tier or hardware released in the last 5 years,
we'll continue to have the same conversation. It's just dumb, that we're having to explain this to developers when they are the ones
in charge and have the power/ability to address it.
Performance improvements don't garner attention like feature changes do, unfortunately. Look at 1.15; it's often ignored in the boon of praise 1.13+ gets simply because it "only added bees" or "didn't even fix all the issues the game has".
It can be unfortunate but its the way our world works. "Good enough" is, well... good enough.
It should also be pointed out that a lot of people are likely playing a game that is typically very CPU heavy on probably older, slow, often mobile (and low clock speed) CPUs/PCs. Often probably below minimum requirements. The minimum/recommended requirements call for a low end Ivy Bridge/mid range Haswell respectively on Intel's side, or pre-Ryzen stuff on AMD's side (and AMD was only offering slower stuff at this time). Such CPUs are pretty old now, and Windows 10 losing support in less than a few years will (at least officially) cut off anything before the 8th generation on Intel's side and the second Ryzen generation on AMD's side (and in three years, those will also be older and slower).
None of this is to say I wouldn't like to see performance be given more focus. It's one of THE things I'd like to see. But I'm just explaining why such an update focused only on that is unlikely to happen. It'd be nice if Minecraft was totally stutter free no matter the circumstances, and ran at 32 to 48 render distance on new stuff, and played smoothly on old Core 2s with only 4 GB or 8 GB of RAM, and so on. But I don't expect development to ever shift to focusing in that direction.
We should not overlook the changes that may happen along the way though, even if they aren't in a dedicated update just for that sort of thing. I've noticed many poor behaviors of older versions that get improved in later versions.
It's understandable that you have your own reasons for why you think Mojang should discontinue development on Minecraft. However, it's worth noting that other players might have different perspectives and preferences regarding the game. Some might enjoy the game as it is, while others may have specific feature requests or modding needs that keep them invested in Minecraft.
Furthermore, it's worth noting that the game industry is vast and diverse, with both indie and AAA studios producing a wide range of games catering to different audiences. What might work for one player or studio may not work for others, and vice versa. It's not necessarily a matter of which type of studio is "superior" but rather which type of game or studio suits a particular player's needs and preferences.
Lastly, it's up to Mojang and the Minecraft community to decide if and when they want to discontinue development on the game. While it's understandable that some players might feel disappointed with certain aspects of the game, it's important to remember that the game is constantly evolving and changing, and it's up to the developers to decide the best course of action for the game's future.
[Best Regards]
Olivia devid
This is one heck of a good first post, and I agree with it entirely. It summarizes things very well.
None of this is to say the opinion of the topic starter is wrong. Everyone has opinions and they are just that, after all.
But I got the impression reading it that someone is "over" what Minecraft currently is, is realizing it is unlikely to change enough to become what they think it should be, and wanting to see development stop to help them move on.
And that part I disagree with. If that's the case, just move on. The game doesn't need to cease changing for one to move on. The gaming landscape is very wide (and in my opinion, wider and even richer than it's ever been), so if one is "over" a given game, there's countless others out there likely to suffice better.
Performance improvements don't garner attention like feature changes do, unfortunately. Look at 1.15; it's often ignored in the boon of praise 1.13+ gets simply because it "only added bees" or "didn't even fix all the issues the game has".
It can be unfortunate but its the way our world works. "Good enough" is, well... good enough.
It should also be pointed out that a lot of people are likely playing a game that is typically very CPU heavy on probably older, slow, often mobile (and low clock speed) CPUs/PCs. Often probably below minimum requirements. The minimum/recommended requirements call for a low end Ivy Bridge/mid range Haswell respectively on Intel's side, or pre-Ryzen stuff on AMD's side (and AMD was only offering slower stuff at this time). Such CPUs are pretty old now, and Windows 10 losing support in less than a few years will (at least officially) cut off anything before the 8th generation on Intel's side and the second Ryzen generation on AMD's side (and in three years, those will also be older and slower).
None of this is to say I wouldn't like to see performance be given more focus. It's one of THE things I'd like to see. But I'm just explaining why such an update focused only on that is unlikely to happen. It'd be nice if Minecraft was totally stutter free no matter the circumstances, and ran at 32 to 48 render distance on new stuff, and played smoothly on old Core 2s with only 4 GB or 8 GB of RAM, and so on. But I don't expect development to ever shift to focusing in that direction.
We should not overlook the changes that may happen along the way though, even if they aren't in a dedicated update just for that sort of thing. I've noticed many poor behaviors of older versions that get improved in later versions.
This is one heck of a good first post, and I agree with it entirely. It summarizes things very well.
None of this is to say the opinion of the topic starter is wrong. Everyone has opinions and they are just that, after all.
But I got the impression reading it that someone is "over" what Minecraft currently is, is realizing it is unlikely to change enough to become what they think it should be, and wanting to see development stop to help them move on.
And that part I disagree with. If that's the case, just move on. The game doesn't need to cease changing for one to move on. The gaming landscape is very wide (and in my opinion, wider and even richer than it's ever been), so if one is "over" a given game, there's countless others out there likely to suffice better.
I do see your point however nobody who understands the basics of the tech world, and you know this too, really expects an Intel Core 2 Duo system to run newer versions of Minecraft well. Minecraft used to run at playable frame rates on PC's with dual core CPU's and 4gb of RAM, but as far as we can tell the game does use multi threading for chunk loading operations or when the game is loading. Even after chunk loading has finished I would not recommend anything less than a quad core CPU for the game and even then those cores need to be powerful, not all quad cores are made equal, they all have different architectures as well as clock speeds, as well as l3 cache sizes. We also need to consider that background applications use CPU threads/cores as well, not just the game itself and a quad core CPU can help prevent those background apps from interfering with the app you're using.
But any new PC that is greatly exceeding the recommended requirements by Microsoft, not only meeting them, for this game shouldn't be lagging at all with a 32 chunks render distance, first problem is these PC builds are not cheap and are most definitely not budget builds.
The second is 32 chunks render distance isn't anything special anymore like it used to be, about 5 years ago or more we could've made that argument with a straight face, but not today and there are gameplay benefits to increased render distance, for a start you can see further out into the End dimension, important for seeing outer islands that have End cities and to help players reduce their risk of dying in the void.
16 or less chunks render distance just sucks for anyone, I'd only suggest doing it as a last resort.
But it is not good indication of a PC handling Minecraft, the only reason tablet or console devices like the Nintendo Switch
would be limited to this is because it is what we would expect from a mobile device.
I do see your point however nobody who understands the basics of the tech world, and you know this too, really expects an Intel Core 2 Duo system to run newer versions of Minecraft well.
Oh, the Core 2 example was kind of pulled from the air because the game used to run well on them, so I figured it might be a good baseline example for what people might point to and say should be possible. Of course I don't expect them to remain relevant forever, though. I know stuff moves on.
That being said, while it's being mentioned...
I found the game "sort of" runs on them, but of course has heavy difficulty when dealing with terrain loading/rendering.
I changed the CPU to a Core 2 Quad Q9550 and it actually make very little difference. Which surprised me because the dual core was maxing out on both cores (and any music running in an external application was pausing on and off constantly when loading terrain) so I was expecting a bit more of an improvement.
But those Core 2 Quads weren't monolithic quad cores. They were just a pair of Core 2 Duos on one CPU communicating over the FSB, which probably slows them down heavily here.
Either way, they were practically too slow for the game even then, and I would especially even more so now for 1.18 and above.
The second is 32 chunks render distance isn't anything special anymore like it used to be, about 5 years ago or more we could've made that argument with a straight face, but not today and there are gameplay benefits to increased render distance, for a start you can see further out into the End dimension, important for seeing outer islands that have End cities and to help players reduce their risk of dying in the void.
It's only not special for Bedrock. It's been difficult on Java, for the most part, from the conception of the game until now.
I used to run on a render distance of up to 32 many years ago, starting with version 1.7 or so, and until 1.10. Frame rates were down at times, but I chose to play that way.
Ironically, I had the best performance I ever had on higher render distances with version 1.16, which a child of the 1.8+ coding practices.
Not necessarily great performance. Probably not all around playable. But that's a render distance of 64, above what the game natively supports in Java. So a render distance of 32, or even then some, was largely playable if I wanted it.
But I didn't care about it anymore. If you had asked me 5+ years ago, I'd say I didn't want less than 32 render distance, and 24 minimum. But when I updated and started a new world in a current (at the time, 1.16) version, I choose a render distance of around 20, later 16 (those bushy leaves did it, and I need them!), instead now because of shaders (and performance). A very high render distance gives you a little more view on a narrow strip of the horizon most of the time. And I felt beautifying the overall image mattered more than that. Granted, I'd love at least 20 or 24 over 16, and I'd possibly even take 32 at times (when flying or up in the mountains, the high distance is more noticed). But beyond that, I think it actually starts to look silly. I'd only play above 32 if I was also playing with large biomes. Seeing across up to half a dozen biomes impacts the immersion of the world to me, and I'd never like it.
And you can go into the end and turn the render distance up easily on Java to find end cities. It's nowhere near as demanding as the other two dimensions.
Anyway, yeah, I'd absolutely love a performance update. But given how Bedrock and Java are different games underneath, and how 1.15 was seemingly not as appreciated, I'm not sure if we'll see that again. Players are more receptive to features so I guess that's what new updates will focus on (and hopefully updates come, because I don't agree they should stop). I'd be fine if they keep improving things as they go in the background to be honest. Remember when the lighting would just mess up? Or was that not a thing in Bedrock? But that's just not a thing in Java anymore, and thank goodness. Improvements as they go is fine by me too. Doesn't need to be a whole update.
Oh, the Core 2 example was kind of pulled from the air because the game used to run well on them, so I figured it might be a good baseline example for what people might point to and say should be possible. Of course I don't expect them to remain relevant forever, though. I know stuff moves on.
That being said, while it's being mentioned...
I found the game "sort of" runs on them, but of course has heavy difficulty when dealing with terrain loading/rendering.
I changed the CPU to a Core 2 Quad Q9550 and it actually make very little difference. Which surprised me because the dual core was maxing out on both cores (and any music running in an external application was pausing on and off constantly when loading terrain) so I was expecting a bit more of an improvement.
But those Core 2 Quads weren't monolithic quad cores. They were just a pair of Core 2 Duos on one CPU communicating over the FSB, which probably slows them down heavily here.
Either way, they were practically too slow for the game even then, and I would especially even more so now for 1.18 and above.
It's only not special for Bedrock. It's been difficult on Java, for the most part, from the conception of the game until now.
I used to run on a render distance of up to 32 many years ago, starting with version 1.7 or so, and until 1.10. Frame rates were down at times, but I chose to play that way.
Ironically, I had the best performance I ever had on higher render distances with version 1.16, which a child of the 1.8+ coding practices.
Not necessarily great performance. Probably not all around playable. But that's a render distance of 64, above what the game natively supports in Java. So a render distance of 32, or even then some, was largely playable if I wanted it.
But I didn't care about it anymore. If you had asked me 5+ years ago, I'd say I didn't want less than 32 render distance, and 24 minimum. But when I updated and started a new world in a current (at the time, 1.16) version, I choose a render distance of around 20, later 16 (those bushy leaves did it, and I need them!), instead now because of shaders (and performance). A very high render distance gives you a little more view on a narrow strip of the horizon most of the time. And I felt beautifying the overall image mattered more than that. Granted, I'd love at least 20 or 24 over 16, and I'd possibly even take 32 at times (when flying or up in the mountains, the high distance is more noticed). But beyond that, I think it actually starts to look silly. I'd only play above 32 if I was also playing with large biomes. Seeing across up to half a dozen biomes impacts the immersion of the world to me, and I'd never like it.
And you can go into the end and turn the render distance up easily on Java to find end cities. It's nowhere near as demanding as the other two dimensions.
Anyway, yeah, I'd absolutely love a performance update. But given how Bedrock and Java are different games underneath, and how 1.15 was seemingly not as appreciated, I'm not sure if we'll see that again. Players are more receptive to features so I guess that's what new updates will focus on (and hopefully updates come, because I don't agree they should stop). I'd be fine if they keep improving things as they go in the background to be honest. Remember when the lighting would just mess up? Or was that not a thing in Bedrock? But that's just not a thing in Java anymore, and thank goodness. Improvements as they go is fine by me too. Doesn't need to be a whole update.
I like high render distances for the reasons you would, it allows us to more easily spot what biomes are ahead of us, in the Overworld it has been a big advantage for me and other people who play on my home survival server.
32 chunks render distance is the equivalent of 1024 blocks squared or 512 from center in every direction, it is a lot of blocks the game has to load into memory, but we need to remember tick or simulation distance is a different setting/feature entirely and rendered blocks themselves only affect what can be seen by the player. But these blocks will not update a redstone tick unless a player is close enough to them.
I do wish minecarts were able to circumvent the tick radius or at least for Mojang to give us a variant of a minecart that would keep 1 chunk loaded as this would allow players to send items to each other across long distances using a minecart train or shulker in chest system.
With a performance update having a feature like that may someday become practical, I've suspected the (ironic) reason they haven't added this feature with minecarts is not to do with balance or worry that it would be abused by auto grinders, (which unfortunately also exists for shulker farms, and in my opinion, this should be replaced by continuously spawning shulkers in End cities to compensate for already looted End city structures for other players on a server, even if all of the shulkers had already been killed by previous players, a much better way of making shulker shells and boxes renewable), it is more the case of it causing lag on servers.
I do see your point however nobody who understands the basics of the tech world, and you know this too, really expects an Intel Core 2 Duo system to run newer versions of Minecraft well
Not me; as a very knowledgeable modder I know exactly how much of an impact adding new content should of had, based on the fact that I've observed virtually no impacts for at least a thousand new features (over 350 blocks and items, 100 biomes, 45 new mobs/entity and/or variants of these, dozens of new world generation including dozens of new types of caves, trees, structures, etc).
Vanilla 1.6.4 at maximum settings (note that the render distance is actually only 10 chunks because the internal server only loads that many, no matter what the render distance is):
TMCWv5 at maximum settings (16 chunk render distance, which loads about 2.5 times as many chunks, 1089 vs 441; I set the view so the same number of chunks are being rendered, 842, though this isn't the only factor affecting FPS):
The only thing that really impacts resource usage is the number of blocks and entities loaded, and that explains nearly everything the game needs because there are just so many - something like 22 million at 16 chunks (and actually twice that number because the client and server has two copies of the world loaded, even in singleplayer), which requires about 106 MB of memory (for both sides). Here is a comparison of VisualVM profiler results for 1.6.4 and TMCWv5 (again, note the differences in loaded chunks):
Vanilla 1.6.4; both of these ran for about 5 minutes:
TMCWv5; note that I increased the render distance from 8 to 16 near the start, which caused CPU usage to spike to about 40%; afterwards it drops much faster than in vanilla, which was still doing a lot of chunk updates for quite some time after, while it drops much faster in TMCW, and despite loading over twice as many chunks there were fewer garbage collection cycles, indicating that TMCW is allocating memory at a lower rate - and also using less CPU despite again, loading way more data - that's the power of optimization, and 1.6.4 is very lightweight compared to modern versions:
In fact, these were the system requirements as of 1.6 - which can be expected to still apply to TMCW, even as it has many major updates worth of new content:
Last Updated: Jul 06, 2013 11:47PM CEST
Minimum Requirements:
CPU : Intel P4/NetBurst Architecture or its AMD Equivalent (AMD K7)
RAM : 2GB
GPU : Intel GMA 950 or AMD Equivalent with OpenGL 1.2 Support
HDD : At least 90MB for Game Core and Sound Files
Java Runtime Environment (JRE) 6 or up is required to be able to run the game.
Recommended Requirements:
CPU : Intel Pentium D or AMD Athlon 64 (K8) 2.6 GHz
RAM : 4GB
GPU : GeForce 6xxx or ATI Radeon 9xxx and up with OpenGL 2 Support (Excluding Integrated Chipsets)
HDD : 150MB
The brand's first processor, codenamed Smithfield and manufactured on the 90 nm process, was released on May 25, 2005, followed by the 65 nm Presler nine months later.
Launched on April 14, 2004, the GeForce 6 family introduced PureVideo post-processing for video, SLI technology, and Shader Model 3.0 support (compliant with Microsoft DirectX 9.0c specification and OpenGL 2.0).
How does load time and world creation compare? 1.6.4 should be way faster as its world generation is comparatively so simple and it has a lot less things to load, right?
Vanilla 1.6.4:
[19:11:13] 2023-04-15 19:11:13 [CLIENT] [INFO] Setting user: TheMasterCaver
[19:11:13] 2023-04-15 19:11:13 [CLIENT] [INFO] (Session ID is null)
[19:11:13] 2023-04-15 19:11:13 [CLIENT] [INFO] LWJGL Version: 2.9.0
[19:11:14] 2023-04-15 19:11:14 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
[19:11:14]
[19:11:14] Starting up SoundSystem...
[19:11:14] Initializing LWJGL OpenAL
[19:11:14] (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
[19:11:14] OpenAL initialized.
[19:11:15]
[19:11:15] 2023-04-15 19:11:15 [CLIENT] [SEVERE] Realms: Server not available!
[19:11:48] 2023-04-15 19:11:48 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
[19:11:48] 2023-04-15 19:11:48 [SERVER] [INFO] Generating keypair
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Converting map!
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Scanning folders...
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Total conversion count is 0
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Preparing start region for level 0
[19:11:50] 2023-04-15 19:11:50 [SERVER] [INFO] Preparing spawn area: 12%
[19:11:51] 2023-04-15 19:11:51 [SERVER] [INFO] Preparing spawn area: 36%
[19:11:52] 2023-04-15 19:11:52 [SERVER] [INFO] Preparing spawn area: 60%
[19:11:53] 2023-04-15 19:11:53 [SERVER] [INFO] Preparing spawn area: 86%
[19:11:54] 2023-04-15 19:11:54 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 266 at (-94.5, 64.0, 244.5)
[19:11:54] 2023-04-15 19:11:54 [SERVER] [INFO] TheMasterCaver joined the game
TMCWv5:
[18:21:25] 2023-04-15 18:21:25 [CLIENT] [INFO] Setting user: TheMasterCaver
[18:21:25] 2023-04-15 18:21:25 [CLIENT] [INFO] (Session ID is null)
[18:21:26] 2023-04-15 18:21:26 [CLIENT] [INFO] LWJGL Version: 2.9.0
[18:21:26] 2023-04-15 18:21:26 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
[18:21:27]
[18:21:27] Starting up SoundSystem...
[18:21:27] Initializing LWJGL OpenAL
[18:21:27] (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
[18:21:27] OpenAL initialized.
[18:21:27]
[18:22:04] 2023-04-15 18:22:04 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
[18:22:04] 2023-04-15 18:22:04 [SERVER] [INFO] Generating keypair
[18:22:04] 2023-04-15 18:22:04 [SERVER] [INFO] Preparing start region for level 0
[18:22:05] 2023-04-15 18:22:05 [SERVER] [INFO] Preparing spawn area: 19%
[18:22:06] 2023-04-15 18:22:06 [SERVER] [INFO] Preparing spawn area: 58%
[18:22:07] 2023-04-15 18:22:07 [SERVER] [INFO] Preparing spawn area: 99%
[18:22:07] 2023-04-15 18:22:07 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 137 at (-245.5, 70.0, -253.5)
[18:22:07] 2023-04-15 18:22:07 [SERVER] [INFO] TheMasterCaver joined the game
Yet somehow(!) TMCW took only half as much time to generate a new world, despite being vastly more complex - again, the power of optimization. 1.13 is absolutely terrifying by comparison, considering it has multithreaded chunk generation, yet took far longer than vanilla 1.6.4:
The only place where TMCW is noticeably heavier is in the save size, which is because of the greatly increased complexity of the world, as indicated by the MCEdit analyses following (both areas are the same size):
The left column is from a world created in 1.6.4; in both cases these represent fully explored regions (lighting up caves increases the complexity of data due to the block light map, more than offsetting any reduction from the relatively small amount of ores mined out):
1.6.4; 138 blocks / block variants and 347 entities:
TMCWv5; 283 blocks / block variants and 351 entities; there are also about twice as many chests and mob spawners, mainly due to random variation; note that despite terrain being higher on average there are more air blocks than the vanilla world had (there are only about half as many lava blocks due to the fact that the cave lava layer is only 3 layers deep, also possibly variation as these areas were only 368x368 blocks):
Fact is, it completely blows my mind how resource intensive modern versions are, even more so traditional modded versions - absolutely insane; just WHAT is using all of that?! No, I'm NOT going to install a modpack, or even a modern version, just so I can analyze its resource usage:
Saying "only" as if 6-8 GB is nothing when I had only 512 MB allocated in the examples above, and this thread claims that even modded 1.3 requires at least that much just to get started, much less load a world at a higher view distance than supported by the game unless you use Optifine (again, 10 chunks loads 441 chunks while 16 chunks loads 1089 chunks; 1089 / 441):
1.3 split the server and the client logic. Suddenly, you have to double the footprint of the game - one copy of all the game objects for the server, one copy for the client. 1.3 needs 500MB before you're even running.
Here are more VisualVM analyses, this time comparing the top objects by memory usage ("retained size", which includes all memory referenced by any objects they hold; the sum of the column is not the total, which can be derived from the percentage used by the top entry):
1.6.4; total memory usage was about 111.3 MB, with 61.5 MB (55.3%) used by loaded chunks and 49.8 MB used by everything else (note that there are actually 1066 chunks loaded, not 882 or 441 x 2, since the spawn chunks are 625 chunks, but only server-side; the number would be even higher if I was outside the spawn area):
TMCWv5; total memory usage was about 164.4 MB, with 137.6 MB (83.7%) used by loaded chunks and 26.8 MB used by everything else (in this case the same number of chunks, 1089, or 2178 total, are loaded on both sides as there are no spawn chunks loaded, except during initial world creation, so it also doesn't matter where I am in the world):
Yes, you read that right - when excluding loaded chunks TMCW uses only about half as much memory! This is clearly visible in some of the classes; RenderGlobal is 2.84 MB in vanilla but TMCW's RenderGlobalTMCW class is only 2.18 MB, and it combines two major rendering classes (RenderGlobal and EntityRenderer). Likewise, vanilla's WorldRenderer takes up 2.56 MB while TMCW's ChunkRenderer only takes up 1.76 MB - and there are 1.61 times more instances due to the higher render distance (in other words, each one less than half as much memory, 106 vs 248 bytes)! This in part because I removed several objects in favor of simpler fields, which also means there are tens of thousands less objects than there would otherwise be (this is why the "size" is the same as "retained", while in vanilla the latter is much larger. Even if you just compare the "size" vanilla still needs 126 bytes per instance). The same goes for many other classes, which all add up to a 50% reduction in baseline memory usage - if I had set TMCW to 10 chunks instead, to load the same number as vanilla, it would be using less memory overall, and even less CPU (which was already lower).
Sure, there are still cases where something can use a lot of memory, for example, look at how much memory is used by mineshafts, and there were only 10 loaded - but at least I don't load or save the data for every single mineshaft in the entire world, like vanilla does, and they are only created if a chunk is being populated with part of them (if I reloaded the world and took another heap dump it would show 0 instances, so only the amount of new terrain generated in a given session matters, plus vanilla's "MapGenStructureData" class stores its own data separately from the "MapGenMineshaft" class, which is already using 1/6 as much memory despite only a single village, which still uses it, being present):
Whether you could say I truly fixed this or not, it will never become such an issue unless you did something unrealistic like continuously flying for days on end, or kept the game running with a world loaded when you weren't playing. In order for mineshaft data to use an amount of memory comparable to loaded chunks you'd have to load on the order of 10,000 of them, or 1.8 million chunks (due to vanilla's inefficient saved structure data format it can only handle a small fraction of this; comments suggest that only about 600 mineshafts, or 60,000 chunks in vanilla, use the same amount of memory - so I can claim to have optimized them by a factor of 30. This also means that my first world, about 135,000 chunks, would use several times more memory if I hadn't disabled structure saving for mineshafts - as it is, it uses no more than a brand-0new world).
Likewise, I'm sure there are ways to greatly optimize the rendering of chests but at least I doubled their performance with some relatively minor changes, and at least there are barrels, which have no more impact than rendering a block like stone does, plus I still get enough FPS to remain stable with a framerate limit / Vsync (which is probably what most developers are happy with, ignoring the fact that they might have an above-average computer - I even still code parts of TMCW as if I still had a 32 bit system, as I did for the first few years I played):
Note that the memory usage shown by VisualVM does not include the code itself (or VRAM usage) but this is self-explanatory (the size of TMCWv5 has increased a bit since a year ago but it is still less than 7 MB - I even added new features from updates as recent as 1.19, including before its official release, like a Swift Sneak enchantment (which only required a few lines of code - once you have the base code for a general type of feature (entities, blocks, items, enchantments, biomes, etc) each new instance needs a lot less to be added*). My modded jars also include a lot of unused vanilla classes since I renamed many of them instead of just modifying the originals, while deleting META-INF reduced the size, either way, even just 1.8, the first update where Mojang adopted their current programming practices, at least on a large scale, is larger despite having only a small fraction of the content (my own code also has far fewer classes, about 1/3 as many when compared to the same overall source size of vanilla 1.6.4; conversely, 1.8 has far more small classes and is far more complex internally as a result):
*This is all the code involved with my "Swift Sneak" enchantment, excluding unrelated parts of existing classes that were modified to include the code for it (only "EnchantmentSwiftSneak" is entirely new):
public class EnchantmentSwiftSneak extends Enchantment
{
public EnchantmentSwiftSneak(int par1, int par2)
{
super(par1, par2, EnumEnchantmentType.armor_legs);
this.setName("swiftSneak");
}
// Returns cost per level in the anvil; level 3 costs 9 levels
public int getAnvilCost()
{
return 3;
}
// Set so only levels 1-2 are likely to be obtained from the enchantment table
public int getMinEnchantability(int par1)
{
return 10 + 20 * (par1 - 1);
}
public int getMaxEnchantability(int par1)
{
return super.getMinEnchantability(par1) + 50;
}
public int getMaxLevel()
{
return 3;
}
// Reduces chance of being chosen in an enchantment table by an additional 75% (effective weight is 0.25)
public float getAdditionalRarity()
{
return 0.25F;
}
}
public abstract class Enchantment
{
public static final Enchantment swiftSneak = new EnchantmentSwiftSneak(28, 1);
static
{
// Initializes list of enchantments used by villager trading and fishing
ArrayList<Enchantment> tradeList = new ArrayList<Enchantment>();
for (int i = 0; i < 2; ++i)
{
for (int e = 0; e <= MAX_ID; ++e)
{
Enchantment ench = enchantmentsList[e];
// Does not include Smelting and Vein Miner and only adds Long Fall and Swift Sneak once so they are half
// as likely to be chosen
if (ench != smelting && ench != veinMiner)
{
if (i == 0 || (ench != longFall && ench != swiftSneak)) tradeList.add(ench);
}
}
}
enchantmentsBookList = (Enchantment[])tradeList.toArray(new Enchantment[0]);
}
}
public class CustomEnchantmentHelper
{
// Adds information on armor and Protection enchantment values
private static final void addArmorTooltips(ItemStack itemStack, ItemArmor item, ArrayList list)
{
level = getEnchantmentLevel(Enchantment.swiftSneak, itemStack);
if (level > 0) list.add(EnumChatFormatting.BLUE + "+" + Integer.toString(level * 15) + "% sneak speed");
}
public static final int getSwiftSneakModifier(EntityLivingBase par0EntityLivingBase)
{
return getMaxEnchantmentLevel(Enchantment.swiftSneak, par0EntityLivingBase.getLastActiveItems());
}
// Returns an enchanted book with Long Fall or Swift Sneak. Level distribution is set so there is 40% chance of
// the max level; for Long Fall levels 1-4 have a 11/19/29/40 chance while for Swift Sneak levels 1-3 have a
// 26/33/40 chance.
public static final ItemStack getRandomRareBook(Random64 par1Random)
{
Enchantment enchant = (par1Random.nextBoolean() ? Enchantment.longFall : Enchantment.swiftSneak);
int value = (enchant.getMaxLevel() == 4 ? 5 : 16);
int level;
do
{
level = enchant.getMaxLevel() - par1Random.nextInt(par1Random.nextInt(value) + par1Random.nextInt(2) + 1);
}
while (level <= 0);
return makeEnchantedBook(enchant, level);
}
}
public class MovementInputFix extends MovementInput
{
public void updatePlayerMoveState()
{
if (this.sneak)
{
// Swift Sneak increases movement speed while sneaking by 15% per level (30%, 45%, 60%, 75% for levels 0-3)
float factor = (float)CustomEnchantmentHelper.getSwiftSneakModifier(this.thePlayer) * 0.15F + 0.3F;
if (factor < 1.0F)
{
this.moveStrafe *= factor;
this.moveForward *= factor;
}
}
}
}
Yes, I like higher render distances too... to a point. Above around 32 chunks and I feel like I'd want to play on large biomes to counteract seeing so many biome transitions in view. Yet the climate zones of versions from 1.7 and on would make playing on large biomes painful. So even if performance wasn't an issue, I probably wouldn't want to play above 32 render distance.
But obviously, the game could stand to do with performance improvements. Being able to play at higher distances is a very nice benefit of Bedrock. And both versions probably have performance areas they could have improved.
Going to spoiler the rest since it's more specific to this subject of performance that came up rather than the topic of the thread. (Speaking of which, I'm surprised the thread starter hasn't returned and replied yet, so I'm hoping they don't feel chased off?)
So this whole discussion got me thinking... I decided to try and reenact my above pictures, from around the same spot, in 1.18 and above. Here's what I got...
What!?
Disclaimer that's it not practical to play like this. Frame rate drops to around 30 when flying around and loading in many chunks, or in some instances, a stutter when moving the camera. I was also surprised to see GPU use as high as it was, and VRAM was at 5 GB or more.
But even though it had "settled" in these pictures, I was still shocked at the numbers. I have never seen them even settle so close to 60 FPS before. I was expecting FAR lower given what I was getting in 1.16, which I considered the best I've seen for performance at high render distances in Java. I was expecting 1.18 had dragged performance far down.
Granted, I've had a CPU upgrade in that time... but I don't think that entirely explains this. I think I was overestimating how much performance had dropped with 1.18. Because even on the Bedrock side, I have seen many complaints of it (special mention to those dealing with it on the Switch).
This got me wondering... what is a render distance of 32 like in modern versions? Would it be remotely playable on decent modern hardware? (Might need to wait for it to process in HD if it's blurry.)
I'm speechless. Absolutely speechless. It's entirely playable. Not quite the way I'd want (I'd want to put some resource packs and antialiasing on, which might bring it down from that constant 60 FPS), but it's more than playable for sure. Even near all the cows! I've become so used to playing with shaders, and even though I knew they were seriously performance demanding and that I was limited by my graphics card, I still did not expect it to be this "high" in "vanilla". It makes me wonder if the Sodium trio would improve on this even more. This was with OptiFine.
I dare say, albeit slightly, this changes/improves my opinion on Java's performance quite a bit.
I know a lot of people are dealing with worse, due to having slower systems, but I thought it was MUCH worse than this on even newer hardware ever since 1.18 at least.
Of course, modded/shaders still remain a different scenario altogether.
So I guess you were ironically right? A render distance of 32 isn't necessarily so special anymore?
But yeah, out of curiosity, I am wondering if the thread starter has more to add, or to comment on some things said in response to their points. It's all opinions anyway, but I'm interested in what they would have to say. Like it seems like they are "over the game" and wants to see it stop development because they aren't happy with it. If that is the case, I'm wondering why they feel it should stop updating at 1.20 specifically, and why they don't just move on to other games if they feel other games are more to their liking?
Yes, I like higher render distances too... to a point. Above around 32 chunks and I feel like I'd want to play on large biomes to counteract seeing so many biome transitions in view. Yet the climate zones of versions from 1.7 and on would make playing on large biomes painful. So even if performance wasn't an issue, I probably wouldn't want to play above 32 render distance.
But obviously, the game could stand to do with performance improvements. Being able to play at higher distances is a very nice benefit of Bedrock. And both versions probably have performance areas they could have improved.
Going to spoiler the rest since it's more specific to this subject of performance that came up rather than the topic of the thread. (Speaking of which, I'm surprised the thread starter hasn't returned and replied yet, so I'm hoping they don't feel chased off?)
So this whole discussion got me thinking... I decided to try and reenact my above pictures, from around the same spot, in 1.18 and above. Here's what I got...
What!?
Disclaimer that's it not practical to play like this. Frame rate drops to around 30 when flying around and loading in many chunks, or in some instances, a stutter when moving the camera. I was also surprised to see GPU use as high as it was, and VRAM was at 5 GB or more.
But even though it had "settled" in these pictures, I was still shocked at the numbers. I have never seen them even settle so close to 60 FPS before. I was expecting FAR lower given what I was getting in 1.16, which I considered the best I've seen for performance at high render distances in Java. I was expecting 1.18 had dragged performance far down.
Granted, I've had a CPU upgrade in that time... but I don't think that entirely explains this. I think I was overestimating how much performance had dropped with 1.18. Because even on the Bedrock side, I have seen many complaints of it (special mention to those dealing with it on the Switch).
This got me wondering... what is a render distance of 32 like in modern versions? Would it be remotely playable on decent modern hardware? (Might need to wait for it to process in HD if it's blurry.)
I'm speechless. Absolutely speechless. It's entirely playable. Not quite the way I'd want (I'd want to put some resource packs and antialiasing on, which might bring it down from that constant 60 FPS), but it's more than playable for sure. Even near all the cows! I've become so used to playing with shaders, and even though I knew they were seriously performance demanding and that I was limited by my graphics card, I still did not expect it to be this "high" in "vanilla". It makes me wonder if the Sodium trio would improve on this even more. This was with OptiFine.
I dare say, albeit slightly, this changes/improves my opinion on Java's performance quite a bit.
I know a lot of people are dealing with worse, due to having slower systems, but I thought it was MUCH worse than this on even newer hardware ever since 1.18 at least.
Of course, modded/shaders still remain a different scenario altogether.
So I guess you were ironically right? A render distance of 32 isn't necessarily so special anymore?
But yeah, out of curiosity, I am wondering if the thread starter has more to add, or to comment on some things said in response to their points. It's all opinions anyway, but I'm interested in what they would have to say. Like it seems like they are "over the game" and wants to see it stop development because they aren't happy with it. If that is the case, I'm wondering why they feel it should stop updating at 1.20 specifically, and why they don't just move on to other games if they feel other games are more to their liking?
You're right MC 1.20 isn't about this however my point is that I think unless they fix the performance issues with the game I would not be comfortable with them to keep adding more content to the game which depending on how much more is being loaded it would cause Minecraft to become even more bloated than it already is. If my PC could do it without any lag spikes whatsoever I'd go for a 64 chunks render distance then terminate the increase there as I'd be satisfied with it, and as you said we could use large biomes to negate the transitioning of biomes coming into view too often. It's nice to see what the next biome is ahead of you in each direction, but one thing which would be offputting is if say you saw an ice spikes biome close by an arid desert, which would feel out of place and that is the sort of thing we would wish to prevent.
I'm sure some people would want a 128+ chunks rendering distance if they could use it during normal gameplay, the thing is there comes a point where there are diminishing returns for this, and the further out the world generates the smaller the distant features would appear to the naked eye, which would eventually make it too difficult to see what biomes were there or even if you could see them, they would appear very small and thin from one biome transition to the next. I do wish we could mask the edge of the rendered chunks with fog in the Overworld though, with the game prioritizing frames per second over chunk updates.
This isn't what is going to happen in the future of the game's development sadly, there will be more updates well beyond 1.20.
And from what I can tell 1.20 isn't doing squat to improve the game, we've got a template coming which we will need to upgrade to Netherite gear, more work for the same items and not in a good way either. Isn't it penalizing enough that netherite gear is non renewable and rare? apparently Mojang didn't think so, but the devil is in the details, we get updates imposed on us for better or for worse and unless we play Java edition, we do not have a choice in which version of the game we are playing in either single or multiplayer.
I still don't know why choosing your own version in Bedrock isn't a thing. Or pausing the game. My only guess is its because they want their cross platform play to just always work between anyone regardless.
I still don't know why choosing your own version in Bedrock isn't a thing. Or pausing the game. My only guess is its because they want their cross platform play to just always work between anyone regardless.
I agree. Pausing in single player should be doable, and if the player is the only person on the server at that point in time then that should also be able to be paused, the pause being cancelled out if somebody else joins, but I guess a feature like that is simply too much work for them and since it's a minor inconvenience it would be better to fix other issues first.
Although I have expressed grievances about nerfs in the game, there are some nerfs I agree with, so did my friend lizking10152011, for example Notch Apples were overpowered in the past, egregiously so that they were effectively a cheap way to get a demigod mode for a player, to counter this, the enchanted golden apple is no longer craftable, and can only be legitimately obtained in naturally generated chests found in certain locations.
I also agree that beds are far too OP for the items needed to craft them, bed mining is the best example of this one, as they have an explosive force that far exceeds TNT in addition to be crafted cheaply using only wool and wood on a crafting table. Wool can either be obtained by crafting it with string from Spiders or from Sheep, sheared or killed. I've held this opinion about beds for a long time also.
One way to balance it would be to make wool be only obtainable using shears on Sheep, and remove naturally generated beds from Villages.
Another, remove their ability to explode in both the Nether and End, beds are not supposed to be used as weapons, they are merely tools to allow players to set their spawn and reset night time back to day time if used in Overworld.
Furthermore, beds have an exploit which can be heavily abused and that is players can leave a server to allow another to sleep, and then rejoin the server while it being daytime. This I feel is wrong, as players are not encouraged to all bring beds with them on their travels in the Overworld, they can get lazy about it and simply not bring a bed with them to save inventory space and then rely on a team member to do the work of time skipping.
Under the new system, beds could be rebalanced to punish players for doing this, but only if it is night time, if a player leaves when it is night time,
they could be expected to wait about 2 to 5 minutes before rejoining, so that they have less time of the day when they rejoin. If players need to leave to have a break they still are given time to do that and the cooldown would likely expire at the point of their return, so they are not punished for this.
I'm okay with nerfs if it is something that involves making something function as originally intended and if it does something which improves the game for people, although even that can be hard to pin down because we don't really know what devs were thinking at the time they made things the way they did.
But sometimes I think nerfs are done just because a minority complained about something they didn't like, or because a developer felt like adding in something random and nobody asked for, just to inconvenience other's, the armour templates in 1.20 being an example of this. Why should players be expected to collect templates, which are not even guaranteed to be in newly generated Bastions, it's chance based, just to craft netherite gear? this change made no sense whatsoever, it's more work put in just to make the same item and it does nothing to make the game more adventurous. There's a difference between nerfing something because it did break the game in some way, and making the game excessively grindy for people just cuz.
Istg,Minecraft fans have to be the fandom who hates change the most.
Not at all. People are like this by default, because a change mean you either like the thing from before thew change or after the change better, and while some people might be mostly indifferent to some changes, some people might really dislike it one way or the other. And then that's where the divide (or opposition to certain versions) comes from. And there's absolutely nothing wrong with that. People have preferences. It has nothing to do with Minecraft in particular. Minecraft is simply one of the largest communities so it also seems to have a louder voice, so you see those complaints more often.
Istg,Minecraft fans have to be the fandom who hates change the most.
Pretty much every single update from 2017 untill today have been more content than Minecraft received from 2009 till 2016. SPECIALLY Bedrock.
Just the concept of "Minecract receives lackluster content so we should stop updanting it altogether" is already so stupid.
Some of the complaints are very valid though; consider these maps of worlds created in 1.18, 1.6, and my own modded version:
A world created in 1.18+ (6x7 level 3 maps or 6144x7168 blocks):
A world created in my own modded version of the game (instead of updating I just modded the game in my own vision), the mapped area is about 4000x4000 blocks:
A world created in 1.5-1.6, close to the same mapped area as the 1.18+ world; there are only 7 major land biomes but the small-scale variation is vastly greater than since 1.7:
And that is one reason why I think 1.7+ world generation is simply terrible, with 1.18+ being even worse form what I've seen; if you wanted 6000+ block biomes before you could just use the "Large Biomes" world type, or even the "Customized" (form 1.8-1.12) to make them even larger. A game should not replicate real life (granted, real-life can mean thousands of kilometers between climate extremes, but how many players want to spend however many hours traveling instead of actually playing the game, which they may not be able to spend much time on either, an in-game day is only 20 minutes, 72 times shorter than real-time, as should distances be).
Of course, unlike most players who dislike changes I took the route of just using mods to make the game the way I liked it (or rather, get new content without updating at all).
Also, Mojang's policy on fixing bugs is completely inexcusable:
This image shows where in the code the amount of 1.0E-12 is added. “margin” is the double value that is either added or subtracted based on what direction on said cartesian axes the entity is traveling. This needs to be done in AxisAlignedBB.java both in “calculateXOffset” and “calculateZOffset” (MCP name) and NOT in “calculateYOffset”.
It's worth noting that this only fixes entities not glitching into walls when reloading. This does not however fix entities growing up.
This is one of several fixes, and one of the simplest; I implemented it myself years ago, around 2018 (I used a larger margin and added a margin to Y to be extra safe; the latter would also become an issue if infinite height worlds are ever implemented) - and indeed, many other bug fixes posted to Mojang's own bug reports. Also the fact they have however many open issues is simply insane - if you actually fixed them as soon as they were reported you wouldn't have such a massive backlog, and the same seems to apply to most projects of any size (for example, Optifine has over 2,500 open issues, a significant portion of which are bug reports).
Also, the last comment about mobs growing up? There is also a fix given for that on its own report, which I again used and have verified to work (I also enhanced it by making mobs immune to suffocation damage for one tick after they grow up as they could still take a tick of damage):
There are many more examples of bugs which should have been fixed a decade ago; for example, they have rewritten the rendering engine multiple times (in at least 1.8, 1.15, and 1.17) - yet why are these bugs still a thing?
(I'm surprised it took so long for the last one to be reported, it is quite obvious on redstone ore and most have existed since the addition of smooth lighting in Beta 1.3 while the first one appeared in release 1.5, as mentioned by the most recent comment, and worsened in 1.14)
Also, note how long it took for this one to be fixed - 7 years, yet I only had to make a single-line change, again fixing it before it was even reported (the game treated liquids as opaque instead of transparent when rendering smooth lighting, which affects the way it is rendered. In vanilla 1.6.4 there are other blocks, like fences, which also cause artifacts due to being treated as "solid" based on their material):
Your first point seems a bit all over and confuses me. It almost seems contradicting in some ways, so can I ask for some clarity?
I apologize if I haven't clarified enough. Honestly, I wasn't completely sure it wasn't indie anymore until you yourself brought it up. But since it was originally an indie company, that's why I called it that. Just take my word for it, okay? It's as simple as the definition gets.
You say Mojang is an indie company. I disagree with this. It's not quite indie anymore. Mojang and Riot are two examples that may have both been indie companies at the start of the 2010s, but not really anymore. In fact, one of the one things you state in the same point is the slow pace of content/change over time, and the company becoming larger, having been bought out by a parent company, and having its processes shift is a result of this growth. That's a separate subject on its own, but company size does not linearly equal rate of change potential.
Like I said, I'm still calling Mojang an indie company because they were originally this way. It's those flaws with indie companies that prompted the buyout on Microsoft's end; Mojang simply couldn't keep up with the userbase, and I think that buyout was deserved.
Anyway, you state Mojang being a small company is why we should expect faster content changes. This can go the other way, too. While indie titles might be more likely to take risks (as opposed to big publishers who take the safer, more profit likely route, resulting in less originality), it's rare a fully polished idea comes out of an indie title that perfects an evolution of the formula. That's a very tall ask, and I think you're underestimating the accomplishment of Minecraft, anyway. Back then, something like that wasn't seen before, and the tech for it wasn't really there before (at least not in the way Minecraft did it). There's a reason a simple concept with a simple look came relatively late.
That's what I've personally seen from the indie industry, anyway. The flaws of Minecraft to me far outweigh the accomplishments that it did do, and I know that with more experience, the game could've easily been done better. Trust me, I've seen so many other sandbox games out there such as Dino Island and Ultimate Ride, and they tend to have more content and functionality in their own respective areas than Minecraft ever has been to me. And I'm pretty sure similar concepts came out way earlier than this; think Infiniminer here. They just didn't really get off the ground because it happened to be "too new" to the general public, kind of like Polybus in the 1980s.
Remember; this just started as some project by one person. It just happened to blow up. You're putting a lot of expectations on what it should have been in my opinion.
I shouldn't even have to mention that I can tell by experience that it was only those huge pay-to-win servers that caused it to even survive into the 2020s in the first place. Without them, the incompetence of the Minecraft team would've caused the game itself to fizzle out and die all those years ago. Like I said, as someone who's played games like RollerCoaster Tycoon 3 and Zoo Empire, I'm not willing to settle for anything less than the absolute best from developers. It's for those reasons that I personally much prefer AAA over indie, as I've seen the difference myself. Zoo Empire was more innovative than games like Undertale and Stardew Valley could ever be; had people actually gotten their stuff together and understood what an actually good game was, I would've certainly enjoyed them.
Also, huge disagree on indie versus triple A. The indie scene is thriving and has been carrying PC gaming the last decade or so, and then some. Triple A gaming has become more hit or miss for me over time. It's okay in recent years but back before things like Steam really allowed for greater possibilities with indie developers, the gaming market was much more bland and limited in my opinion. I find most of the weight of the (in my opinion) current boon of PC gaming is being carried by the indie segment, and it's not even close.
Unfortunately, that's where your post as a whole comes off as fundamentally flawed. I see things in AAA that most folks would never see, and I've personally given AAA a chance where most others wouldn't have. Even if it were true that AAA has been hit or miss, I know that this period shall too pass. Indie, on the other hand to me, has come off as having way too much artificial difficulty, for one thing, whereas AAA has difficulty based off of actual intelligence. Not to mention the many canceled projects in the indie department. I mean, have you ever seen the original Super Mario Bros. Z Flash animation and The Mario Flipnote Movie? They were both canceled.
I can't speak much to the modding/coding parts of point two.
I was talking about the fact that obfuscation made it more difficult to have mods work between different versions, not to mention for the servers as well; trust me, I remember that time. By discontinuing development, this won't be an issue anymore.
As for three, I disagree. Version 1.19 is rather infamous for that (but it also gets dragged down by the chat thing), but that aside, I disagree. I'm not saying it never happened aside from then, just that I don't think it was at all a big issue besides that one point. And Mojang has expressed learning from it that time. Minecraft has a history roughly a dozen years in making. There's inevitably going to be some things hinted at that time that don't end up getting added. It's just inevitable.
But some of these desisions were most likely based on a poor education on the developers' parts. I personally would've been fine with fireflies being in the game and eaten by frogs, since realism doesn't necessarily matter on my part. I've spent a lot of my time in life watching educational content (and boy, do I wish I was watching Cartoon Network at that time), and so I tend to be smarter than the rest of the children in the world much like me. I know from experience which was a poor decision and which was not so bad after all.
For point four, huge disagree, and I said above since you mentioned this at the opening of your post (I'm replying as I read it). I don't play on the console side if that helps explain my stance, but on the PC side, indie gaming is thriving and in my opinion PC gaming is going through a sort of golden age as of late. Triple A games? Let's see, remakes, remakes, poor ports, same formula again and again, more poor ports that make Minecraft blush, not-technically-a-remake-but-still-the-same-formula, and... remakes, etc. And like you, I'm not "throwing shade" at all those things. I actually don't mind the recent "remake" boom. There's a certain era of gaming (namely PlayStation/PlayStation 2 era, so late 1990s and early 2000s) that stand to gain so much from remakes due to the fact that those games are in that era were a lot of them had low resolution, non-widescreen assets and aged poorly. Go newer and things go HD/widescreen, and super old pixel stuff didn't age quite as bad either. So there's justification to remakes. I loved the remake of Resident Evil 2 (and even to an extent, 3, even if it was underwhelming comparatively). Both are games I paid full price for up front and I don't do that for triple A games often these days. My biggest gaming wish right now is that Final Fantasy IX (totally not the best game ever or anything...) remake rumors come true. And there's been some original ideas on the triple A landscape too. But I can say this. Thank goodness the triple A landscape isn't the only thing we have. In fact, a big company bought up a smaller one here and you saw what happened. It just got monetized more and you can argue the originality slowed down even more. Big budgets can sometimes bring more possibilities, but I think you're dismissing potential of indie titles by outright stating triple A titles just do things better. They don't necessarily, and being beholden to big, publicly traded publishers/companies comes with its own set of drawbacks.
This just sounds like more pessimism on your part for AAA companies, not to mention undeserved support for indie companies. Indie games may have seemed innovative on the surface to me, but how many of those concepts have actually become standard in the gaming industry? From what I know, I haven't seen too many. Meanwhile, AAA has produced things that actually resonate with people like me. I mean, have you ever seen the two Super Mario Maker games? Despite other people's opinions, I would much prefer that over any fan-made engine for Mario fan-game development. And as for me "dismissing" the potential of indie titles? Sorry, but I'm not. I just personally don't see the potential. Like I said, I've seen so many indie titles canceled, not to mention that they're typically made by people with far less experience in the development field. AAA tends to have more experienced developers, and thus, I can expect more from them. Even if AAA isn't so hot in recent years, all they had to do was git gud again. I don't think we need separate markets there.
This just sounds like a "I'm disappointed with it, but can't move on, so I'd rather its development stopped". That's your opinion. There's plenty of people who AREN'T disappointed with modern versions. Version 1.18 (and to an extent, 1.16) reinvigorated my passion for this game. 1.13+ is just a different era, and a much better one in my own opinion. Not everyone thinks modern versions are perfect. FAR from it. But nor does everyone think it's a disappointment that needs to end. Again, FAR from it. But if you're disappointed with it, just acknowledge that and stay to versions you enjoy and/or move on from the game. It doesn't need to formally stop for that to happen. Other games are out there.
That's something I forgot in the OP, and I'll certainly be adding it shortly. I'll certainly be staying on version 1.20, because at this point, I've lost all hope in the game itself. As a former indie studio, you'd think Mojang would do more to actually provide a richer experience than those of the AAA department. Unfortunately, that was proven wrong to me by their track record, and Minecraft is no exception.
As for bonus point 6, that's good! Whenever something big comes (the original Doom I guess), all these clones rush to try their take on the idea. Minecraft, by no means, stands above everything else in the sandbox space in every single regard. Far from it. But I disagree that just because it's older or because other things do things better in some ways, that it should stop. The thing is, a continually developing game for this long is such a rare thing that it's hard to say WHAT Minecraft should be. It';s mostly games as a service (League of Legends) or MMOs (which are also games as a service) that get continual development for so long. But a single purchase game being updated, and constantly, for over a decade? It's a rarity. So there's not much established in that regard to compare to on what Miencraft SHOULD be. Some think it's changed too much, not too little.
It is true that Minecraft being updated for this long is a great thing, but I still stand by why I think development on Minecraft should terminate permanently after 1.20. I could easily develop a mod for this game (it's in my signature, by the way) that makes Minecraft a better game than it ever was in vanilla to me in only a few short hours. That's how smart I am. And the clones have their reasons for doing some things better than Minecraft itself; I would've just preferred an experience much like the AAA department in every way.
As for people moving on, yeah? That happens. Things ebb and flow, peak and decline. That's everything. People were saying the same sorts of things back in the earlier 2010s about Minecraft. People wanting to move on from it is anecdotal, and the game needing to just pack up shop because some people feel that way isn't necessarily any more true now than it was back then.
Here's the ugly truth: my friends saw things in the game(s) that most folks these days would never see or even bother trying to see. This is evidenced by them simply never returning even after so many years later, despite me insisting that they play with me at times. And trust me, I still want to play Dino Island, Ultimate Ride, RollerCoaster Tycoon 3 (I actually still do play it, the Complete Edition, in fact), and Zoo Empire again to this day; I've never really moved on from where I started, and it's made me happy ever since that day. My stepbrothers, Zach and Mason, still stick with AAA like me despite others' "opinions", and I would have to agree with them, as well.
Sorry if that seems a bit scattered, but I read it in chunks and then posted my thoughts, as I wanted to give input on what seemed like a constructive subject that had some time put into it. I don't agree with many of your points, but I don't necessarily think you're wrong either, and sort of get where you're coming from. But it sounds like you've just started moving on, but have been unable to do so. Your thoughts about the game being that it's declining is leading you to feel it should just stop and end on a higher note rather than a lower note, to make it easier for you to move on and live with things. I don't agree with it though. Plenty of people, myself included, still enjoy the modern game.
That's one final disagreement on my part, and I understand. You should probably reread my previous points just in case you've missed anything of particular importance, as I believe it's something I've learned from experience. You're welcome very much.
Responses are in bold. As much as I appreciate your thoughts, a lot of your disagreements are fundamentally flawed, not to mention rather pessimistic for someone willing to seek out the truth. Now, I know I did say that this thread was all my opinion; I'm completely fine with the game itself moving on from 1.20 if that's so, but I posted all of this for a good reason. People much like me are seeing things in Minecraft that most folks would never see, and they happen to be smart much like me. Trust me, I've spent many years in homeschool learning from my mother, and she would agree with my opinions as well. I'm certainly not saying your replies have absolutely no merit to them, I'm just saying that they have issues that most others wouldn't see here.
Rollback Post to RevisionRollBack
Order of the Stone - A mod idea of what Minecraft could've been had it been developed by a team with more expertise; by professional developers and producers.
As much as I appreciate your thoughts, a lot of your disagreements are fundamentally flawed, not to mention rather pessimistic for someone willing to seek out the truth.
These are mere opinions, so it's quite surprising to me that you're calling someone else's flawed but placing yours as the "path to truth". What's flawed here is your approach. For someone who's self declaring themself as "smart" (what's with this recurring pattern of declaring your opinion, a subjective thing, as more objectively correct?), it's disheartening.
You can think my opinions themselves aren't correct merely because I don't share in your opinions. That's fine. I definitely don't ever expect anyone to always agree with me. Likewise, I can (and do) think your argument is flawed. And notice I'm saying your approach/argument is flawed, but not your opinions. I don't think your opinions themselves are flawed, because I can recognize that opinions are subjective things and thus aren't really right or wrong, but I think the argument you're making with your opinion is flawed. What you're doing is making a statement that the game should cease development, mostly because it doesn't cater to your opinions of what it "should be". Well, guess what? Everyone has a different opinion on what the game should be. So we seem to be an impasse, no?
The more important part is this. You are failing to substantiate WHY the game should cease development beyond the aforementioned "I think it should be something else", which isn't a good argument because anyone can make it. The rest of the mentioned things are mostly arbitrary padding; like whether Mojang is indie or not, or whether you like triple A games over indie games or not, or whether you "see things" (haha, what!?) in games that others don't, it is all completely arbitrary insofar as reasons to why the game should cease development. And those things seem to mostly be serving as padding to what is a lack of real reasoning to substantiate WHY development should cease. "I think the game should be something else" doesn't suffice. When the majority of the market is speaking in ways that has convinced Mojang it is worth continuing, then that's the way things will go. I think the game should be something different than what it is. I also enjoy what it is, and don't think it should cease development, despite that.
The onus is on YOU to substantiate WHY it should cease development, because you're the one making a rather bold claim with your opinion, and simply saying you find those who disagree with you as flawed is no reasoning in and of itself. Substantiate it. Saying "I disagree" and "my opinion is more right than those who disagree with me" is just about the biggest non-argument there is.
The answer is obvious here, and I called it out already. The game seemingly doesn't cater on your preferences as well as other games do, so the answer is to move on. But you seem unwilling to do that fully, and instead want to see the game cease development in order to satisfy you into moving on.
Ngl this is the most active serious convo I've seen on here yet.
What's the actual argument for stopping development? Having to update worlds and servers? Content bloat?
Updates keep this game alive. No more updates means no more hype.
Aside from the number, 1.20 is also an arbitrary point to stop. It has no feeling of finality to it and many ideas are still planned but not done yet.
I expected to be able to pivot blocks using motors and levers, and even rotate sets of blocks to create dynamics such as large ships and robotic arms. However, this sadly wasn't the case for me. By discontinuing Minecraft after 1.20, we won't have to worry about features we actually wanted never actually getting implemented, because development would've stopped altogether. I think that Mojang deserves a vacation, perhaps a permanent one at that.
Another feature that was not only "promised" back in 1.5, the Redstone Update, yet not delivered until 1.8, but even then, was so difficult to understand that you'd think it was broken, was minecart coupling. To add insult to injury, this feature is entirely absent in Bedrock Edition -- my preferred edition of Minecraft to play on -- and so is the furnace minecart. Although personally, this is more of a blessing than a curse, as there's nothing complicated to "learn" here, that word being used loosely because it's practically impossible to figure out without a guide or YouTube video.
In other words, the ugly truth is that indie games are based on a lot of false information you might see on the news, or see from what you thought was a "good friend" of yours. The truth is, AAA is still just as good as ever; they're still trying to find new ideas for their games and content. By going ahead and ending Minecraft's development on 1.20, the game can not only be considered "finished", as we will see in the final bullet point, but we won't have to worry about any disappointment anymore. And like I said before, the game never felt like to me a properly polished experience here.
Overall, it seems like a shame that in my humble opinion, Minecraft should end development by 1.20, but the truth is, lots of my friends like Ryan and Mason have permanently moved on from Minecraft, and have not looked back since. This is because they've seen similar issues with the game besides what I just told y'all about, and I'd have to agree with them wholeheartedly.
Order of the Stone - A mod idea of what Minecraft could've been had it been developed by a team with more expertise; by professional developers and producers.
Ironically, you don't even need to mod the actual game to pirate it - the launcher itself is what actually enforces it, either by adding a "-demo" parameter to the game if you haven't bought it (fun fact: versions prior to 1.3 do not recognize this so they actually allow you to play the full game - as even documented on the Wiki - all "cracked" launchers need to do is omit this to allow any version to be played in non-demo mode).
As for the server itself, it is entirely free to download (as all the game files are, actually - just check out https://mcversions.net/, which directly links to the files on Mojang's servers) - and there is actually a setting which lets you disable online authentication - which is all a "cracked" server actually is, and is also clearly documented on the Wiki, and elsewhere (why Mojang hasn't removed such an easily exploited setting is beyond me, I've heard it is so server admins can get on in the event they can't normally login for some reason; as for pre-1.3 versions, they may just not care since they are so outdated they may as well be a stripped-down demo version, otherwise, they could just prevent you from changing versions if you have a demo account):
Thus, obfuscation literally does nothing at all to secure the game against unlicensed usage. My main issue with it is that it makes (vanilla) crash reports impossible to understand unless you have access to deobfuscation mappings, or somebody else had figured out what the issue is, or the error message is clear enough; what does this even mean (division by zero - but where? What is "bit.b"?)
Otherwise, it hasn't bothered me since I simply stopped updating at 1.6.4, with everything after that basically a separate game (if you consider how I version my own mods, based on major updates to world generation, 1.0.0-1.6.4 would be "Minecraft 1.0", 1.7-1.17 is "Minecraft 2.0", and 1.18+ is "Minecraft 3.0"), so there is no issue with having to update mods, which also must be updated because of internal changes to the game's code; the main reason why so many mods stopped updating at or were slow to update past 1.7.10 is not because of obfuscation but because of major internal changes, same for 1.13.
Also, I don't think it is correct to call Minecraft an "indie" game anymore, it hasn't been developed by a single person for well over a decade (there is a subset of players who consider versions up to Beta 1.7.3, when Notch was still dominant, "golden age", with everything since then going in a completely different direction from its original vision). Others consider the Microsoft buyout to be the end of the indie era; by this measure 1.8 was the last "indie" version (though I'd put it at 1.7 at the latest due to major changes in how the game is coded since 1.8).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Your first point seems a bit all over and confuses me. It almost seems contradicting in some ways, so can I ask for some clarity?
You say Mojang is an indie company. I disagree with this. It's not quite indie anymore. Mojang and Riot are two examples that may have both been indie companies at the start of the 2010s, but not really anymore. In fact, one of the one things you state in the same point is the slow pace of content/change over time, and the company becoming larger, having been bought out by a parent company, and having its processes shift is a result of this growth. That's a separate subject on its own, but company size does not linearly equal rate of change potential.
Anyway, you state Mojang being a small company is why we should expect faster content changes. This can go the other way, too. While indie titles might be more likely to take risks (as opposed to big publishers who take the safer, more profit likely route, resulting in less originality), it's rare a fully polished idea comes out of an indie title that perfects an evolution of the formula. That's a very tall ask, and I think you're underestimating the accomplishment of Minecraft, anyway. Back then, something like that wasn't seen before, and the tech for it wasn't really there before (at least not in the way Minecraft did it). There's a reason a simple concept with a simple look came relatively late.
Remember; this just started as some project by one person. It just happened to blow up. You're putting a lot of expectations on what it should have been in my opinion.
Also, huge disagree on indie versus triple A. The indie scene is thriving and has been carrying PC gaming the last decade or so, and then some. Triple A gaming has become more hit or miss for me over time. It's okay in recent years but back before things like Steam really allowed for greater possibilities with indie developers, the gaming market was much more bland and limited in my opinion. I find most of the weight of the (in my opinion) current boon of PC gaming is being carried by the indie segment, and it's not even close.
I can't speak much to the modding/coding parts of point two.
As for three, I disagree. Version 1.19 is rather infamous for that (but it also gets dragged down by the chat thing), but that aside, I disagree. I'm not saying it never happened aside from then, just that I don't think it was at all a big issue besides that one point. And Mojang has expressed learning from it that time. Minecraft has a history roughly a dozen years in making. There's inevitably going to be some things hinted at that time that don't end up getting added. It's just inevitable.
For point four, huge disagree, and I said above since you mentioned this at the opening of your post (I'm replying as I read it). I don't play on the console side if that helps explain my stance, but on the PC side, indie gaming is thriving and in my opinion PC gaming is going through a sort of golden age as of late. Triple A games? Let's see, remakes, remakes, poor ports, same formula again and again, more poor ports that make Minecraft blush, not-technically-a-remake-but-still-the-same-formula, and... remakes, etc. And like you, I'm not "throwing shade" at all those things. I actually don't mind the recent "remake" boom. There's a certain era of gaming (namely PlayStation/PlayStation 2 era, so late 1990s and early 2000s) that stand to gain so much from remakes due to the fact that those games are in that era were a lot of them had low resolution, non-widescreen assets and aged poorly. Go newer and things go HD/widescreen, and super old pixel stuff didn't age quite as bad either. So there's justification to remakes. I loved the remake of Resident Evil 2 (and even to an extent, 3, even if it was underwhelming comparatively). Both are games I paid full price for up front and I don't do that for triple A games often these days. My biggest gaming wish right now is that Final Fantasy IX (totally not the best game ever or anything...) remake rumors come true. And there's been some original ideas on the triple A landscape too. But I can say this. Thank goodness the triple A landscape isn't the only thing we have. In fact, a big company bought up a smaller one here and you saw what happened. It just got monetized more and you can argue the originality slowed down even more. Big budgets can sometimes bring more possibilities, but I think you're dismissing potential of indie titles by outright stating triple A titles just do things better. They don't necessarily, and being beholden to big, publicly traded publishers/companies comes with its own set of drawbacks.
This just sounds like a "I'm disappointed with it, but can't move on, so I'd rather its development stopped". That's your opinion. There's plenty of people who AREN'T disappointed with modern versions. Version 1.18 (and to an extent, 1.16) reinvigorated my passion for this game. 1.13+ is just a different era, and a much better one in my own opinion. Not everyone thinks modern versions are perfect. FAR from it. But nor does everyone think it's a disappointment that needs to end. Again, FAR from it. But if you're disappointed with it, just acknowledge that and stay to versions you enjoy and/or move on from the game. It doesn't need to formally stop for that to happen. Other games are out there.
As for bonus point 6, that's good! Whenever something big comes (the original Doom I guess), all these clones rush to try their take on the idea. Minecraft, by no means, stands above everything else in the sandbox space in every single regard. Far from it. But I disagree that just because it's older or because other things do things better in some ways, that it should stop. The thing is, a continually developing game for this long is such a rare thing that it's hard to say WHAT Minecraft should be. It';s mostly games as a service (League of Legends) or MMOs (which are also games as a service) that get continual development for so long. But a single purchase game being updated, and constantly, for over a decade? It's a rarity. So there's not much established in that regard to compare to on what Miencraft SHOULD be. Some think it's changed too much, not too little.
As for people moving on, yeah? That happens. Things ebb and flow, peak and decline. That's everything. People were saying the same sorts of things back in the earlier 2010s about Minecraft. People wanting to move on from it is anecdotal, and the game needing to just pack up shop because some people feel that way isn't necessarily any more true now than it was back then.
Sorry if that seems a bit scattered, but I read it in chunks and then posted my thoughts, as I wanted to give input on what seemed like a constructive subject that had some time put into it. I don't agree with many of your points, but I don't necessarily think you're wrong either, and sort of get where you're coming from. But it sounds like you've just started moving on, but have been unable to do so. Your thoughts about the game being that it's declining is leading you to feel it should just stop and end on a higher note rather than a lower note, to make it easier for you to move on and live with things. I don't agree with it though. Plenty of people, myself included, still enjoy the modern game.
I think updates should stop until they fix the bad performance so many people are having on their PC's with this game
they don't seem to focus on optimizing the game and how it runs on different sets of hardware anymore, they just rush updates out in part due to impatience of other people who expect them to come out quicker, but I think this is wrong, I think it is far more important to give developers time to finish a product before they release it.
If they can't eliminate the performance issues on people's PC's that meet or exceed the recommended requirements, then they should hire some people who can, while I am not a programmer I do know there are other people in the Minecraft community who have created mods, people who have benchmarks to show what more could be done to make sure the game runs at playable frame rates regardless of what is going on in player worlds.
While it is a gamer's responsibility to ensure the normal operation of their device, they can't really do anything about software which isn't being efficient with the hardware they're running it on, except for to simply not use it. And all PC's no matter the hardware have limits, we can't just blame people's PC's every time they are complaining about an fps drop in a game, sometimes it isn't that simple as they could have high end machines and still be having the same problem. As Princes_Garnet has explained in a different thread, people have had these sorts of problems with Minecraft even on PC's with the fastest desktop CPU's in them, so it's clearly not anything to do with the hardware anymore, it's more the case Mojang just being inefficient with their software engineering or cutting out things which don't need to be running in the game at all times.
But if they don't optimize their game then it doesn't really help that we get more content added to the game,
it could potentially make things worse and until there is enough pressure from the fandom to encourage Mojang
to release updates that massively reduce lag spikes on even PC's with mid tier or hardware released in the last 5 years,
we'll continue to have the same conversation. It's just dumb, that we're having to explain this to developers when they are the ones
in charge and have the power/ability to address it.
Performance improvements don't garner attention like feature changes do, unfortunately. Look at 1.15; it's often ignored in the boon of praise 1.13+ gets simply because it "only added bees" or "didn't even fix all the issues the game has".
It can be unfortunate but its the way our world works. "Good enough" is, well... good enough.
It should also be pointed out that a lot of people are likely playing a game that is typically very CPU heavy on probably older, slow, often mobile (and low clock speed) CPUs/PCs. Often probably below minimum requirements. The minimum/recommended requirements call for a low end Ivy Bridge/mid range Haswell respectively on Intel's side, or pre-Ryzen stuff on AMD's side (and AMD was only offering slower stuff at this time). Such CPUs are pretty old now, and Windows 10 losing support in less than a few years will (at least officially) cut off anything before the 8th generation on Intel's side and the second Ryzen generation on AMD's side (and in three years, those will also be older and slower).
None of this is to say I wouldn't like to see performance be given more focus. It's one of THE things I'd like to see. But I'm just explaining why such an update focused only on that is unlikely to happen. It'd be nice if Minecraft was totally stutter free no matter the circumstances, and ran at 32 to 48 render distance on new stuff, and played smoothly on old Core 2s with only 4 GB or 8 GB of RAM, and so on. But I don't expect development to ever shift to focusing in that direction.
We should not overlook the changes that may happen along the way though, even if they aren't in a dedicated update just for that sort of thing. I've noticed many poor behaviors of older versions that get improved in later versions.
This is one heck of a good first post, and I agree with it entirely. It summarizes things very well.
None of this is to say the opinion of the topic starter is wrong. Everyone has opinions and they are just that, after all.
But I got the impression reading it that someone is "over" what Minecraft currently is, is realizing it is unlikely to change enough to become what they think it should be, and wanting to see development stop to help them move on.
And that part I disagree with. If that's the case, just move on. The game doesn't need to cease changing for one to move on. The gaming landscape is very wide (and in my opinion, wider and even richer than it's ever been), so if one is "over" a given game, there's countless others out there likely to suffice better.
I do see your point however nobody who understands the basics of the tech world, and you know this too, really expects an Intel Core 2 Duo system to run newer versions of Minecraft well. Minecraft used to run at playable frame rates on PC's with dual core CPU's and 4gb of RAM, but as far as we can tell the game does use multi threading for chunk loading operations or when the game is loading. Even after chunk loading has finished I would not recommend anything less than a quad core CPU for the game and even then those cores need to be powerful, not all quad cores are made equal, they all have different architectures as well as clock speeds, as well as l3 cache sizes. We also need to consider that background applications use CPU threads/cores as well, not just the game itself and a quad core CPU can help prevent those background apps from interfering with the app you're using.
But any new PC that is greatly exceeding the recommended requirements by Microsoft, not only meeting them, for this game shouldn't be lagging at all with a 32 chunks render distance, first problem is these PC builds are not cheap and are most definitely not budget builds.
The second is 32 chunks render distance isn't anything special anymore like it used to be, about 5 years ago or more we could've made that argument with a straight face, but not today and there are gameplay benefits to increased render distance, for a start you can see further out into the End dimension, important for seeing outer islands that have End cities and to help players reduce their risk of dying in the void.
16 or less chunks render distance just sucks for anyone, I'd only suggest doing it as a last resort.
But it is not good indication of a PC handling Minecraft, the only reason tablet or console devices like the Nintendo Switch
would be limited to this is because it is what we would expect from a mobile device.
Oh, the Core 2 example was kind of pulled from the air because the game used to run well on them, so I figured it might be a good baseline example for what people might point to and say should be possible. Of course I don't expect them to remain relevant forever, though. I know stuff moves on.
That being said, while it's being mentioned...
I changed the CPU to a Core 2 Quad Q9550 and it actually make very little difference. Which surprised me because the dual core was maxing out on both cores (and any music running in an external application was pausing on and off constantly when loading terrain) so I was expecting a bit more of an improvement.
But those Core 2 Quads weren't monolithic quad cores. They were just a pair of Core 2 Duos on one CPU communicating over the FSB, which probably slows them down heavily here.
Either way, they were practically too slow for the game even then, and I would especially even more so now for 1.18 and above.
It's only not special for Bedrock. It's been difficult on Java, for the most part, from the conception of the game until now.
I used to run on a render distance of up to 32 many years ago, starting with version 1.7 or so, and until 1.10. Frame rates were down at times, but I chose to play that way.
Ironically, I had the best performance I ever had on higher render distances with version 1.16, which a child of the 1.8+ coding practices.
Not necessarily great performance. Probably not all around playable. But that's a render distance of 64, above what the game natively supports in Java. So a render distance of 32, or even then some, was largely playable if I wanted it.
But I didn't care about it anymore. If you had asked me 5+ years ago, I'd say I didn't want less than 32 render distance, and 24 minimum. But when I updated and started a new world in a current (at the time, 1.16) version, I choose a render distance of around 20, later 16 (those bushy leaves did it, and I need them!), instead now because of shaders (and performance). A very high render distance gives you a little more view on a narrow strip of the horizon most of the time. And I felt beautifying the overall image mattered more than that. Granted, I'd love at least 20 or 24 over 16, and I'd possibly even take 32 at times (when flying or up in the mountains, the high distance is more noticed). But beyond that, I think it actually starts to look silly. I'd only play above 32 if I was also playing with large biomes. Seeing across up to half a dozen biomes impacts the immersion of the world to me, and I'd never like it.
And you can go into the end and turn the render distance up easily on Java to find end cities. It's nowhere near as demanding as the other two dimensions.
Anyway, yeah, I'd absolutely love a performance update. But given how Bedrock and Java are different games underneath, and how 1.15 was seemingly not as appreciated, I'm not sure if we'll see that again. Players are more receptive to features so I guess that's what new updates will focus on (and hopefully updates come, because I don't agree they should stop). I'd be fine if they keep improving things as they go in the background to be honest. Remember when the lighting would just mess up? Or was that not a thing in Bedrock? But that's just not a thing in Java anymore, and thank goodness. Improvements as they go is fine by me too. Doesn't need to be a whole update.
I like high render distances for the reasons you would, it allows us to more easily spot what biomes are ahead of us, in the Overworld it has been a big advantage for me and other people who play on my home survival server.
32 chunks render distance is the equivalent of 1024 blocks squared or 512 from center in every direction, it is a lot of blocks the game has to load into memory, but we need to remember tick or simulation distance is a different setting/feature entirely and rendered blocks themselves only affect what can be seen by the player. But these blocks will not update a redstone tick unless a player is close enough to them.
I do wish minecarts were able to circumvent the tick radius or at least for Mojang to give us a variant of a minecart that would keep 1 chunk loaded as this would allow players to send items to each other across long distances using a minecart train or shulker in chest system.
With a performance update having a feature like that may someday become practical, I've suspected the (ironic) reason they haven't added this feature with minecarts is not to do with balance or worry that it would be abused by auto grinders, (which unfortunately also exists for shulker farms, and in my opinion, this should be replaced by continuously spawning shulkers in End cities to compensate for already looted End city structures for other players on a server, even if all of the shulkers had already been killed by previous players, a much better way of making shulker shells and boxes renewable), it is more the case of it causing lag on servers.
Not me; as a very knowledgeable modder I know exactly how much of an impact adding new content should of had, based on the fact that I've observed virtually no impacts for at least a thousand new features (over 350 blocks and items, 100 biomes, 45 new mobs/entity and/or variants of these, dozens of new world generation including dozens of new types of caves, trees, structures, etc).
Vanilla 1.6.4 at maximum settings (note that the render distance is actually only 10 chunks because the internal server only loads that many, no matter what the render distance is):
TMCWv5 at maximum settings (16 chunk render distance, which loads about 2.5 times as many chunks, 1089 vs 441; I set the view so the same number of chunks are being rendered, 842, though this isn't the only factor affecting FPS):
The only thing that really impacts resource usage is the number of blocks and entities loaded, and that explains nearly everything the game needs because there are just so many - something like 22 million at 16 chunks (and actually twice that number because the client and server has two copies of the world loaded, even in singleplayer), which requires about 106 MB of memory (for both sides). Here is a comparison of VisualVM profiler results for 1.6.4 and TMCWv5 (again, note the differences in loaded chunks):
Vanilla 1.6.4; both of these ran for about 5 minutes:
TMCWv5; note that I increased the render distance from 8 to 16 near the start, which caused CPU usage to spike to about 40%; afterwards it drops much faster than in vanilla, which was still doing a lot of chunk updates for quite some time after, while it drops much faster in TMCW, and despite loading over twice as many chunks there were fewer garbage collection cycles, indicating that TMCW is allocating memory at a lower rate - and also using less CPU despite again, loading way more data - that's the power of optimization, and 1.6.4 is very lightweight compared to modern versions:
In fact, these were the system requirements as of 1.6 - which can be expected to still apply to TMCW, even as it has many major updates worth of new content:
How old is the recommended hardware?
How does load time and world creation compare? 1.6.4 should be way faster as its world generation is comparatively so simple and it has a lot less things to load, right?
Vanilla 1.6.4:
[19:11:13] 2023-04-15 19:11:13 [CLIENT] [INFO] (Session ID is null)
[19:11:13] 2023-04-15 19:11:13 [CLIENT] [INFO] LWJGL Version: 2.9.0
[19:11:14] 2023-04-15 19:11:14 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
[19:11:14]
[19:11:14] Starting up SoundSystem...
[19:11:14] Initializing LWJGL OpenAL
[19:11:14] (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
[19:11:14] OpenAL initialized.
[19:11:15]
[19:11:15] 2023-04-15 19:11:15 [CLIENT] [SEVERE] Realms: Server not available!
[19:11:48] 2023-04-15 19:11:48 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
[19:11:48] 2023-04-15 19:11:48 [SERVER] [INFO] Generating keypair
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Converting map!
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Scanning folders...
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Total conversion count is 0
[19:11:49] 2023-04-15 19:11:49 [SERVER] [INFO] Preparing start region for level 0
[19:11:50] 2023-04-15 19:11:50 [SERVER] [INFO] Preparing spawn area: 12%
[19:11:51] 2023-04-15 19:11:51 [SERVER] [INFO] Preparing spawn area: 36%
[19:11:52] 2023-04-15 19:11:52 [SERVER] [INFO] Preparing spawn area: 60%
[19:11:53] 2023-04-15 19:11:53 [SERVER] [INFO] Preparing spawn area: 86%
[19:11:54] 2023-04-15 19:11:54 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 266 at (-94.5, 64.0, 244.5)
[19:11:54] 2023-04-15 19:11:54 [SERVER] [INFO] TheMasterCaver joined the game
TMCWv5:
[18:21:25] 2023-04-15 18:21:25 [CLIENT] [INFO] (Session ID is null)
[18:21:26] 2023-04-15 18:21:26 [CLIENT] [INFO] LWJGL Version: 2.9.0
[18:21:26] 2023-04-15 18:21:26 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
[18:21:27]
[18:21:27] Starting up SoundSystem...
[18:21:27] Initializing LWJGL OpenAL
[18:21:27] (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
[18:21:27] OpenAL initialized.
[18:21:27]
[18:22:04] 2023-04-15 18:22:04 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
[18:22:04] 2023-04-15 18:22:04 [SERVER] [INFO] Generating keypair
[18:22:04] 2023-04-15 18:22:04 [SERVER] [INFO] Preparing start region for level 0
[18:22:05] 2023-04-15 18:22:05 [SERVER] [INFO] Preparing spawn area: 19%
[18:22:06] 2023-04-15 18:22:06 [SERVER] [INFO] Preparing spawn area: 58%
[18:22:07] 2023-04-15 18:22:07 [SERVER] [INFO] Preparing spawn area: 99%
[18:22:07] 2023-04-15 18:22:07 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 137 at (-245.5, 70.0, -253.5)
[18:22:07] 2023-04-15 18:22:07 [SERVER] [INFO] TheMasterCaver joined the game
Yet somehow(!) TMCW took only half as much time to generate a new world, despite being vastly more complex - again, the power of optimization. 1.13 is absolutely terrifying by comparison, considering it has multithreaded chunk generation, yet took far longer than vanilla 1.6.4:
[17:55:31] [Server thread/INFO]: Generating keypair
[17:55:31] [Server thread/INFO]: Found new data pack vanilla, loading it automatically
[17:55:31] [Server thread/INFO]: Reloading ResourceManager: Default
[17:55:32] [Server thread/INFO]: Loaded 524 recipes
[17:55:33] [Server thread/INFO]: Loaded 571 advancements
[17:55:36] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld
[17:55:37] [Server thread/INFO]: Preparing spawn area: 0%
[17:55:37] [Server thread/INFO]: Preparing spawn area: 4%
[17:55:38] [Server thread/INFO]: Preparing spawn area: 8%
[17:55:38] [Server thread/INFO]: Preparing spawn area: 12%
[17:55:38] [Server thread/INFO]: Preparing spawn area: 16%
[17:55:39] [Server thread/INFO]: Preparing spawn area: 20%
[17:55:39] [Server thread/INFO]: Preparing spawn area: 24%
[17:55:39] [Server thread/INFO]: Preparing spawn area: 28%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 32%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 36%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 40%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 44%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 48%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 52%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 56%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 60%
[17:55:42] [Server thread/INFO]: Preparing spawn area: 64%
[17:55:42] [Server thread/INFO]: Preparing spawn area: 68%
[17:55:42] [Server thread/INFO]: Preparing spawn area: 72%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 76%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 80%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 84%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 88%
[17:55:44] [Server thread/INFO]: Preparing spawn area: 92%
[17:55:44] [Server thread/INFO]: Preparing spawn area: 96%
[17:55:44] [Server thread/INFO]: Preparing spawn area: 100%
[17:55:44] [Server thread/INFO]: Time elapsed: 8520 ms
[17:55:45] [Server thread/INFO]: Changing view distance to 12, from 10
[17:55:46] [Server thread/INFO]: TheMasterCaver[local:E:c0336e00] logged in with entity id 754 at (58.5, 71.0, -104.5)
[17:55:46] [Server thread/INFO]: TheMasterCaver joined the game
The only place where TMCW is noticeably heavier is in the save size, which is because of the greatly increased complexity of the world, as indicated by the MCEdit analyses following (both areas are the same size):
1.6.4; 138 blocks / block variants and 347 entities:
(1:0),Stone,6828349
(2:0),Grass,84800
(3:0),Dirt,754782
(4:0),Cobblestone,3178
(5:0),Wood Planks,3435
(7:0),Bedrock,406323
(8:1),Water (active),41072
(10:0),Lava (active),78740
(12:0),Sand,145920
(13:0),Gravel,229644
(14:0),Gold Ore,4276
(15:0),Iron Ore,46358
(16:0),Coal Ore,87467
(17:0),Wood,1526
(17:1),Pine Wood,1692
(17:2),Birch Wood,320
(17:3),Jungle Wood,7596
(17:4),Wood,73
(17:8),Wood,52
(18:0),Leaves,29834
(18:1),Pine Leaves,7836
(18:2),Birch Leaves,2202
(18:3),Jungle Leaves,20209
(18:8),Leaves (Decaying),8805
(18:9),Pine Leaves (Decaying),5155
(18:10),Birch Leaves (Decaying),663
(18:11),Jungle Leaves (Decaying),6796
(21:0),Lapis Lazuli Ore,1784
(24:0),Sandstone,48869
(30:0),Web,343
(31:1),Tall Grass,19371
(31:2),Fern,828
(32:0),Dead Shrub,74
(35:15),Black Wool,1
(37:0),Flower,348
(38:0),Rose,90
(39:0),Brown Mushroom,53
(40:0),Red Mushroom,35
(43:0),Double Stone Slab,22
(48:0),Moss Stone,497
(49:0),Obsidian,808
(50:1),Torch,12
(50:2),Torch,10
(50:3),Torch,12
(50:4),Torch,4
(52:0),Monster Spawner,14
(53:0),Wooden Stairs,116
(53:1),Wooden Stairs,89
(53:2),Wooden Stairs,130
(53:3),Wooden Stairs,83
(54:2),Chest,3
(54:3),Chest,5
(54:4),Chest,2
(54:5),Chest,4
(56:0),Diamond Ore,1610
(59:2),Crops,7
(59:3),Crops,11
(59:4),Crops,16
(59:5),Crops,17
(59:6),Crops,14
(59:7),Crops,47
(60:7),Farmland,168
(64:0),Wooden Door,1
(64:1),Wooden Door,7
(64:2),Wooden Door,4
(64:8),Wooden Door,12
(65:2),Ladder,8
(65:4),Ladder,9
(66:0),Rail,312
(66:1),Rail,217
(66:2),Rail,1
(66:7),Rail,1
(66:9),Rail,1
(67:0),Stone Stairs,1
(67:1),Stone Stairs,2
(67:3),Stone Stairs,3
(72:0),Wooden Pressure Plate,5
(73:0),Redstone Ore,12837
(78:0),Snow Layer,13325
(79:0),Ice,850
(81:0),Cactus,53
(81:1),Cactus,2
(81:2),Cactus,2
(81:3),Cactus,2
(81:4),Cactus,3
(81:5),Cactus,7
(81:6),Cactus,8
(81:7),Cactus,3
(81:9),Cactus,4
(81:11),Cactus,2
(81:12),Cactus,1
(82:0),Clay,626
(83:0),Sugar Cane,46
(83:2),Sugar Cane,1
(83:4),Sugar Cane,1
(83:6),Sugar Cane,1
(83:7),Sugar Cane,1
(85:0),Fence,1463
(102:0),Glass Pane,76
(106:0),Vines,8
(106:1),Vines,5448
(106:2),Vines,4611
(106:3),Vines,13
(106:4),Vines,5507
(106:5),Vines,4
(106:6),Vines,13
(106:8),Vines,4345
(106:9),Vines,7
(106:10),Vines,1
(106:11),Vines,1
(106:12),Vines,12
(111:0),Lilypad,6
(127:0),Cocoa Plant,5
(127:1),Cocoa Plant,4
(127:2),Cocoa Plant,7
(127:3),Cocoa Plant,3
(127:4),Cocoa Plant,6
(127:5),Cocoa Plant,2
(127:6),Cocoa Plant,4
(127:7),Cocoa Plant,6
(127:8),Cocoa Plant,4
(127:9),Cocoa Plant,7
(127:10),Cocoa Plant,5
(127:11),Cocoa Plant,13
(141:2),Carrots,2
(141:3),Carrots,6
(141:4),Carrots,2
(141:5),Carrots,2
(141:6),Carrots,7
(141:7),Carrots,9
(142:2),Potatoes,3
(142:3),Potatoes,3
(142:4),Potatoes,4
(142:5),Potatoes,5
(142:6),Potatoes,5
(142:7),Potatoes,8
,,
,<Entities>,347
Bat,Bat,22
Chicken,Chicken,52
Cow,Cow,28
Creeper,Creeper,29
Item,Egg,13
Item,Gravel,1
Item,Rail,5
Item,Seeds,1
Item,String,1
MinecartChest,MinecartChest,9
Pig,Pig,77
Sheep,Sheep,31
Skeleton,Skeleton,30
Spider,Spider,2
Squid,Squid,8
Villager,Villager,18
Zombie,Zombie,20
,,
,<TileEntities>,28
Chest,Chest,14
MobSpawner,MobSpawner,14
TMCWv5; 283 blocks / block variants and 351 entities; there are also about twice as many chests and mob spawners, mainly due to random variation; note that despite terrain being higher on average there are more air blocks than the vanilla world had (there are only about half as many lava blocks due to the fact that the cave lava layer is only 3 layers deep, also possibly variation as these areas were only 368x368 blocks):
(1:0),Stone,4762059
(1:1),Stone,219949
(1:3),Stone,391886
(1:5),Stone,618613
(1:8),Stone,6143
(1:15),Stone,27
(2:0),Grass,87200
(2:1),Grass,272
(3:0),Dirt,685957
(3:1),Dirt,134
(4:0),Cobblestone,1205
(5:0),Wood Planks,1355
(5:1),Wood Planks,3961
(5:3),Wood Planks,179
(5:4),Wood Planks,3
(7:1),Bedrock,117204
(7:2),Bedrock,2019
(7:8),Bedrock,16201
(9:0),Water,126756
(11:0),Lava,38922
(12:0),Sand,19473
(12:1),Sand,134652
(13:0),Gravel,110853
(13:1),Gravel,76175
(14:0),Gold Ore,3957
(14:2),Gold Ore,534
(15:0),Iron Ore,40795
(15:2),Iron Ore,5478
(16:0),Coal Ore,75301
(16:2),Coal Ore,9427
(17:0),Wood,3237
(17:1),Pine Wood,3799
(17:2),Birch Wood,1142
(17:3),Jungle Wood,3517
(17:4),Wood,13
(17:5),Wood,12
(17:6),Wood,4
(17:7),Wood,9
(17:8),Wood,4
(17:9),Wood,5
(17:10),Wood,5
(17:12),Wood,1196
(17:13),Wood,802
(17:14),Wood,186
(17:15),Wood,1356
(18:0),Leaves,47912
(18:1),Pine Leaves,36424
(18:2),Birch Leaves,9357
(18:3),Jungle Leaves,18138
(21:0),Lapis Lazuli Ore,1930
(21:2),Lapis Lazuli Ore,227
(24:0),Sandstone,273
(24:4),Sandstone,15955
(30:0),Web,1067
(31:0),(Unused Shrub),11305
(31:1),Tall Grass,1580
(31:2),Fern,58
(31:3),(Unused Shrub),52
(32:0),Dead Shrub,97
(35:15),Black Wool,3
(37:0),Flower,215
(37:1),Flower,53
(37:2),Flower,83
(37:3),Flower,61
(37:4),Flower,20
(37:6),Flower,42
(37:7),Flower,43
(37:8),Flower,42
(37:9),Flower,53
(37:10),Flower,44
(37:11),Flower,52
(37:12),Flower,49
(37:13),Flower,59
(37:14),Flower,26
(37:15),Flower,37
(38:0),Rose,181
(39:0),Brown Mushroom,296
(39:1),Brown Mushroom,77
(39:2),Brown Mushroom,86
(39:3),Brown Mushroom,69
(39:4),Brown Mushroom,90
(43:0),Double Stone Slab,11
(48:0),Moss Stone,875
(49:0),Obsidian,2156
(52:0),Monster Spawner,35
(53:8),Wooden Stairs,77
(53:9),Wooden Stairs,92
(53:10),Wooden Stairs,58
(53:11),Wooden Stairs,39
(54:2),Chest,9
(54:3),Chest,8
(54:4),Chest,5
(54:5),Chest,9
(56:0),Diamond Ore,1026
(56:2),Diamond Ore,133
(59:2),Crops,5
(59:3),Crops,7
(59:4),Crops,5
(59:5),Crops,13
(59:6),Crops,6
(59:7),Crops,20
(60:7),Farmland,112
(64:0),Wooden Door,3
(64:1),Wooden Door,7
(64:2),Wooden Door,1
(64:8),Wooden Door,10
(64:9),Wooden Door,1
(65:2),Ladder,4
(65:4),Ladder,9
(66:0),Rail,466
(66:1),Rail,517
(72:2),Wooden Pressure Plate,4
(73:0),Redstone Ore,8080
(73:2),Redstone Ore,1062
(75:1),Redstone Torch (off),25
(75:2),Redstone Torch (off),16
(75:3),Redstone Torch (off),17
(75:4),Redstone Torch (off),24
(75:9),Redstone Torch (off),12
(75:10),Redstone Torch (off),7
(75:11),Redstone Torch (off),7
(75:12),Redstone Torch (off),8
(75:13),Redstone Torch (off),8
(81:0),Cactus,18
(81:5),Cactus,1
(81:8),Cactus,11
(81:9),Cactus,1
(81:10),Cactus,1
(81:13),Cactus,1
(82:0),Clay,2141
(83:0),Sugar Cane,65
(83:1),Sugar Cane,1
(83:3),Sugar Cane,1
(83:4),Sugar Cane,1
(83:5),Sugar Cane,2
(83:6),Sugar Cane,1
(85:0),Fence,880
(85:1),Fence,2244
(85:3),Fence,116
(85:4),Fence,4
(98:0),Stone Bricks,1613
(98:1),Mossy Stone Bricks,153
(98:2),Cracked Stone Bricks,478
(98:3),Circle Stone Bricks,55
(99:1),Huge Brown Mushroom (Northwest),68
(99:2),Huge Brown Mushroom (North),49
(99:3),Huge Brown Mushroom (Northeast),68
(99:4),Huge Brown Mushroom (West),45
(99:5),Huge Brown Mushroom (Top),141
(99:6),Huge Brown Mushroom (East),45
(99:7),Huge Brown Mushroom (Southwest),54
(99:8),Huge Brown Mushroom (South),41
(99:9),Huge Brown Mushroom (Southeast),54
(99:10),Huge Brown Mushroom (Stem),79
(99:11),Huge Brown Mushroom,13
(100:1),Huge Red Mushroom (Northwest),47
(100:2),Huge Red Mushroom (North),43
(100:3),Huge Red Mushroom (Northeast),47
(100:4),Huge Red Mushroom (West),40
(100:5),Huge Red Mushroom (Top),162
(100:6),Huge Red Mushroom (East),39
(100:7),Huge Red Mushroom (Southwest),45
(100:8),Huge Red Mushroom (South),39
(100:9),Huge Red Mushroom (Southeast),43
(100:10),Huge Red Mushroom (Stem),76
(100:11),Huge Red Mushroom,33
(102:0),Glass Pane,57
(103:0),Watermelon,2
(106:0),Vines,37
(106:1),Vines,2615
(106:2),Vines,1981
(106:3),Vines,11
(106:4),Vines,2570
(106:5),Vines,8
(106:6),Vines,14
(106:8),Vines,2034
(106:9),Vines,15
(106:10),Vines,4
(106:12),Vines,14
(109:0),Stone Brick Stairs,1
(109:1),Stone Brick Stairs,2
(109:2),Stone Brick Stairs,2
(109:3),Stone Brick Stairs,5
(127:0),Cocoa Plant,2
(127:1),Cocoa Plant,5
(127:2),Cocoa Plant,2
(127:3),Cocoa Plant,4
(127:4),Cocoa Plant,3
(127:5),Cocoa Plant,3
(127:6),Cocoa Plant,2
(127:7),Cocoa Plant,2
(127:8),Cocoa Plant,6
(127:9),Cocoa Plant,5
(127:10),Cocoa Plant,4
(127:11),Cocoa Plant,11
(141:2),Carrots,2
(141:3),Carrots,2
(141:4),Carrots,6
(141:5),Carrots,6
(141:6),Carrots,5
(141:7),Carrots,7
(142:2),Potatoes,3
(142:3),Potatoes,4
(142:4),Potatoes,6
(142:5),Potatoes,4
(142:6),Potatoes,5
(142:7),Potatoes,6
(161:3),Future Block!,759
(162:0),Future Block!,503
(164:1),Future Block!,56
(164:2),Future Block!,52
(164:3),Future Block!,56
(164:4),Future Block!,52
(164:5),Future Block!,248
(164:6),Future Block!,52
(164:7),Future Block!,54
(164:8),Future Block!,49
(164:9),Future Block!,54
(164:10),Future Block!,98
(164:11),Future Block!,48
(165:1),Future Block!,73
(165:2),Future Block!,60
(165:3),Future Block!,72
(165:4),Future Block!,55
(165:5),Future Block!,136
(165:6),Future Block!,55
(165:7),Future Block!,67
(165:8),Future Block!,53
(165:9),Future Block!,67
(165:10),Future Block!,95
(165:11),Future Block!,32
(166:1),Future Block!,40
(166:2),Future Block!,41
(166:3),Future Block!,41
(166:4),Future Block!,41
(166:5),Future Block!,180
(166:6),Future Block!,41
(166:7),Future Block!,41
(166:8),Future Block!,41
(166:9),Future Block!,41
(166:10),Future Block!,82
(166:11),Future Block!,18
(167:7),Future Block!,5
(167:8),Future Block!,5
(167:10),Future Block!,7
(168:1),Future Block!,744951
(175:0),Future Block!,238
(175:1),Future Block!,50
(175:2),Future Block!,5923
(175:3),Future Block!,1527
(175:4),Future Block!,64
(175:5),Future Block!,88
(180:0),Future Block!,59
(180:4),Future Block!,71
(180:8),Future Block!,26
(181:0),Future Block!,391
(185:0),Future Block!,314
(185:2),Future Block!,62
(185:8),Future Block!,803
(185:10),Future Block!,97
(186:0),Future Block!,190
(186:2),Future Block!,56
(186:8),Future Block!,550
(186:10),Future Block!,106
(187:0),Future Block!,21
(187:2),Future Block!,4
(187:8),Future Block!,73
(187:10),Future Block!,23
(188:0),Future Block!,2256
(188:1),Future Block!,8
(188:2),Future Block!,3
(188:3),Future Block!,10
(188:4),Future Block!,8
(188:5),Future Block!,5
(188:6),Future Block!,2
(188:7),Future Block!,6
(188:8),Future Block!,8
(188:9),Future Block!,10
(188:10),Future Block!,6
(200:0),Future Block!,202
(200:2),Future Block!,24
,,
,<Entities>,351
Bat,Bat,22
CaveSpider,CaveSpider,5
Chicken,Chicken,32
Cow,Cow,22
Creeper,Creeper,15
Fish,Fish,10
Horse,Horse,6
Item,Brown Mushroom,15
Item,Rail,2
Item,Rotten Flesh,1
Item,Seeds,16
Item,Stick,1
MinecartChest,MinecartChest,25
Ozelot,Ozelot,2
Pig,Pig,38
Rabbit,Rabbit,22
Sheep,Sheep,48
Skeleton,Skeleton,22
Spider,Spider,4
Squid,Squid,15
Villager,Villager,13
Witch,Witch,2
Zombie,Zombie,13
,,
,<TileEntities>,66
Chest,Chest,31
MobSpawner,MobSpawner,35
Fact is, it completely blows my mind how resource intensive modern versions are, even more so traditional modded versions - absolutely insane; just WHAT is using all of that?! No, I'm NOT going to install a modpack, or even a modern version, just so I can analyze its resource usage:
Saying "only" as if 6-8 GB is nothing when I had only 512 MB allocated in the examples above, and this thread claims that even modded 1.3 requires at least that much just to get started, much less load a world at a higher view distance than supported by the game unless you use Optifine (again, 10 chunks loads 441 chunks while 16 chunks loads 1089 chunks; 1089 / 441):
Here are more VisualVM analyses, this time comparing the top objects by memory usage ("retained size", which includes all memory referenced by any objects they hold; the sum of the column is not the total, which can be derived from the percentage used by the top entry):
1.6.4; total memory usage was about 111.3 MB, with 61.5 MB (55.3%) used by loaded chunks and 49.8 MB used by everything else (note that there are actually 1066 chunks loaded, not 882 or 441 x 2, since the spawn chunks are 625 chunks, but only server-side; the number would be even higher if I was outside the spawn area):
TMCWv5; total memory usage was about 164.4 MB, with 137.6 MB (83.7%) used by loaded chunks and 26.8 MB used by everything else (in this case the same number of chunks, 1089, or 2178 total, are loaded on both sides as there are no spawn chunks loaded, except during initial world creation, so it also doesn't matter where I am in the world):
Yes, you read that right - when excluding loaded chunks TMCW uses only about half as much memory! This is clearly visible in some of the classes; RenderGlobal is 2.84 MB in vanilla but TMCW's RenderGlobalTMCW class is only 2.18 MB, and it combines two major rendering classes (RenderGlobal and EntityRenderer). Likewise, vanilla's WorldRenderer takes up 2.56 MB while TMCW's ChunkRenderer only takes up 1.76 MB - and there are 1.61 times more instances due to the higher render distance (in other words, each one less than half as much memory, 106 vs 248 bytes)! This in part because I removed several objects in favor of simpler fields, which also means there are tens of thousands less objects than there would otherwise be (this is why the "size" is the same as "retained", while in vanilla the latter is much larger. Even if you just compare the "size" vanilla still needs 126 bytes per instance). The same goes for many other classes, which all add up to a 50% reduction in baseline memory usage - if I had set TMCW to 10 chunks instead, to load the same number as vanilla, it would be using less memory overall, and even less CPU (which was already lower).
Sure, there are still cases where something can use a lot of memory, for example, look at how much memory is used by mineshafts, and there were only 10 loaded - but at least I don't load or save the data for every single mineshaft in the entire world, like vanilla does, and they are only created if a chunk is being populated with part of them (if I reloaded the world and took another heap dump it would show 0 instances, so only the amount of new terrain generated in a given session matters, plus vanilla's "MapGenStructureData" class stores its own data separately from the "MapGenMineshaft" class, which is already using 1/6 as much memory despite only a single village, which still uses it, being present):
MC-33134 Mineshaft.dat uses too much CPU (this should be "too much memory, forcing high CPU usage via garbage collections)
Whether you could say I truly fixed this or not, it will never become such an issue unless you did something unrealistic like continuously flying for days on end, or kept the game running with a world loaded when you weren't playing. In order for mineshaft data to use an amount of memory comparable to loaded chunks you'd have to load on the order of 10,000 of them, or 1.8 million chunks (due to vanilla's inefficient saved structure data format it can only handle a small fraction of this; comments suggest that only about 600 mineshafts, or 60,000 chunks in vanilla, use the same amount of memory - so I can claim to have optimized them by a factor of 30. This also means that my first world, about 135,000 chunks, would use several times more memory if I hadn't disabled structure saving for mineshafts - as it is, it uses no more than a brand-0new world).
Likewise, I'm sure there are ways to greatly optimize the rendering of chests but at least I doubled their performance with some relatively minor changes, and at least there are barrels, which have no more impact than rendering a block like stone does, plus I still get enough FPS to remain stable with a framerate limit / Vsync (which is probably what most developers are happy with, ignoring the fact that they might have an above-average computer - I even still code parts of TMCW as if I still had a 32 bit system, as I did for the first few years I played):
Note that the memory usage shown by VisualVM does not include the code itself (or VRAM usage) but this is self-explanatory (the size of TMCWv5 has increased a bit since a year ago but it is still less than 7 MB - I even added new features from updates as recent as 1.19, including before its official release, like a Swift Sneak enchantment (which only required a few lines of code - once you have the base code for a general type of feature (entities, blocks, items, enchantments, biomes, etc) each new instance needs a lot less to be added*). My modded jars also include a lot of unused vanilla classes since I renamed many of them instead of just modifying the originals, while deleting META-INF reduced the size, either way, even just 1.8, the first update where Mojang adopted their current programming practices, at least on a large scale, is larger despite having only a small fraction of the content (my own code also has far fewer classes, about 1/3 as many when compared to the same overall source size of vanilla 1.6.4; conversely, 1.8 has far more small classes and is far more complex internally as a result):
*This is all the code involved with my "Swift Sneak" enchantment, excluding unrelated parts of existing classes that were modified to include the code for it (only "EnchantmentSwiftSneak" is entirely new):
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Yes, I like higher render distances too... to a point. Above around 32 chunks and I feel like I'd want to play on large biomes to counteract seeing so many biome transitions in view. Yet the climate zones of versions from 1.7 and on would make playing on large biomes painful. So even if performance wasn't an issue, I probably wouldn't want to play above 32 render distance.
But obviously, the game could stand to do with performance improvements. Being able to play at higher distances is a very nice benefit of Bedrock. And both versions probably have performance areas they could have improved.
Going to spoiler the rest since it's more specific to this subject of performance that came up rather than the topic of the thread. (Speaking of which, I'm surprised the thread starter hasn't returned and replied yet, so I'm hoping they don't feel chased off?)
What!?
Disclaimer that's it not practical to play like this. Frame rate drops to around 30 when flying around and loading in many chunks, or in some instances, a stutter when moving the camera. I was also surprised to see GPU use as high as it was, and VRAM was at 5 GB or more.
But even though it had "settled" in these pictures, I was still shocked at the numbers. I have never seen them even settle so close to 60 FPS before. I was expecting FAR lower given what I was getting in 1.16, which I considered the best I've seen for performance at high render distances in Java. I was expecting 1.18 had dragged performance far down.
Granted, I've had a CPU upgrade in that time... but I don't think that entirely explains this. I think I was overestimating how much performance had dropped with 1.18. Because even on the Bedrock side, I have seen many complaints of it (special mention to those dealing with it on the Switch).
This got me wondering... what is a render distance of 32 like in modern versions? Would it be remotely playable on decent modern hardware? (Might need to wait for it to process in HD if it's blurry.)
I'm speechless. Absolutely speechless. It's entirely playable. Not quite the way I'd want (I'd want to put some resource packs and antialiasing on, which might bring it down from that constant 60 FPS), but it's more than playable for sure. Even near all the cows! I've become so used to playing with shaders, and even though I knew they were seriously performance demanding and that I was limited by my graphics card, I still did not expect it to be this "high" in "vanilla". It makes me wonder if the Sodium trio would improve on this even more. This was with OptiFine.
I dare say, albeit slightly, this changes/improves my opinion on Java's performance quite a bit.
I know a lot of people are dealing with worse, due to having slower systems, but I thought it was MUCH worse than this on even newer hardware ever since 1.18 at least.
Of course, modded/shaders still remain a different scenario altogether.
So I guess you were ironically right? A render distance of 32 isn't necessarily so special anymore?
But yeah, out of curiosity, I am wondering if the thread starter has more to add, or to comment on some things said in response to their points. It's all opinions anyway, but I'm interested in what they would have to say. Like it seems like they are "over the game" and wants to see it stop development because they aren't happy with it. If that is the case, I'm wondering why they feel it should stop updating at 1.20 specifically, and why they don't just move on to other games if they feel other games are more to their liking?
You're right MC 1.20 isn't about this however my point is that I think unless they fix the performance issues with the game I would not be comfortable with them to keep adding more content to the game which depending on how much more is being loaded it would cause Minecraft to become even more bloated than it already is. If my PC could do it without any lag spikes whatsoever I'd go for a 64 chunks render distance then terminate the increase there as I'd be satisfied with it, and as you said we could use large biomes to negate the transitioning of biomes coming into view too often. It's nice to see what the next biome is ahead of you in each direction, but one thing which would be offputting is if say you saw an ice spikes biome close by an arid desert, which would feel out of place and that is the sort of thing we would wish to prevent.
I'm sure some people would want a 128+ chunks rendering distance if they could use it during normal gameplay, the thing is there comes a point where there are diminishing returns for this, and the further out the world generates the smaller the distant features would appear to the naked eye, which would eventually make it too difficult to see what biomes were there or even if you could see them, they would appear very small and thin from one biome transition to the next. I do wish we could mask the edge of the rendered chunks with fog in the Overworld though, with the game prioritizing frames per second over chunk updates.
This isn't what is going to happen in the future of the game's development sadly, there will be more updates well beyond 1.20.
And from what I can tell 1.20 isn't doing squat to improve the game, we've got a template coming which we will need to upgrade to Netherite gear, more work for the same items and not in a good way either. Isn't it penalizing enough that netherite gear is non renewable and rare? apparently Mojang didn't think so, but the devil is in the details, we get updates imposed on us for better or for worse and unless we play Java edition, we do not have a choice in which version of the game we are playing in either single or multiplayer.
I still don't know why choosing your own version in Bedrock isn't a thing. Or pausing the game. My only guess is its because they want their cross platform play to just always work between anyone regardless.
I agree. Pausing in single player should be doable, and if the player is the only person on the server at that point in time then that should also be able to be paused, the pause being cancelled out if somebody else joins, but I guess a feature like that is simply too much work for them and since it's a minor inconvenience it would be better to fix other issues first.
Although I have expressed grievances about nerfs in the game, there are some nerfs I agree with, so did my friend lizking10152011, for example Notch Apples were overpowered in the past, egregiously so that they were effectively a cheap way to get a demigod mode for a player, to counter this, the enchanted golden apple is no longer craftable, and can only be legitimately obtained in naturally generated chests found in certain locations.
I also agree that beds are far too OP for the items needed to craft them, bed mining is the best example of this one, as they have an explosive force that far exceeds TNT in addition to be crafted cheaply using only wool and wood on a crafting table. Wool can either be obtained by crafting it with string from Spiders or from Sheep, sheared or killed. I've held this opinion about beds for a long time also.
One way to balance it would be to make wool be only obtainable using shears on Sheep, and remove naturally generated beds from Villages.
Another, remove their ability to explode in both the Nether and End, beds are not supposed to be used as weapons, they are merely tools to allow players to set their spawn and reset night time back to day time if used in Overworld.
Furthermore, beds have an exploit which can be heavily abused and that is players can leave a server to allow another to sleep, and then rejoin the server while it being daytime. This I feel is wrong, as players are not encouraged to all bring beds with them on their travels in the Overworld, they can get lazy about it and simply not bring a bed with them to save inventory space and then rely on a team member to do the work of time skipping.
Under the new system, beds could be rebalanced to punish players for doing this, but only if it is night time, if a player leaves when it is night time,
they could be expected to wait about 2 to 5 minutes before rejoining, so that they have less time of the day when they rejoin. If players need to leave to have a break they still are given time to do that and the cooldown would likely expire at the point of their return, so they are not punished for this.
I'm okay with nerfs if it is something that involves making something function as originally intended and if it does something which improves the game for people, although even that can be hard to pin down because we don't really know what devs were thinking at the time they made things the way they did.
But sometimes I think nerfs are done just because a minority complained about something they didn't like, or because a developer felt like adding in something random and nobody asked for, just to inconvenience other's, the armour templates in 1.20 being an example of this. Why should players be expected to collect templates, which are not even guaranteed to be in newly generated Bastions, it's chance based, just to craft netherite gear? this change made no sense whatsoever, it's more work put in just to make the same item and it does nothing to make the game more adventurous. There's a difference between nerfing something because it did break the game in some way, and making the game excessively grindy for people just cuz.
Istg,Minecraft fans have to be the fandom who hates change the most.
Pretty much every single update from 2017 untill today have been more content than Minecraft received from 2009 till 2016. SPECIALLY Bedrock.
Just the concept of "Minecract receives lackluster content so we should stop updanting it altogether" is already so stupid.
Not at all. People are like this by default, because a change mean you either like the thing from before thew change or after the change better, and while some people might be mostly indifferent to some changes, some people might really dislike it one way or the other. And then that's where the divide (or opposition to certain versions) comes from. And there's absolutely nothing wrong with that. People have preferences. It has nothing to do with Minecraft in particular. Minecraft is simply one of the largest communities so it also seems to have a louder voice, so you see those complaints more often.
Some of the complaints are very valid though; consider these maps of worlds created in 1.18, 1.6, and my own modded version:
A world created in my own modded version of the game (instead of updating I just modded the game in my own vision), the mapped area is about 4000x4000 blocks:
A world created in 1.5-1.6, close to the same mapped area as the 1.18+ world; there are only 7 major land biomes but the small-scale variation is vastly greater than since 1.7:
And that is one reason why I think 1.7+ world generation is simply terrible, with 1.18+ being even worse form what I've seen; if you wanted 6000+ block biomes before you could just use the "Large Biomes" world type, or even the "Customized" (form 1.8-1.12) to make them even larger. A game should not replicate real life (granted, real-life can mean thousands of kilometers between climate extremes, but how many players want to spend however many hours traveling instead of actually playing the game, which they may not be able to spend much time on either, an in-game day is only 20 minutes, 72 times shorter than real-time, as should distances be).
Of course, unlike most players who dislike changes I took the route of just using mods to make the game the way I liked it (or rather, get new content without updating at all).
Also, Mojang's policy on fixing bugs is completely inexcusable:
This is one of several fixes, and one of the simplest; I implemented it myself years ago, around 2018 (I used a larger margin and added a margin to Y to be extra safe; the latter would also become an issue if infinite height worlds are ever implemented) - and indeed, many other bug fixes posted to Mojang's own bug reports. Also the fact they have however many open issues is simply insane - if you actually fixed them as soon as they were reported you wouldn't have such a massive backlog, and the same seems to apply to most projects of any size (for example, Optifine has over 2,500 open issues, a significant portion of which are bug reports).
Also, the last comment about mobs growing up? There is also a fix given for that on its own report, which I again used and have verified to work (I also enhanced it by making mobs immune to suffocation damage for one tick after they grow up as they could still take a tick of damage):
There are many more examples of bugs which should have been fixed a decade ago; for example, they have rewritten the rendering engine multiple times (in at least 1.8, 1.15, and 1.17) - yet why are these bugs still a thing?
MC-43968 Ambient occlusion bug on staircase structures
MC-138211 Smooth lighting / ambient occlusion is incorrect (asymmetrical) on south-east and north-west corners
MC-197497 Smooth lighting transition from level 1 to 0 is not smooth
MC-225516 Smooth lighting doesn't work on blocks that emit light
(I'm surprised it took so long for the last one to be reported, it is quite obvious on redstone ore and most have existed since the addition of smooth lighting in Beta 1.3 while the first one appeared in release 1.5, as mentioned by the most recent comment, and worsened in 1.14)
Also, note how long it took for this one to be fixed - 7 years, yet I only had to make a single-line change, again fixing it before it was even reported (the game treated liquids as opaque instead of transparent when rendering smooth lighting, which affects the way it is rendered. In vanilla 1.6.4 there are other blocks, like fences, which also cause artifacts due to being treated as "solid" based on their material):
MC-68129 Smooth lighting doesn't work properly underwater
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Responses are in bold. As much as I appreciate your thoughts, a lot of your disagreements are fundamentally flawed, not to mention rather pessimistic for someone willing to seek out the truth. Now, I know I did say that this thread was all my opinion; I'm completely fine with the game itself moving on from 1.20 if that's so, but I posted all of this for a good reason. People much like me are seeing things in Minecraft that most folks would never see, and they happen to be smart much like me. Trust me, I've spent many years in homeschool learning from my mother, and she would agree with my opinions as well. I'm certainly not saying your replies have absolutely no merit to them, I'm just saying that they have issues that most others wouldn't see here.
Order of the Stone - A mod idea of what Minecraft could've been had it been developed by a team with more expertise; by professional developers and producers.
These are mere opinions, so it's quite surprising to me that you're calling someone else's flawed but placing yours as the "path to truth". What's flawed here is your approach. For someone who's self declaring themself as "smart" (what's with this recurring pattern of declaring your opinion, a subjective thing, as more objectively correct?), it's disheartening.
You can think my opinions themselves aren't correct merely because I don't share in your opinions. That's fine. I definitely don't ever expect anyone to always agree with me. Likewise, I can (and do) think your argument is flawed. And notice I'm saying your approach/argument is flawed, but not your opinions. I don't think your opinions themselves are flawed, because I can recognize that opinions are subjective things and thus aren't really right or wrong, but I think the argument you're making with your opinion is flawed. What you're doing is making a statement that the game should cease development, mostly because it doesn't cater to your opinions of what it "should be". Well, guess what? Everyone has a different opinion on what the game should be. So we seem to be an impasse, no?
The more important part is this. You are failing to substantiate WHY the game should cease development beyond the aforementioned "I think it should be something else", which isn't a good argument because anyone can make it. The rest of the mentioned things are mostly arbitrary padding; like whether Mojang is indie or not, or whether you like triple A games over indie games or not, or whether you "see things" (haha, what!?) in games that others don't, it is all completely arbitrary insofar as reasons to why the game should cease development. And those things seem to mostly be serving as padding to what is a lack of real reasoning to substantiate WHY development should cease. "I think the game should be something else" doesn't suffice. When the majority of the market is speaking in ways that has convinced Mojang it is worth continuing, then that's the way things will go. I think the game should be something different than what it is. I also enjoy what it is, and don't think it should cease development, despite that.
The onus is on YOU to substantiate WHY it should cease development, because you're the one making a rather bold claim with your opinion, and simply saying you find those who disagree with you as flawed is no reasoning in and of itself. Substantiate it. Saying "I disagree" and "my opinion is more right than those who disagree with me" is just about the biggest non-argument there is.
The answer is obvious here, and I called it out already. The game seemingly doesn't cater on your preferences as well as other games do, so the answer is to move on. But you seem unwilling to do that fully, and instead want to see the game cease development in order to satisfy you into moving on.
Ngl this is the most active serious convo I've seen on here yet.
What's the actual argument for stopping development? Having to update worlds and servers? Content bloat?
Updates keep this game alive. No more updates means no more hype.
Aside from the number, 1.20 is also an arbitrary point to stop. It has no feeling of finality to it and many ideas are still planned but not done yet.
That's what I was wondering.
The reasoning seems to be based on an opinion that the game isn't, never was, and seemingly never will be, what someone thinks it should be.