Every new version release, we get tons of features and some players like some of them while hating some of them.
Then they get told "Just play the previous version you whiner". But doing that to get rid of the one feature they don't like, they have to sacrifice all the OTHER new features they liked. That is not a good approach.
What if Mojang started coding stuff as "modularly" as possible ?
Some (all the most important ones especialyl those that created much debate on the forums) of the game's features get their own version number, which is the version when that feature appeared. A feature that gets some kind of major change ALSO would get a new version number.
When you start a game, instead of simply starting say a 1.8 or a 1.9 game, you could start a "custom version" game.
You then go to a screen with a long list of features that were "versioned", and you have picklists to choose which version for which feature. Some features listed there would only have two choices, others more. Some choices would simply not be compatible creating "red lines".
You could then save your custom version preferences, and THEN start a game with that set. If there are feature incompatibilities, they get explained in better detail then.
Thus, I could start a game with the BETA overworld generator, the 1.6.4 combat system, but with the 1.9 Strongholds and Nether. Or whatever mixes ok. Or start a normal 1.9 game but for extreme hills the older world generation would be used. And so on. Or for example I really hate the look of the new stones so I could turn them off from world generation, then go exploring somewhere and mining and would have to look at all those ugly veins. Then when I come back, I turn the feature back on again.
You could swap in-game but when a change "breaks" stuff, you would get a warning.
Note that I am not talking about ALL features here. i.e. you wouldn't have "versioning" for minor details that don't really change the game. For example, they added new doors, without changing the old doors, so there is no reason to "versionalize" the doors feature. Otherwise the list of features in that screen would be ridiculously huge. Also, most of the "versioning" wouldn't be about single ultra-specific features, but more like a "pack" of features. For example how the combat system is actually a big number of features all packaged to work together. You couldn't choose" new sword" with "old axe", for example. There would only be one item to choose, which combat system, which would affect ll of the weapons.
Also, "turning off" a feature would turn off only those parts of the feature without "limiting" the player's choices. For example in the case of me turning of the 3 new stones off, I wouldn't actually turn off the entire existence of these stones off. They'd still be in my inventory. They'd still be there underground in already world generated pockets. It woyuld only be in NEW chunks that they simply wouldn't generate. i.e. Simple to code, backward compatible, not game breaking. Another such very minor "versionezed" feature would be the Poppy. You could select to see that block as the old Rose instead. Same block, same item, just seeing it differently in the environment and in your inventory, that one is a very minor change. A slightly bigger one would be "Dyes per flower", for example.
For all that to work, each module should be independent. i.e. Zero "spaghetti code" that directly hardcode-references everything else all over the place.
Or maybe have the game use text files for EVERYTHING. Don't even need a ocmplex custom version screen then, just a single filename. Don't like some features preferred older version ? Go copy the 1.9 customization file to another file say 1.9mycustom, go check the 1.8 1.7 1.6 whatever customization files and replace the 1.9 values you don't want by those o those other files, and voilà, your own custom game.
This would allow a true sandbox: play how you like !
Mapmakers could go wild with how easy it would be to add recipes, swap not only textures but also block behavior.
Potential problems
But I don't know if that is even possible.
#1 - Adding such a layer of indirection may have an impact on performance that might render this suggestion impossible. C language allows prototyping a function call into an appropriately type-formatted pointer so that you can swap on the fly which function gets called so that an algorithm can call the "proper" function according to user data, instead of hardcoding the call, without any performance loss. i.e. Instead of calling the function directly, you call the function that a function pointer variable contains the pointer to. Such dereferencing is handled by the compiler and doesn't take extra CPU cycles when running the program. However, I'm not sure at all if Java' is capable of doing that kind of thing. Maybe the only way to do it is through the config text file then, but that would mean a game that is a bit slower to start.
#2 - Minecraft really *is* spaghetti code still, so implementing this might require TONS of code rewrite.
On the plus side, and it is to me the MAIN attraction here, is that once that "patch the feature" functionality would be implemented, you'd have NEARLY done and completed the so-long-promised API interface. Because if you can mix and swap features no matter which version, then you can also mix and swap features no matter which mods.
This would be a technical nightmare to implement. Every time something is added as an option it adds another exponent of potential issues. Meaning if you force all sounds to play all the time, you only need to test for sounds not playing. If you give options to turn sounds off, you need to test for them not playing when they should and playing when they shouldn't. Add a third option (like the subtitles for deaf people), and that is another whole thing you need to test. And those are little things.
This is huge interlocking features and could cause tons and tons of problems. Plus, every single combination would need to be tested in tandem. Lets take a few. Enchanting, attack cooldowns, the new Enderdragon fight, Elytra, and the Hunger system. You need to test them all separately and in every possible configuration.
Basically if they were to do this, they might as well just go open source and stop development entirely. It would be easier on them and probably give people more options because the thousands of amateurs would be able to push out more work. Then if there were bugs they would not be responsible.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
On the plus side, and it is to me the MAIN attraction here, is that once that "patch the feature" functionality would be implemented, you'd have NEARLY done and completed the so-long-promised API interface. Because if you can mix and swap features no matter which version, then you can also mix and swap features no matter which mods.
Whoo! So 1.10 will be 100x late. Code rewriting is tiring, boring, huge job, etc. Unless Microsoft helps Mojang, the answer is Almost No.
Rollback Post to RevisionRollBack
I'm a programmer. I use C/C++, BASIC, Assembly, and Python. If i sound too technicial, that's because it's the way i think.
Yeah you're so right ... How many full-time programmers does this billon-dollars game software employs? Strictly for the PC version, maybe 4 or 5 guys? So yeah maybe it wouldn't work so great lol.
This would be a technical nightmare to implement. Every time something is added as an option it adds another exponent of potential issues. Meaning if you force all sounds to play all the time, you only need to test for sounds not playing. If you give options to turn sounds off, you need to test for them not playing when they should and playing when they shouldn't. Add a third option (like the subtitles for deaf people), and that is another whole thing you need to test. And those are little things.
This is huge interlocking features and could cause tons and tons of problems. Plus, every single combination would need to be tested in tandem. Lets take a few. Enchanting, attack cooldowns, the new Enderdragon fight, Elytra, and the Hunger system. You need to test them all separately and in every possible configuration.
Basically if they were to do this, they might as well just go open source and stop development entirely. It would be easier on them and probably give people more options because the thousands of amateurs would be able to push out more work. Then if there were bugs they would not be responsible.
I see forcing those tests as a side-benefit: forcing the code to be modular means they'd HAVE to put emphasis on the mod API *and* on better testing. Because seriously, this game is really buggy lol. Cleaner more structured code = we'd end up with less bugs = better development cycle and easier to add new features or modify old ones!
But of course that would be extra work, so they'd have to hire extra staff but ... (sarcasm mode on) obviously they can't do that, because y know, Minecraft is bringing them so little money, they can really allow allocatingm more than a tiny handful of coders to it (sarcasm mode off).
Even if they had a hundred or more staff and a whole QA team they wouldn't want to do this. I've worked as a tester for Activision and they typically don't use more than a few standard control schemes because every part of the game needs to be tested with each scheme. That means making sure all controls work at each point, all button graphics display correctly everywhere, all images of the control scheme are updated properly, etc. And those were with developers that had like 30-50 people and the testing teams usually had as many people, sometimes more.
Outside of PC titles, doing custom control schemes are usually out of the question for most developers. PC is fundamentally easier because you don't need to use standardized button graphics or set text. Typically, if you use text you have to use specific terminology like saying Wii Remote or "Press the A Button". Saying Wiimote or "Press A" can cause the console makers to fail a game and make the devs fix it.
And that is just for control schemes lol. It would be a logistical nightmare to do it with entire game features, no matter how big the team was.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
Every new version release, we get tons of features and some players like some of them while hating some of them.
Then they get told "Just play the previous version you whiner". But doing that to get rid of the one feature they don't like, they have to sacrifice all the OTHER new features they liked. That is not a good approach.
What if Mojang started coding stuff as "modularly" as possible ?
Some (all the most important ones especialyl those that created much debate on the forums) of the game's features get their own version number, which is the version when that feature appeared. A feature that gets some kind of major change ALSO would get a new version number.
When you start a game, instead of simply starting say a 1.8 or a 1.9 game, you could start a "custom version" game.
You then go to a screen with a long list of features that were "versioned", and you have picklists to choose which version for which feature. Some features listed there would only have two choices, others more. Some choices would simply not be compatible creating "red lines".
You could then save your custom version preferences, and THEN start a game with that set. If there are feature incompatibilities, they get explained in better detail then.
Thus, I could start a game with the BETA overworld generator, the 1.6.4 combat system, but with the 1.9 Strongholds and Nether. Or whatever mixes ok. Or start a normal 1.9 game but for extreme hills the older world generation would be used. And so on. Or for example I really hate the look of the new stones so I could turn them off from world generation, then go exploring somewhere and mining and would have to look at all those ugly veins. Then when I come back, I turn the feature back on again.
You could swap in-game but when a change "breaks" stuff, you would get a warning.
Note that I am not talking about ALL features here. i.e. you wouldn't have "versioning" for minor details that don't really change the game. For example, they added new doors, without changing the old doors, so there is no reason to "versionalize" the doors feature. Otherwise the list of features in that screen would be ridiculously huge. Also, most of the "versioning" wouldn't be about single ultra-specific features, but more like a "pack" of features. For example how the combat system is actually a big number of features all packaged to work together. You couldn't choose" new sword" with "old axe", for example. There would only be one item to choose, which combat system, which would affect ll of the weapons.
Also, "turning off" a feature would turn off only those parts of the feature without "limiting" the player's choices. For example in the case of me turning of the 3 new stones off, I wouldn't actually turn off the entire existence of these stones off. They'd still be in my inventory. They'd still be there underground in already world generated pockets. It woyuld only be in NEW chunks that they simply wouldn't generate. i.e. Simple to code, backward compatible, not game breaking. Another such very minor "versionezed" feature would be the Poppy. You could select to see that block as the old Rose instead. Same block, same item, just seeing it differently in the environment and in your inventory, that one is a very minor change. A slightly bigger one would be "Dyes per flower", for example.
For all that to work, each module should be independent. i.e. Zero "spaghetti code" that directly hardcode-references everything else all over the place.
Or maybe have the game use text files for EVERYTHING. Don't even need a ocmplex custom version screen then, just a single filename. Don't like some features preferred older version ? Go copy the 1.9 customization file to another file say 1.9mycustom, go check the 1.8 1.7 1.6 whatever customization files and replace the 1.9 values you don't want by those o those other files, and voilà, your own custom game.
This would allow a true sandbox: play how you like !
Mapmakers could go wild with how easy it would be to add recipes, swap not only textures but also block behavior.
Potential problems
But I don't know if that is even possible.
#1 - Adding such a layer of indirection may have an impact on performance that might render this suggestion impossible. C language allows prototyping a function call into an appropriately type-formatted pointer so that you can swap on the fly which function gets called so that an algorithm can call the "proper" function according to user data, instead of hardcoding the call, without any performance loss. i.e. Instead of calling the function directly, you call the function that a function pointer variable contains the pointer to. Such dereferencing is handled by the compiler and doesn't take extra CPU cycles when running the program. However, I'm not sure at all if Java' is capable of doing that kind of thing. Maybe the only way to do it is through the config text file then, but that would mean a game that is a bit slower to start.
#2 - Minecraft really *is* spaghetti code still, so implementing this might require TONS of code rewrite.
On the plus side, and it is to me the MAIN attraction here, is that once that "patch the feature" functionality would be implemented, you'd have NEARLY done and completed the so-long-promised API interface. Because if you can mix and swap features no matter which version, then you can also mix and swap features no matter which mods.
This would be a technical nightmare to implement. Every time something is added as an option it adds another exponent of potential issues. Meaning if you force all sounds to play all the time, you only need to test for sounds not playing. If you give options to turn sounds off, you need to test for them not playing when they should and playing when they shouldn't. Add a third option (like the subtitles for deaf people), and that is another whole thing you need to test. And those are little things.
This is huge interlocking features and could cause tons and tons of problems. Plus, every single combination would need to be tested in tandem. Lets take a few. Enchanting, attack cooldowns, the new Enderdragon fight, Elytra, and the Hunger system. You need to test them all separately and in every possible configuration.
Basically if they were to do this, they might as well just go open source and stop development entirely. It would be easier on them and probably give people more options because the thousands of amateurs would be able to push out more work. Then if there were bugs they would not be responsible.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
Whoo! So 1.10 will be 100x late. Code rewriting is tiring, boring, huge job, etc. Unless Microsoft helps Mojang, the answer is Almost No.
I'm a programmer. I use C/C++, BASIC, Assembly, and Python. If i sound too technicial, that's because it's the way i think.
My Suggestions
Yeah you're so right ... How many full-time programmers does this billon-dollars game software employs? Strictly for the PC version, maybe 4 or 5 guys? So yeah maybe it wouldn't work so great lol.
I see forcing those tests as a side-benefit: forcing the code to be modular means they'd HAVE to put emphasis on the mod API *and* on better testing. Because seriously, this game is really buggy lol. Cleaner more structured code = we'd end up with less bugs = better development cycle and easier to add new features or modify old ones!
But of course that would be extra work, so they'd have to hire extra staff but ... (sarcasm mode on) obviously they can't do that, because y know, Minecraft is bringing them so little money, they can really allow allocatingm more than a tiny handful of coders to it (sarcasm mode off).
Even if they had a hundred or more staff and a whole QA team they wouldn't want to do this. I've worked as a tester for Activision and they typically don't use more than a few standard control schemes because every part of the game needs to be tested with each scheme. That means making sure all controls work at each point, all button graphics display correctly everywhere, all images of the control scheme are updated properly, etc. And those were with developers that had like 30-50 people and the testing teams usually had as many people, sometimes more.
Outside of PC titles, doing custom control schemes are usually out of the question for most developers. PC is fundamentally easier because you don't need to use standardized button graphics or set text. Typically, if you use text you have to use specific terminology like saying Wii Remote or "Press the A Button". Saying Wiimote or "Press A" can cause the console makers to fail a game and make the devs fix it.
And that is just for control schemes lol. It would be a logistical nightmare to do it with entire game features, no matter how big the team was.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum