Before I begin, I wish to point out that this is not designed to be a rant. It is designed to provide a look into how I see the modding scene as it is today, and why I am nervous about it's future. With that out of the way, let's begin.
First, a little background. I'm a modder. I have coded numerous mods, and helped out on a few others. My first experience with modding was a horrible copy-pasta mod for 1.6 that was never released. I really came into modding using version 1.7.10. Safe to say, I've been doing it a while.
As any modder will tell you, version updates are a part of a mods life. Those that don't update wither, and all but the strongest will die under the weight of newer mods on newer versions. Case in point: currently, there are no servers in the Minecraft Forums server list with version 1.6.4, 23 pages of 1.7.10, and 58 pages of 1.10. If that doesn't show a trend to newer versions, I don't know what does.
Given this data, one would hope that creating new mods for the new 1.10 versions would be about as simple, if not slightly more complex, as creating mods for older 1.6.4 and 1.7.10 versions. Yes, feature additions and code changes are always a roadblock, but I would expect that to a new modder with no prior experience with Forge, the increase in difficulty would not be so significant as to cause them to fail. This however, as I am finding as an experienced modder, is not the case.
Rather than leave it at this, however, I will back up my statement with an example.
Let's say that as a new modder I want to add a block. This block is just a basic block, so there's no Tile Entity or custom TESR rendering code. Let's also say that I want this block to act like wool and simply change its color depending on what the metatdata is. I also want the block to have a 'front' with a special icon, and have it face the player depending on what direction it was placed. Since this is a basic block, I don't need to make any items for it, nor do I need to worry about special properties like the bounding box size. I will have to find a way to determine the direction it faces, and store that data, but that should be simple.
In 1.7.10, this would be an easy feat. I would first need to create a class that extended Block, and then go in and override the code for registerBlockIcons() and getIcon(). I would also need to override onBlockPlacedBy() and change the metadata to a value I can use in getIcon(). Finally, I would set the creative tab and hardness stuff so I can actually place it. Pretty simple stuff so far.
I would then go and create a main mod file, subscribe to the FMLInitializationEvent, and then register my block with the GameRegistry. Boom. Block added.
Now let's take a look a version 1.10.2.
First off, the block file itself. Icons are no longer an thing, so registerBlockIcons() and getIcon() have to go. Metadata is also removed, so the onBlockPlaced() method has get tweaked to accommodate that. To get the rotation down I need to learn how to use BlockStates, but to do that I need to learn about Properties. Let's just assume I'm good at understanding tutorials for 1.8, as that's all I can find when I google "Minecraft BlockState tutorial".
So, now I need to find a way to tell my block what texture it should have. In 1.10.2, this is done by making a BlockState json file. I also need to make a model file for the block, as extending the base Block class isn't enough to tell Minecraft that I want a basic block model. Now that I have those out of the way, It's time for me to register my block in the GameRegistry and call it a day. But wait, I can't use the GameRegistry anymore as it's depreciated. No matter, the mouseover text tells me to use the registry instead, so I'll go and do that.
I fire up the debug environment and am greeted by a host of error messages in the console and a checkered block. Some on-line searching tells me that I need to register my block's json files. After figuring out how the bakery system works I try to debug the mod again. This time I get a textured block, but a crash when I try to get an item from the block. Turns out I needed to make an ItemBlock class for my block, and register that itemblock as well as the block. I also need to create a json file for the item, and register said json file with the Forge system. Back to the Bakery for me.
After all this, I finally have a working mod! Eager to show it off, I start up a server for my friends and am quickly greeted with a crash caused by my trying to register item icons on a server environment. After puzzling out how proxies work, and implementing a few of my own, I finally have a working mod.
So, what does this have to do with the difficulty/future of modding?
In a nutshell, the new system for modding is much more complex. To do something as simple as make a custom block requires much more overhead and understanding than previous versions. If you didn't keep track, here's a list of everything I would need to know and use in a 1.7.10 mod and a 1.10.2 mod:
Main mod file.
Block class file.
Metadata calculations and assignments.
Main mod file.
Block class file.
Json file format.
Block state, block model, and item model files and syntax.
ModelBakery system/ item model registry system.
ItemBlock class file.
Registry (Block vs ItemBlock)
Safe to say, there are a lot more files and systems required in later versions of Forge than earlier versions.
As someone with no Java experience prior to Minecraft (my first language was C, then Python and VBA), I find that each new Minecraft version adds a new 'abstraction', or something that's not a simple method or class file. 1.8 added the Json file format, the Model/Bakery system, and the BlockPos system. 1.8.9 added rendering Factories for entities. 1.9 added an extra layer to the sound system through the SoundEvent class and tweaked the GameRegisty to be two separate systems for items and blocks. Additionally, Forge moved fluids to IFluidContainerItems in 1.9, and then did an about-face and decided to move all fluid systems to Capabilities in 1.10.
I'm not a naysayer for change. I also understand that a good number of these changes like BlockStates and the like are Mojang's doing and not Forge's. What I am worried about is the ease at which the Forge community seems to accept these changes. If you follow the Forge changes you'll see what's coming down the pipeline and why changes are made. But I don't have the time to keep tabs on Forge development, and I suspect the majority of modders are in the same boat with me. There have been more than a few times when I have been caught doing something 'wrong', with the reason simply being I could not find anything about how to do it 'right'.
Perhaps it's the lack of documentation past 1.8 that scares me. Perhaps its all the Java-based methods like Factories, Bakeries, and Capabilities. Perhaps it's the fact that even though I create mods, I cannot figure out how the new BlockState system works, despite my best efforts at looking at the code an searching for tutorials. Maybe it's knowing that some of the mods I love will never update past 1.7.10 due to the immense number of changes to the rendering and blockstate system. Or maybe it's just the fact that I have to work with half a dozen systems just to make a block. Either way, I'm nervous about the future of Minecraft modding, and dearly hoping that it doesn't evolve into a twisted future where only those with Java training and experience can survive.
Post your comments if you want. I'm not going to defend my potion as it's an opinion that's based on observations (defending these types of positions always ends in arguments on the web). Still, I thought it would be something to say just in case other modders feel the same way. Congratulations if you read the post all the way through. You have a better attention span than most of the people I know.
Yeah that's true (except that you don't need the ItemBlock class in this case, also you don't need an item model if you use Forge's blockstates format).
Nevertheless I recommend new modders to start modding on the newest Minecraft/Forge version, because it can be a pain to update your code (especially from 1.7.10 to 1.8, then to 1.8.9 and finally 1.9.4/1.10).
As a modder who started in 1.7.10 and has updated/built mods all the way to 1.10.2, here are my two cents:
People who enter modding as a pasttime or a nice way to learn Java will often be discouraged. This was true for 1.7.10 would-be-modders and it is true of 1.10.2 would-be-modders.
People who love coding and modding, on the other hand, will not be stopped, no matter how complex it becomes to make a "simple" mod. Personally, I enjoy the challenge of writing working code (and then transforming it into good working code) and work with whatever changes are made simply because I like trying.
Was I excited by the JSON system and many rendering changes? No -- until I discovered the power of special models without a TESR or complicated vertex code. Was I excited by BlockPos and the need to change every single method signature in my block classes? No -- until I discovered the helper methods and convenience of such a container class. Was I excited by IProperty and IBlockState requiring several bridges just to get block metadata? No -- until I discovered how much easier it was to remember a property name than the significance of each bit in stair or door metadata (structure generation got a lot easier with that change). There are still some changes that I am not excited about, but I look at those as changes of which I have not learned the true power yet.
What I'm saying here is that the people who sincerely enjoy coding and modding will find a way to use every change to their benefit. At the very least they will accept the need to work with changes instead of against them. The learning curve may be steeper than it once was, but for people who love learning and trying, that steepness makes no difference.
Rollback Post to RevisionRollBack
Click this banner for a list of illegal mod distributors -- only download from legal sites!
- Yes yes, yes and yes! It did! And that's a good thing!
When jsons first came out I was really strongly against it because it's so much more harder to do than a simple ISBRH. But soon after that I have learned a lot about OpenGL and how it works in more details. (not only add points with texture positions to render something) And I have realized that it's harder for a reason. You absolutely need to sacrifice easy code for performance!
Well mc is actually guilty of this as well for not implementing a proper rendering engine and is still using a rendering protocol that is deprecated and heavily discouraged to use for a couple of years... (Just, that the actual hell Mojang? How does this not raise a red flag...)
But vanilla code is great when compared with some mods in terms of rendering so jsons are for sure a good thing.
More abstraction = less uneducated coders making bad code
More abstraction = educated/experienced modders finding an efficient way around abstraction and not making bad code.
More abstraction = better mod code overall
1.5. Point: no more metadata as int aka 0-15 values:
This is one of those things that were advertised as no more parsing ints to usable data, but is actually just an extra layer o abstraction of the int->data process + less convenient code.
I don't know about this one... It could be a good thing if i was deleted and properly implemented while not caring about backwards comparability. (in terms of code not save files)
In a nutshell, the new system for modding is much more complex. To do something as simple as make a custom block requires much more overhead and understanding than previous versions.
Yes that is a sign that the mc code is improving and naturally requires more complexity.
That's why I think that there should be some utility framework (maybe in forge?) that has: no performance penalty, easy to use as normal mc in 1.7 or even more and has a wide range of flexibility in most/all parts of development.
Side mini rant about vanilla mc code:
BlockPos and it's concept is bad... really bad... It decreases the performance of the game as if puts a lot more work in the garbage collection. Why? Because there is no primitive types which are discarded a lot faster (int, float, double...) and instead of that there is a lot of full blown objects. That translates to more GC scanning for dead objects and to less computing power free for game updating and rendering.
A much better way of implementing BlockPos convenience would be a solid Utility class with static methods that processes the int x, int y, int z the same as a BlockPos would. This would give the fast code aka less GC and retain the convenience of BlockPos.
What I am worried about is the ease at which the Forge community seems to accept these changes.
Do we have an option to not accept them? If So I will gladly decline them and make mc better preforming.
Perhaps it's the fact that even though I create mods, I cannot figure out how the new BlockState system works, despite my best efforts at looking at the code an searching for tutorials.
You are not alone my friend... I gave up on understanding it. I know that the setter of a state is withProperty and things like that, but anything above that is... Eeeh... Not worth to understand.
I feel I should comment on this too. I completely agree with sky_01, and he mostly speaks my mind.
I also started in 1.7.10 and have worked through updating mods all the way to 1.10.2 and there's nothing that has stopped me or even made me consider stopping.
The later versions, in my opinion, have been so much better, providing much better and more flexible ways to create mods. I mean, sure it takes some work to learn the new ways of doing things, but should that be a concern? Minecraft was built by a team who didn't know too much and have been learning as they worked (or so I've been told), and the code wasn't great. But they're improving it with every update, and I'm loving it. Some see obstacles in the changes, but I see improvements and new possibilities. The new json modelling, like sky_01 said, was a vast improvement and meant you could easily make models without TESRs. Yes, you need all these jsons per item and block, but it's the power of those files which is what makes them worth it.
I'm not saying I agree with all changes, but overall I've been enjoying the changes and look forward to future improvements.