The logic of the commands is similar to the logic I would use in an API. It's all well and good that they want to shift to more efficient means of doing things, but it doesn't necessarily have much to do with API. Rendering using shaders? What's that got to do with easy implementation of new blocks, mobs, and mechanics? I suppose there might be some bizarre mechanic someone wants to do involving light, but every block already has its own light value and I can't imagine a mechanic that requires anything more specific other than colored light. Maybe they want to make it look cool? Some special shader-based system? Going to such great lengths for the minority (in the very beginning) seems ridiculous, especially when you don't need to complete the entire thing all at once.
1.5, as you describe it, is just a texture isolator. It simply gathers together files that had been divided and puts pointers in the code to specific files. 1.6 is just a new launcher (though finding and putting in old versions of the game will take time, it shouldn't take too much time). 1.7 is just a rename of everything (Ctrl+F->replace) and a multiplayer change that does not appear to directly impact the rest of the game (while complicated they could probably hand it off to another team to add into the game whenever it was complete). 1.8 is the only thing that I see in that list that would make updates take a long time (as it did). The majority of these things have to be done, but it should not be taking this long.
So would you call this the same code within commands? Minecraft is programmed in Java, not custom commands that Mojang makes. That class I showed you was just one of the source files for my mod, and it was just the base block class.
The shaders Mojang are moving to are not the same as the shaders seen in SEUS or KUDA, where it makes the game look pretty. Mojang is using shaders to speed the game's rendering up by moving things such as AO to the shaders instead of on the CPU (AO = Smooth Lighting). Moving to shaders is one reason why the huge performance boost seen in 1.8 for some people.
1.7 wasn't just a rename, it reformatted the entire way the game and subsequent mods worked. Instead of referencing blocks using IDs you instead reference them using Strings and instances. And the networking wasn't just multiplayer, it was a COMPLETE redesign of how packeting and networking worked, it redesigned how your client communicates to a server down to how it actually initiates the connection. It was put in place as the old system was very bulky and inefficient, Netty handles things in a cleaner way so they moved over.
Please, don't try to talk code if you don't know code. Everything you said was incorrect.
So would you call this the same code within commands? Minecraft is programmed in Java, not custom commands that Mojang makes. That class I showed you was just one of the source files for my mod, and it was just the base block class.
The shaders Mojang are moving to are not the same as the shaders seen in SEUS or KUDA, where it makes the game look pretty. Mojang is using shaders to speed the game's rendering up by moving things such as AO to the shaders instead of on the CPU (AO = Smooth Lighting). Moving to shaders is one reason why the huge performance boost seen in 1.8 for some people.
1.7 wasn't just a rename, it reformatted the entire way the game and subsequent mods worked. Instead of referencing blocks using IDs you instead reference them using Strings and instances. And the networking wasn't just multiplayer, it was a COMPLETE redesign of how packeting and networking worked, it redesigned how your client communicates to a server down to how it actually initiates the connection. It was put in place as the old system was very bulky and inefficient, Netty handles things in a cleaner way so they moved over.
Please, don't try to talk code if you don't know code. Everything you said was incorrect.
I said the logic was similar. Code is a logical thing. Cause, effect, interrelation, etcetera. I would use a similar logic for basic rules for an API. The code will not look the same as commands do. I feel like I'm stating the obvious. I apologize that you felt the need to state the obvious.
And for others their performance went down the drain. How does any of it help with an API?
I'm basing my responses on what you tell me. The less you try to dumb it down the more I will understand of what the actual difficulty is. Anyways, so they shifted from what could be variables to strings and objects in 1.7. While that would take me maybe a few months on my programming calculator, it would take considerably less time on a computer. Please explain. And while I get that networking was changed and why it was changed, it still seems like a separate thing that's necessary but unrelated to every other portion of the game other than itself. I do not understand how what you said changes anything about my previous response. Please explain.
I do know code to a certain degree. I have more familiarity with it than most random people on the internet. While it can be tedious and all over the place sometimes, it's pretty straightforwards if you understand the logic. The main things I'm not aware of are the limitations of Java and Minecraft code in general, so I don't understand why what seems like a simple process in my head (imagining how the code fits together if I were the one to write it) is limited. Provided you refrain from being condescending, I would like you to help me understand, since you know information that I do not.
I can't believe such a useless thread actually has 3 pages already. I mean, ANYONE who know even the most little thing about making a game would know that you can't just add stuff and send it for people to use it, it takes a lot of time programming, adding new graphics, checking for everything to be right, fixing bugs, because if you knew anything about programming (that you obviously don't) you'd know that every single line of code you add may interfere with other parts of the code, causing unexpected effects. So I wonder, why don't you just stay quiet and wait? It's better not to talk and looking like an ignorant, than saying nonsenses and proving it.
I can't believe such a useless thread actually has 3 pages already. I mean, ANYONE who know even the most little thing about making a game would know that you can't just add stuff and send it for people to use it, it takes a lot of time programming, adding new graphics, checking for everything to be right, fixing bugs, because if you knew anything about programming (that you obviously don't) you'd know that every single line of code you add may interfere with other parts of the code, causing unexpected effects. So I wonder, why don't you just stay quiet and wait? It's better not to talk and looking like an ignorant, than saying nonsenses and proving it.
It's based more around what we know they're capable of and the time-frames they have created expectations for. For example, there is a certain usual expected time for snapshots to be released after a major update. Currently, we are nearly four months over that time. Is it really that unreasonable to expect something based on their past behavior? I see no reason for them to deviate except if they're recoding enormous portions of the game. And it's downright weird of them to do that for the first snapshot, which is usually a gameplay/item-based snapshot.
I said the logic was similar. Code is a logical thing. Cause, effect, interrelation, etcetera. I would use a similar logic for basic rules for an API. The code will not look the same as commands do. I feel like I'm stating the obvious. I apologize that you felt the need to state the obvious.
And for others their performance went down the drain. How does any of it help with an API?
I'm basing my responses on what you tell me. The less you try to dumb it down the more I will understand of what the actual difficulty is. Anyways, so they shifted from what could be variables to strings and objects in 1.7. While that would take me maybe a few months on my programming calculator, it would take considerably less time on a computer. Please explain. And while I get that networking was changed and why it was changed, it still seems like a separate thing that's necessary but unrelated to every other portion of the game other than itself. I do not understand how what you said changes anything about my previous response. Please explain.
I do know code to a certain degree. I have more familiarity with it than most random people on the internet. While it can be tedious and all over the place sometimes, it's pretty straightforwards if you understand the logic. The main things I'm not aware of are the limitations of Java and Minecraft code in general, so I don't understand why what seems like a simple process in my head (imagining how the code fits together if I were the one to write it) is limited. Provided you refrain from being condescending, I would like you to help me understand, since you know information that I do not.
There's about 1400 classes in the entire game, 144 of those are for blocks, 173 for the world management and access portion of the game, and 87 for items. That's 406 total classes, solely for the world, blocks and items, and that isn't even everything that interfaces with block and item identification. Now, Mojang had to manually recode each and every class to work off of the new ID format; they cannot replace things because in most cases they worked with IDs in different ways; some sections of code would check an ID, others would grab the block / item by ID, etc. That and Java handles integers, strings and objects very differently. Tell me how long that would take you, along side the actual writing of the system?
Next, I never said anything about an API. Mojang COMPLETELY redesigned how the game actually renders stuff to the screen to support both native models and shaders. The game went from using hardcoded voxel-based models for blocks, items and entities to JSON-interpreted model "scripts" provided by resource packs. Alongside that they had to fully implement a function shading pipeline that worked with the old and new rendering system (the pipeline was in place by the 1.7.10 update, they had to recode the pipeline a little to support the new renderer for 1.8).
Networking isn't just a principle of how the server knows when a player presses a button, it's how both client and server communicate. From heartbeat packets, to movement packets, to rendering packets, it covers the entire principle of networked communication. Sockets is a Java API which allows for simplistic networking, just like Netty is, but both do it differently and that's why it took them so long to implement the Netty networking API.
Everything is not a simple process that takes a single keyboard shortcut to perform, and you as a programmer should know that. Mojang not only are making changes to the code but are also catering for the loud minority of users who scream for useful updates. Yes, with a team of 20 or so programmers it would take a couple of months or less to implement a new ID system, but add a new rendering engine, supporting shading and user-defined models, a new networking system, refinements to existing code to make way for the modding API supposedly coming, and having to add content that users are asking for, and it takes a while to roll out a simple fix.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
There's about 1400 classes in the entire game, 144 of those are for blocks, 173 for the world management and access portion of the game, and 87 for items. That's 406 total classes, solely for the world, blocks and items, and that isn't even everything that interfaces with block and item identification. Now, Mojang had to manually recode each and every class to work off of the new ID format; they cannot replace things because in most cases they worked with IDs in different ways; some sections of code would check an ID, others would grab the block / item by ID, etc. That and Java handles integers, strings and objects very differently. Tell me how long that would take you, along side the actual writing of the system?
Next, I never said anything about an API. Mojang COMPLETELY redesigned how the game actually renders stuff to the screen to support both native models and shaders. The game went from using hardcoded voxel-based models for blocks, items and entities to JSON-interpreted model "scripts" provided by resource packs. Alongside that they had to fully implement a function shading pipeline that worked with the old and new rendering system (the pipeline was in place by the 1.7.10 update, they had to recode the pipeline a little to support the new renderer for 1.8).
Networking isn't just a principle of how the server knows when a player presses a button, it's how both client and server communicate. From heartbeat packets, to movement packets, to rendering packets, it covers the entire principle of networked communication. Sockets is a Java API which allows for simplistic networking, just like Netty is, but both do it differently and that's why it took them so long to implement the Netty networking API.
Everything is not a simple process that takes a single keyboard shortcut to perform, and you as a programmer should know that. Mojang not only are making changes to the code but are also catering for the loud minority of users who scream for useful updates. Yes, with a team of 20 or so programmers it would take a couple of months or less to implement a new ID system, but add a new rendering engine, supporting shading and user-defined models, a new networking system, refinements to existing code to make way for the modding API supposedly coming, and having to add content that users are asking for, and it takes a while to roll out a simple fix.
I suppose that would take a fairly long time, but mostly because it requires separation of what ids belong in what category of process and tedious doing the same thing over and over again. I imagine that provided everyone figures out the processes required first, then everyone can quickly find all id numbers and begin switching. It should not take more than a couple months at most if everyone knows what they're doing and no one takes a vacation, mostly because of the sheer number of things they have to replace. Any numbers they miss (somehow) can be found doing snapshots, of course. Granted, I don't know how Java handles integers, strings and objects differently enough to be an apparently enormous obstacle. But if Java is a coding language that obeys basic concepts of reason, then it should be self-consistent enough that the same process can be used repeatedly to replace similar situations. In that sense, it really is an easy find-and-replace. It's not doing anything other than switching to logic necessary to comprehend strings in various scenarios and then putting in strings.
I said things about API in the beginning, and that's what I've been sticking to. I don't know where you're going, but to me, them switching from one thing that has widespread uncertain running ability to another thing that has widespread uncertain running ability does not appear to be the most productive use of time.
I'm aware of that much. How integrated into the basic game is networking? The client/server relationship needs to keep track of what the player is doing so that it can delete/add/switch appropriate environmental constructs properly, sure. But is it really so closely related to actual game code that it could not be done independently of everything else?
Haven't you listed all those things as things they did in separate updates? Excepting adding content, of course, but I'd get bored as well. Add another couple weeks for basic blocks and crafting recipes, another couple months for anything more complex.
Still, even with the four months of minimum time, five-six months maximum time that I've reasoned out here (that seems par for the course), how do you explain the recent relatively large gap between update and snapshots? What are they doing over there that's taking so long, other than the vacations? They recoding it from the bottom up for some reason?
There really shouldn't be any debate about if mojang is lazy. When the height map was changed from 128 to 256 the first released version of the update would crash if any player built up to the top of the map. They fixed the bug within a day, but that means they released a feature (it wasn't even a snaphot, it was a full version, i think 1.2) that increased the height map without play testing it at all. They never even got in game and went to the top of the map to make sure it worked. They just released the update without a care if it worked. Now, that doesn't mean minecraft is a bad game, it just means mojang is lazy. And then every update is just taking mod code and putting it in the game. I don't know why that potioncraft guy got made fun of so much, they probably did take his mod and make it worse. I'm not really against taking the best parts of mods and putting them in vanilla, I just don't know what mojang actually does besides play test the mods they put in the game which they apparently don't do looking at the height map thing...
Still, something like minecraft was going to be made with how computer's advanced, it didn't really take much ingenuity to make, it just surfaced when it became doable. Too bad better people didn't make the game, but its still a good game. Mojang did one very important thing right: let the community earn revenue off of creations in their game. That was a genius thing to do at the time and is why the game is as successful as it is today.
Hopefully microsoft recognizes this and continues to let the community do what they want. This whole merging platforms article that was on here recently is scary. Minecraft is an awful game on everything except pc.
This is going on a tangent, basically good game, lazy company.
There really shouldn't be any debate about if mojang is lazy. When the height map was changed from 128 to 256 the first released version of the update would crash if any player built up to the top of the map. They fixed the bug within a day, but that means they released a feature (it wasn't even a snaphot, it was a full version, i think 1.2) that increased the height map without play testing it at all. They never even got in game and went to the top of the map to make sure it worked. They just released the update without a care if it worked.
What reason would they have to believe there would be a problem with building up there? You wouldn't test something you had no idea would remotely cause a problem. They most likely tested building up to and past 129 and it worked, so what reason would they have to think building at 254 would be any different? Who's to say they didn't build up there and it worked fine? Understand that game development environments can perform different than user client environments. They likely do all their testing on the same computer they work on.
Also note, as evident with 1.8+, a user's hardware configuration can also have an impact on performance seemingly randomly. The changes may work 100% perfectly on all their systems at Mojang, so naturally they have no reason to believe anything is wrong, till the game hits millions upon millions of different configurations out in the public. Perfect testing of an open world game is near impossible.
Mojang may have some sloppy code, but I would equate that to their employees being mostly freelance, self taught, indie programmers rather than professionally educated, spent 4 years in school for software engineering, programmers.
Humans are not perfect, mistakes will be made. The important thing is that they fix the mistakes.
Rollback Post to RevisionRollBack
Cast aside your festive doylaks: dragon stuff is about to happen.
Multiplayer is lonely once you understand how it actually works.
What reason would they have to believe there would be a problem with building up there? You wouldn't test something you had no idea would remotely cause a problem. They most likely tested building up to and past 129 and it worked, so what reason would they have to think building at 254 would be any different? Who's to say they didn't build up there and it worked fine? Understand that game development environments can perform different than user client environments. They likely do all their testing on the same computer they work on.
Also note, as evident with 1.8+, a user's hardware configuration can also have an impact on performance seemingly randomly. The changes may work 100% perfectly on all their systems at Mojang, so naturally they have no reason to believe anything is wrong, till the game hits millions upon millions of different configurations out in the public. Perfect testing of an open world game is near impossible.
Mojang may have some sloppy code, but I would equate that to their employees being mostly freelance, self taught, indie programmers rather than professionally educated, spent 4 years in school for software engineering, programmers.
Humans are not perfect, mistakes will be made. The important thing is that they fix the mistakes.
Okay, so you add a feature to a game but don't actually test if it works before final release, that makes sense. And it wasn't a performance issue, it crashed the game for everybody. If they only built up to 129 that is still lazy. That would the same as adding redstone and only testing if it lights up for 1 block ignoring the 16 block limit it should have. Adding a height limit and not even making sure it doesn't crash the game when people go up there is a lazy mistake. It really was an embarrassment which is why they fixed it so quickly and don't even list 1.2 as a playable version. Every other update has a .0 but 1.2 just starts with 1.2.1, that's why. 1.2 isn't even listed in the launcher, that's how bad of a release it was due to its poor testing.
Okay, so you add a feature to a game but don't actually test if it works before final release, that makes sense. And it wasn't a performance issue, it crashed the game for everybody. If they only built up to 129 that is still lazy. That would the same as adding redstone and only testing if it lights up for 1 block ignoring the 16 block limit it should have. Adding a height limit and not even making sure it doesn't crash the game when people go up there is a lazy mistake. It really was an embarrassment which is why they fixed it so quickly and don't even list 1.2 as a playable version. Every other update has a .0 but 1.2 just starts with 1.2.1, that's why. 1.2 isn't even listed in the launcher, that's how bad of a release it was due to its poor testing.
If it worked past 129, why bother going all the way up? Basic logic says it should be the same result all the way up.
Perhaps it worked for their initial height change tests up to 254, but a later change unknowingly caused it to crash. Nothing would have lead them to even think to test the height a second time. Programming can be very touchy. One change can unknowingly cause problems elsewhere.
Yes it may have crashed the game for everyone, but how many people actually build at max height consistently? Probably not many, so in reality, it wasn't a HUGE deal. Those that it effected were probably people rushing to see what max height looked like upon initial release, not people who were actually building up that high for a purpose. And the fact that it was fixed quickly means they acknowledged they screwed up.
Further indication that they have improved overall, snapshots are a thing, so they can get the tests to the masses so they can see how the game performs on millions of computers vs their internal work computers. Instead of releasing updates every week, they actually take time and fix as much as they can. 1.8 was the most comprehensive overhaul of the game with a bug fix list longer then the entire 1.0 release log.
Understand the situation they work under. A bunch of self taught freelancers put under a microscope of the masses. Naturally there will be mistakes found, and pointing them out helps, but bashing them and calling them lazy just makes things worse for them. Who would have the motivation to do a good job when people are constantly yelling at them and calling them lazy and whatnot. They are people, not machines. Mistakes will be made, and as long as they fix them, that is far from lazy in my book.
On an unrelated note, I am sitting at work avoiding doing anything and playing Starbound... now THAT is being lazy.
Rollback Post to RevisionRollBack
Cast aside your festive doylaks: dragon stuff is about to happen.
Multiplayer is lonely once you understand how it actually works.
Look, I don't have time to argue with you about this back and forward. The updates are taking so long because the changes they're making are so drastic. If you think that they're being lazy, be my guest, learn GLSL, Netty and all the other APIs and you attempt to do the same things with Minecraft as they are doing. The point is it is recoding from the ground up, it isn't taking parts of code and replacing it with newer code, it's completely deleting the entire classes and rewriting the engine completely. They can't just wait till a snapshot rolls out to patch an ID they missed, this is where you shouldn't be arguing because you know nothing about Java or the game itself code-wise. If they miss an ID, the game crashes. That simple.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Still, even with the four months of minimum time, five-six months maximum time that I've reasoned out here (that seems par for the course), how do you explain the recent relatively large gap between update and snapshots? What are they doing over there that's taking so long, other than the vacations? They recoding it from the bottom up for some reason?
Well one thing that's already been mentioned is that they plan on moving over to solely shaders for rendering in 1.9. They've made some progress towards that end in 1.8 but it's still a long way off. GL calls are still widely used internally and switching to shaders will still involve a massive amount of work. More than just the 'find and replace' you keep talking about.
There's also mention of changing entity renderering to use models from resourcepacks as well that, having seen the code myself, I would be very impressed if they manage to get that working this year. There is just so much abstracting they have to do for that, not just models but also all the animations, held items, wearables, different render passes (used by the enderman to get their eyes to glow). Not to mention the models or the textures (or both) have to change depending on the state of the entity, like how sheep have coloured wool or no wool, villagers change clothes, zombies can have villager heads, endermen open their mouths, and the enderdragon I don't even.
I'd also like to add that 'find and replace' is not an adequate method for editing code. Any self respecting programmer would never use that. It's not context sensitive and just one misplaced or ill thought replacement could mean hours of work trying to fix the resulting mess, or worse one of the changes it makes doesn't cause any immediate problems but then a bug arises weeks later and you have to hunt it down.
Rollback Post to RevisionRollBack
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
If it worked past 129, why bother going all the way up? Basic logic says it should be the same result all the way up.
Perhaps it worked for their initial height change tests up to 254, but a later change unknowingly caused it to crash. Nothing would have lead them to even think to test the height a second time. Programming can be very touchy. One change can unknowingly cause problems elsewhere.
Yes it may have crashed the game for everyone, but how many people actually build at max height consistently? Probably not many, so in reality, it wasn't a HUGE deal. Those that it effected were probably people rushing to see what max height looked like upon initial release, not people who were actually building up that high for a purpose. And the fact that it was fixed quickly means they acknowledged they screwed up.
Further indication that they have improved overall, snapshots are a thing, so they can get the tests to the masses so they can see how the game performs on millions of computers vs their internal work computers. Instead of releasing updates every week, they actually take time and fix as much as they can. 1.8 was the most comprehensive overhaul of the game with a bug fix list longer then the entire 1.0 release log.
Understand the situation they work under. A bunch of self taught freelancers put under a microscope of the masses. Naturally there will be mistakes found, and pointing them out helps, but bashing them and calling them lazy just makes things worse for them. Who would have the motivation to do a good job when people are constantly yelling at them and calling them lazy and whatnot. They are people, not machines. Mistakes will be made, and as long as they fix them, that is far from lazy in my book.
On an unrelated note, I am sitting at work avoiding doing anything and playing Starbound... now THAT is being lazy.
The height limit was the main feature of the update and it crashed the game. It is the laziest thing I've ever seen in any game indie or not. People build up to 256 all the time, maybe not in survival, but in creative it is very common. They didn't really acknowledge they screwed up. If you look at it now its almost as if they tried to cover it up by removing evidence of its existence from the launcher. After that they made every release a "snapshot" so if it has bugs they can claim its an unfinished product and not look as bad, its not really better.
To be totally honest, I could hardly care less if they are or are not lazy.
However, I do think they could have better focus... for the most part most of my friends have performance reductions in each consecutive update, which I think is the real problem that Mojang has right now. Perhaps they are trying to rewrite things to fix it, which is a nice idea, but thus far it doesn't seem to be working.Sure some people get better performance, but most people I know will not even update to 1.8 because the game is simply unplayable.
Now, the reason they seem lazy is because they are not adding features en mass, which is probably a good thing, because mods have these features if people want them. However, new features is WAY easier to work on than bugfixing/performance boosting. I feel that is Mojang wanted to, they could release a comparable amount of new features to the last 5 updates within a 6 month period. Adding new content is simply not that hard. That said, fixing the new content is harder, more time consuming, and far less rewarding (personal experience). So I in some ways admire the direction Mojang is trying to go, but I really don't think they are accomplishing what they are trying to do well enough.
All that said. They are trying to work on the only aspect of the game that actually maters anymore, namely, making it perform better, and be more user/modder friendly. Everything else they do is pretty useless in my opinion. Additionally, new update just complicate things for modders such as myself, as well as server owners. So basically the updates should be large and make a big difference. In all honesty, I think it would have been better for them to not even have released 1.8 by now, because it probably would just be better to update everything at once.
[just my two cents]
Anyways, cheers, and you all have a wonderful day.
The height limit was the main feature of the update and it crashed the game. It is the laziest thing I've ever seen in any game indie or not. People build up to 256 all the time, maybe not in survival, but in creative it is very common. They didn't really acknowledge they screwed up. If you look at it now its almost as if they tried to cover it up by removing evidence of its existence from the launcher. After that they made every release a "snapshot" so if it has bugs they can claim its an unfinished product and not look as bad, its not really better.
How is that a bad thing? They fixed the problem quickly and made sure no one can use that version of the game because it has that problem. This is a GOOD thing. Just because they didn't publicly say "Hey guys we screwed something up.", they went ahead and fixed it and released it. There was no need for anything to be said, they just did what needed to be done.
Letting people know its a snapshot, which requires you to opt-in, is good for them. They can publicly test out their game changes on far more system than they could internally. This improves the quality of each official release as opposed to back in Alpha or Beta when released were unorganized and hap-hazard. They have improved their QA a crap load since then.
And if this qualifies as the laziest thing you've ever seen, then clearly you don't know your game history. ET anyone?
So, as I've stated before, I don't claim to know Minecraft's code. For that matter, I hate coding in Java (and haven't since 2004). But I AM a developer for a mid-sized software company that provides a core product, on which add-on modules rely. My role; supporting and maintaining some of the legacy add-on modules so they remain functional against an ever-evolving core product. So, my 2 cents....
First... (Charles) Finley's law: If you change something, you've CHANGED something. Sounds like a cute little 'so what' statement; but it's something that every coder has to understand and be aware of on a fundamental level. Seriously.. most non-coders just can't get it, no matter how much they claim they 'do'.
Java is Object Oriented. Object classes/functions aren't something you simply change on the fly. The entire library of classes has to be scoured for references, verified for data type handling, and (ideally) regression-tested. And it's not uncommon (although ill-advised) that object references are made without being properly documented in the target class (again, it's been 10 years for me; I'm a bit rusty on Java, so you Java-monkeys, please be kind....). I can't tell you how many times I've had to go back to the core developers and inform them of an unexpected impact that resulted from what they thought was an innocuous change. Long made short, what the average Joe thinks should have been a quick update sometimes involves an exorbitant amount of resources to vet out the impact across the board. As JC(? I'm on page 4 now....) said.. miss one ID, and the game crashes. Unless you know the specific code that they are working on, and have knowledge of every single change, you cannot justifiably claim 'laziness' just because you are ignorant of the efforts taking place (that's not an insult....).
On a side note.... maybe now Mojang can gain access to Microsoft's test farms. Just saying; public snapshot testing helps with game mechanic/feature testing, but having access to a test farm can provide very useful historical bench-marking data as well (over time, of course).
As for their coders' level of competence; give 'em a break already. You typically don't see professional code-monkeys complaining. Why? Because we understand what it takes to produce and maintain a stable product. Yes, they've flubbed pretty badly in the past; but have you seen the internal communication that took place prior to, during and after the fallout of the height change update? What I'm getting at, is that as much as we all try to avoid them, mistakes do happen. And I doubt they excluded that update to 'hide their shame'. The issue was so easily encountered, the version was ultimately unstable. To leave it as a published version (as opposed to retracted), is what would be lazy. If anything, they did the responsible thing in removing access to a faulty product. Very few companies can boast that they've never released a product revision that wasn't in some way capable of producing a 'critical failure'.
To be totally honest, I could hardly care less if they are or are not lazy.
However, I do think they could have better focus... for the most part most of my friends have performance reductions in each consecutive update, which I think is the real problem that Mojang has right now. Perhaps they are trying to rewrite things to fix it, which is a nice idea, but thus far it doesn't seem to be working.Sure some people get better performance, but most people I know will not even update to 1.8 because the game is simply unplayable.
Now, the reason they seem lazy is because they are not adding features en mass, which is probably a good thing, because mods have these features if people want them. However, new features is WAY easier to work on than bugfixing/performance boosting. I feel that is Mojang wanted to, they could release a comparable amount of new features to the last 5 updates within a 6 month period. Adding new content is simply not that hard. That said, fixing the new content is harder, more time consuming, and far less rewarding (personal experience). So I in some ways admire the direction Mojang is trying to go, but I really don't think they are accomplishing what they are trying to do well enough.
All that said. They are trying to work on the only aspect of the game that actually maters anymore, namely, making it perform better, and be more user/modder friendly. Everything else they do is pretty useless in my opinion. Additionally, new update just complicate things for modders such as myself, as well as server owners. So basically the updates should be large and make a big difference. In all honesty, I think it would have been better for them to not even have released 1.8 by now, because it probably would just be better to update everything at once.
[just my two cents]
Anyways, cheers, and you all have a wonderful day.
To explain why performance is slowly decreasing each update, AFAIK it's mainly due to the fact that they're cramming so much content into a system that was coded over 2 years ago. Back 2 years ago the game only had so much, the engine has relatively remained the same, but more and more content is being added. Hence why they're rewriting large portions of the game now; they're making the game able to support the new content.
As far as I know, the main reason why 1.8 is laggy for a lot of people is because of the fact that the game overall is more demanding the run graphically. While the shaders seen in Minecraft are meant to make it run smoother, on lower-end computers (which a LOT of users play it on low-end systems), it makes the game more intensive which actually increases lag. Then again, I could be wrong and it could actually be something with the pipeline, but that's my opinion. Guess we're going to have to wait until 1.9.
Not meaning to poke a stick at you so-to-speak, just explaining why performance is slowly getting worse each update.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
To explain why performance is slowly decreasing each update, AFAIK it's mainly due to the fact that they're cramming so much content into a system that was coded over 2 years ago. Back 2 years ago the game only had so much, the engine has relatively remained the same, but more and more content is being added. Hence why they're rewriting large portions of the game now; they're making the game able to support the new content.
As far as I know, the main reason why 1.8 is laggy for a lot of people is because of the fact that the game overall is more demanding the run graphically. While the shaders seen in Minecraft are meant to make it run smoother, on lower-end computers (which a LOT of users play it on low-end systems), it makes the game more intensive which actually increases lag. Then again, I could be wrong and it could actually be something with the pipeline, but that's my opinion. Guess we're going to have to wait until 1.9.
Not meaning to poke a stick at you so-to-speak, just explaining why performance is slowly getting worse each update.
What you say certainly makes sense, and it is somewhat logical. However, I think Mojang needs to be more concerned about this issue than they currently are. Or rather, I was noting the fact that what they are trying to do to fix this issue is not working as fast as the issue is propagating.
But no offense (or any such thing) taken from your comment, and thanks for the clarity that your opinion gives
So would you call this the same code within commands? Minecraft is programmed in Java, not custom commands that Mojang makes. That class I showed you was just one of the source files for my mod, and it was just the base block class.
The shaders Mojang are moving to are not the same as the shaders seen in SEUS or KUDA, where it makes the game look pretty. Mojang is using shaders to speed the game's rendering up by moving things such as AO to the shaders instead of on the CPU (AO = Smooth Lighting). Moving to shaders is one reason why the huge performance boost seen in 1.8 for some people.
1.7 wasn't just a rename, it reformatted the entire way the game and subsequent mods worked. Instead of referencing blocks using IDs you instead reference them using Strings and instances. And the networking wasn't just multiplayer, it was a COMPLETE redesign of how packeting and networking worked, it redesigned how your client communicates to a server down to how it actually initiates the connection. It was put in place as the old system was very bulky and inefficient, Netty handles things in a cleaner way so they moved over.
Please, don't try to talk code if you don't know code. Everything you said was incorrect.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
I said the logic was similar. Code is a logical thing. Cause, effect, interrelation, etcetera. I would use a similar logic for basic rules for an API. The code will not look the same as commands do. I feel like I'm stating the obvious. I apologize that you felt the need to state the obvious.
And for others their performance went down the drain. How does any of it help with an API?
I'm basing my responses on what you tell me. The less you try to dumb it down the more I will understand of what the actual difficulty is. Anyways, so they shifted from what could be variables to strings and objects in 1.7. While that would take me maybe a few months on my programming calculator, it would take considerably less time on a computer. Please explain. And while I get that networking was changed and why it was changed, it still seems like a separate thing that's necessary but unrelated to every other portion of the game other than itself. I do not understand how what you said changes anything about my previous response. Please explain.
I do know code to a certain degree. I have more familiarity with it than most random people on the internet. While it can be tedious and all over the place sometimes, it's pretty straightforwards if you understand the logic. The main things I'm not aware of are the limitations of Java and Minecraft code in general, so I don't understand why what seems like a simple process in my head (imagining how the code fits together if I were the one to write it) is limited. Provided you refrain from being condescending, I would like you to help me understand, since you know information that I do not.
If you are planning to make a suggestion, please read this.
If you want to know more, you can read this.
For those who complain about post-Beta generation, you might want to see this.
I can't believe such a useless thread actually has 3 pages already. I mean, ANYONE who know even the most little thing about making a game would know that you can't just add stuff and send it for people to use it, it takes a lot of time programming, adding new graphics, checking for everything to be right, fixing bugs, because if you knew anything about programming (that you obviously don't) you'd know that every single line of code you add may interfere with other parts of the code, causing unexpected effects. So I wonder, why don't you just stay quiet and wait? It's better not to talk and looking like an ignorant, than saying nonsenses and proving it.
It's based more around what we know they're capable of and the time-frames they have created expectations for. For example, there is a certain usual expected time for snapshots to be released after a major update. Currently, we are nearly four months over that time. Is it really that unreasonable to expect something based on their past behavior? I see no reason for them to deviate except if they're recoding enormous portions of the game. And it's downright weird of them to do that for the first snapshot, which is usually a gameplay/item-based snapshot.
If you are planning to make a suggestion, please read this.
If you want to know more, you can read this.
For those who complain about post-Beta generation, you might want to see this.
There's about 1400 classes in the entire game, 144 of those are for blocks, 173 for the world management and access portion of the game, and 87 for items. That's 406 total classes, solely for the world, blocks and items, and that isn't even everything that interfaces with block and item identification. Now, Mojang had to manually recode each and every class to work off of the new ID format; they cannot replace things because in most cases they worked with IDs in different ways; some sections of code would check an ID, others would grab the block / item by ID, etc. That and Java handles integers, strings and objects very differently. Tell me how long that would take you, along side the actual writing of the system?
Next, I never said anything about an API. Mojang COMPLETELY redesigned how the game actually renders stuff to the screen to support both native models and shaders. The game went from using hardcoded voxel-based models for blocks, items and entities to JSON-interpreted model "scripts" provided by resource packs. Alongside that they had to fully implement a function shading pipeline that worked with the old and new rendering system (the pipeline was in place by the 1.7.10 update, they had to recode the pipeline a little to support the new renderer for 1.8).
Networking isn't just a principle of how the server knows when a player presses a button, it's how both client and server communicate. From heartbeat packets, to movement packets, to rendering packets, it covers the entire principle of networked communication. Sockets is a Java API which allows for simplistic networking, just like Netty is, but both do it differently and that's why it took them so long to implement the Netty networking API.
Everything is not a simple process that takes a single keyboard shortcut to perform, and you as a programmer should know that. Mojang not only are making changes to the code but are also catering for the loud minority of users who scream for useful updates. Yes, with a team of 20 or so programmers it would take a couple of months or less to implement a new ID system, but add a new rendering engine, supporting shading and user-defined models, a new networking system, refinements to existing code to make way for the modding API supposedly coming, and having to add content that users are asking for, and it takes a while to roll out a simple fix.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
I suppose that would take a fairly long time, but mostly because it requires separation of what ids belong in what category of process and tedious doing the same thing over and over again. I imagine that provided everyone figures out the processes required first, then everyone can quickly find all id numbers and begin switching. It should not take more than a couple months at most if everyone knows what they're doing and no one takes a vacation, mostly because of the sheer number of things they have to replace. Any numbers they miss (somehow) can be found doing snapshots, of course. Granted, I don't know how Java handles integers, strings and objects differently enough to be an apparently enormous obstacle. But if Java is a coding language that obeys basic concepts of reason, then it should be self-consistent enough that the same process can be used repeatedly to replace similar situations. In that sense, it really is an easy find-and-replace. It's not doing anything other than switching to logic necessary to comprehend strings in various scenarios and then putting in strings.
I said things about API in the beginning, and that's what I've been sticking to. I don't know where you're going, but to me, them switching from one thing that has widespread uncertain running ability to another thing that has widespread uncertain running ability does not appear to be the most productive use of time.
I'm aware of that much. How integrated into the basic game is networking? The client/server relationship needs to keep track of what the player is doing so that it can delete/add/switch appropriate environmental constructs properly, sure. But is it really so closely related to actual game code that it could not be done independently of everything else?
Haven't you listed all those things as things they did in separate updates? Excepting adding content, of course, but I'd get bored as well. Add another couple weeks for basic blocks and crafting recipes, another couple months for anything more complex.
Still, even with the four months of minimum time, five-six months maximum time that I've reasoned out here (that seems par for the course), how do you explain the recent relatively large gap between update and snapshots? What are they doing over there that's taking so long, other than the vacations? They recoding it from the bottom up for some reason?
If you are planning to make a suggestion, please read this.
If you want to know more, you can read this.
For those who complain about post-Beta generation, you might want to see this.
They update Minecraft: you don't like it, whine about it
They don't: you don't like it, whine about it
Minecraft community is so ungrateful I'm surprised they are still updating the game for YOU.
Miner's nightmare preset
Miner's nightmare preset (original terrain)
Killing the Ender Dragon, no damage (no armor/potions/enchantments/pumpkin)
There really shouldn't be any debate about if mojang is lazy. When the height map was changed from 128 to 256 the first released version of the update would crash if any player built up to the top of the map. They fixed the bug within a day, but that means they released a feature (it wasn't even a snaphot, it was a full version, i think 1.2) that increased the height map without play testing it at all. They never even got in game and went to the top of the map to make sure it worked. They just released the update without a care if it worked. Now, that doesn't mean minecraft is a bad game, it just means mojang is lazy. And then every update is just taking mod code and putting it in the game. I don't know why that potioncraft guy got made fun of so much, they probably did take his mod and make it worse. I'm not really against taking the best parts of mods and putting them in vanilla, I just don't know what mojang actually does besides play test the mods they put in the game which they apparently don't do looking at the height map thing...
Still, something like minecraft was going to be made with how computer's advanced, it didn't really take much ingenuity to make, it just surfaced when it became doable. Too bad better people didn't make the game, but its still a good game. Mojang did one very important thing right: let the community earn revenue off of creations in their game. That was a genius thing to do at the time and is why the game is as successful as it is today.
Hopefully microsoft recognizes this and continues to let the community do what they want. This whole merging platforms article that was on here recently is scary. Minecraft is an awful game on everything except pc.
This is going on a tangent, basically good game, lazy company.
What reason would they have to believe there would be a problem with building up there? You wouldn't test something you had no idea would remotely cause a problem. They most likely tested building up to and past 129 and it worked, so what reason would they have to think building at 254 would be any different? Who's to say they didn't build up there and it worked fine? Understand that game development environments can perform different than user client environments. They likely do all their testing on the same computer they work on.
Also note, as evident with 1.8+, a user's hardware configuration can also have an impact on performance seemingly randomly. The changes may work 100% perfectly on all their systems at Mojang, so naturally they have no reason to believe anything is wrong, till the game hits millions upon millions of different configurations out in the public. Perfect testing of an open world game is near impossible.
Mojang may have some sloppy code, but I would equate that to their employees being mostly freelance, self taught, indie programmers rather than professionally educated, spent 4 years in school for software engineering, programmers.
Humans are not perfect, mistakes will be made. The important thing is that they fix the mistakes.
Cast aside your festive doylaks: dragon stuff is about to happen.
Multiplayer is lonely once you understand how it actually works.
Alpha 1.0.4
Okay, so you add a feature to a game but don't actually test if it works before final release, that makes sense. And it wasn't a performance issue, it crashed the game for everybody. If they only built up to 129 that is still lazy. That would the same as adding redstone and only testing if it lights up for 1 block ignoring the 16 block limit it should have. Adding a height limit and not even making sure it doesn't crash the game when people go up there is a lazy mistake. It really was an embarrassment which is why they fixed it so quickly and don't even list 1.2 as a playable version. Every other update has a .0 but 1.2 just starts with 1.2.1, that's why. 1.2 isn't even listed in the launcher, that's how bad of a release it was due to its poor testing.
If it worked past 129, why bother going all the way up? Basic logic says it should be the same result all the way up.
Perhaps it worked for their initial height change tests up to 254, but a later change unknowingly caused it to crash. Nothing would have lead them to even think to test the height a second time. Programming can be very touchy. One change can unknowingly cause problems elsewhere.
Yes it may have crashed the game for everyone, but how many people actually build at max height consistently? Probably not many, so in reality, it wasn't a HUGE deal. Those that it effected were probably people rushing to see what max height looked like upon initial release, not people who were actually building up that high for a purpose. And the fact that it was fixed quickly means they acknowledged they screwed up.
Further indication that they have improved overall, snapshots are a thing, so they can get the tests to the masses so they can see how the game performs on millions of computers vs their internal work computers. Instead of releasing updates every week, they actually take time and fix as much as they can. 1.8 was the most comprehensive overhaul of the game with a bug fix list longer then the entire 1.0 release log.
Understand the situation they work under. A bunch of self taught freelancers put under a microscope of the masses. Naturally there will be mistakes found, and pointing them out helps, but bashing them and calling them lazy just makes things worse for them. Who would have the motivation to do a good job when people are constantly yelling at them and calling them lazy and whatnot. They are people, not machines. Mistakes will be made, and as long as they fix them, that is far from lazy in my book.
On an unrelated note, I am sitting at work avoiding doing anything and playing Starbound... now THAT is being lazy.
Cast aside your festive doylaks: dragon stuff is about to happen.
Multiplayer is lonely once you understand how it actually works.
Alpha 1.0.4
Look, I don't have time to argue with you about this back and forward. The updates are taking so long because the changes they're making are so drastic. If you think that they're being lazy, be my guest, learn GLSL, Netty and all the other APIs and you attempt to do the same things with Minecraft as they are doing. The point is it is recoding from the ground up, it isn't taking parts of code and replacing it with newer code, it's completely deleting the entire classes and rewriting the engine completely. They can't just wait till a snapshot rolls out to patch an ID they missed, this is where you shouldn't be arguing because you know nothing about Java or the game itself code-wise. If they miss an ID, the game crashes. That simple.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Well one thing that's already been mentioned is that they plan on moving over to solely shaders for rendering in 1.9. They've made some progress towards that end in 1.8 but it's still a long way off. GL calls are still widely used internally and switching to shaders will still involve a massive amount of work. More than just the 'find and replace' you keep talking about.
There's also mention of changing entity renderering to use models from resourcepacks as well that, having seen the code myself, I would be very impressed if they manage to get that working this year. There is just so much abstracting they have to do for that, not just models but also all the animations, held items, wearables, different render passes (used by the enderman to get their eyes to glow). Not to mention the models or the textures (or both) have to change depending on the state of the entity, like how sheep have coloured wool or no wool, villagers change clothes, zombies can have villager heads, endermen open their mouths, and the enderdragon I don't even.
I'd also like to add that 'find and replace' is not an adequate method for editing code. Any self respecting programmer would never use that. It's not context sensitive and just one misplaced or ill thought replacement could mean hours of work trying to fix the resulting mess, or worse one of the changes it makes doesn't cause any immediate problems but then a bug arises weeks later and you have to hunt it down.
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
The height limit was the main feature of the update and it crashed the game. It is the laziest thing I've ever seen in any game indie or not. People build up to 256 all the time, maybe not in survival, but in creative it is very common. They didn't really acknowledge they screwed up. If you look at it now its almost as if they tried to cover it up by removing evidence of its existence from the launcher. After that they made every release a "snapshot" so if it has bugs they can claim its an unfinished product and not look as bad, its not really better.
To be totally honest, I could hardly care less if they are or are not lazy.
However, I do think they could have better focus... for the most part most of my friends have performance reductions in each consecutive update, which I think is the real problem that Mojang has right now. Perhaps they are trying to rewrite things to fix it, which is a nice idea, but thus far it doesn't seem to be working.Sure some people get better performance, but most people I know will not even update to 1.8 because the game is simply unplayable.
Now, the reason they seem lazy is because they are not adding features en mass, which is probably a good thing, because mods have these features if people want them. However, new features is WAY easier to work on than bugfixing/performance boosting. I feel that is Mojang wanted to, they could release a comparable amount of new features to the last 5 updates within a 6 month period. Adding new content is simply not that hard. That said, fixing the new content is harder, more time consuming, and far less rewarding (personal experience). So I in some ways admire the direction Mojang is trying to go, but I really don't think they are accomplishing what they are trying to do well enough.
All that said. They are trying to work on the only aspect of the game that actually maters anymore, namely, making it perform better, and be more user/modder friendly. Everything else they do is pretty useless in my opinion. Additionally, new update just complicate things for modders such as myself, as well as server owners. So basically the updates should be large and make a big difference. In all honesty, I think it would have been better for them to not even have released 1.8 by now, because it probably would just be better to update everything at once.
[just my two cents]
Anyways, cheers, and you all have a wonderful day.
I think because he has a lot of money.
How is that a bad thing? They fixed the problem quickly and made sure no one can use that version of the game because it has that problem. This is a GOOD thing. Just because they didn't publicly say "Hey guys we screwed something up.", they went ahead and fixed it and released it. There was no need for anything to be said, they just did what needed to be done.
Letting people know its a snapshot, which requires you to opt-in, is good for them. They can publicly test out their game changes on far more system than they could internally. This improves the quality of each official release as opposed to back in Alpha or Beta when released were unorganized and hap-hazard. They have improved their QA a crap load since then.
And if this qualifies as the laziest thing you've ever seen, then clearly you don't know your game history. ET anyone?
Cast aside your festive doylaks: dragon stuff is about to happen.
Multiplayer is lonely once you understand how it actually works.
Alpha 1.0.4
My turn....
So, as I've stated before, I don't claim to know Minecraft's code. For that matter, I hate coding in Java (and haven't since 2004). But I AM a developer for a mid-sized software company that provides a core product, on which add-on modules rely. My role; supporting and maintaining some of the legacy add-on modules so they remain functional against an ever-evolving core product. So, my 2 cents....
First... (Charles) Finley's law: If you change something, you've CHANGED something. Sounds like a cute little 'so what' statement; but it's something that every coder has to understand and be aware of on a fundamental level. Seriously.. most non-coders just can't get it, no matter how much they claim they 'do'.
Java is Object Oriented. Object classes/functions aren't something you simply change on the fly. The entire library of classes has to be scoured for references, verified for data type handling, and (ideally) regression-tested. And it's not uncommon (although ill-advised) that object references are made without being properly documented in the target class (again, it's been 10 years for me; I'm a bit rusty on Java, so you Java-monkeys, please be kind....). I can't tell you how many times I've had to go back to the core developers and inform them of an unexpected impact that resulted from what they thought was an innocuous change. Long made short, what the average Joe thinks should have been a quick update sometimes involves an exorbitant amount of resources to vet out the impact across the board. As JC(? I'm on page 4 now....) said.. miss one ID, and the game crashes. Unless you know the specific code that they are working on, and have knowledge of every single change, you cannot justifiably claim 'laziness' just because you are ignorant of the efforts taking place (that's not an insult....).
On a side note.... maybe now Mojang can gain access to Microsoft's test farms.
Just saying; public snapshot testing helps with game mechanic/feature testing, but having access to a test farm can provide very useful historical bench-marking data as well (over time, of course).
As for their coders' level of competence; give 'em a break already. You typically don't see professional code-monkeys complaining. Why? Because we understand what it takes to produce and maintain a stable product. Yes, they've flubbed pretty badly in the past; but have you seen the internal communication that took place prior to, during and after the fallout of the height change update? What I'm getting at, is that as much as we all try to avoid them, mistakes do happen. And I doubt they excluded that update to 'hide their shame'. The issue was so easily encountered, the version was ultimately unstable. To leave it as a published version (as opposed to retracted), is what would be lazy. If anything, they did the responsible thing in removing access to a faulty product. Very few companies can boast that they've never released a product revision that wasn't in some way capable of producing a 'critical failure'.
To explain why performance is slowly decreasing each update, AFAIK it's mainly due to the fact that they're cramming so much content into a system that was coded over 2 years ago. Back 2 years ago the game only had so much, the engine has relatively remained the same, but more and more content is being added. Hence why they're rewriting large portions of the game now; they're making the game able to support the new content.
As far as I know, the main reason why 1.8 is laggy for a lot of people is because of the fact that the game overall is more demanding the run graphically. While the shaders seen in Minecraft are meant to make it run smoother, on lower-end computers (which a LOT of users play it on low-end systems), it makes the game more intensive which actually increases lag. Then again, I could be wrong and it could actually be something with the pipeline, but that's my opinion. Guess we're going to have to wait until 1.9.
Not meaning to poke a stick at you so-to-speak, just explaining why performance is slowly getting worse each update.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
What you say certainly makes sense, and it is somewhat logical. However, I think Mojang needs to be more concerned about this issue than they currently are. Or rather, I was noting the fact that what they are trying to do to fix this issue is not working as fast as the issue is propagating.
But no offense (or any such thing) taken from your comment, and thanks for the clarity that your opinion gives