Background:
I see A LOT of suggestions on the forums regarding the flexibility of materials and items. By that I mean, a lot of people would like to be able to make stairs from any material, fences of any material, blocks of any color, and so forth. The current system for MineCraft object IDs (data values) is hardcoded for an extremely limited set of objects and has very little flexibility.
Proposal:
Expand the data values to include more bits for generic object implementation.What does that mean? Well, let me show you.
Proposed data value: XXXX.XXXX.YYYY.ZZZZ
The "." is just for reference (every 4 bits). So the the first 8 bits, XXXX.XXXX, are for the item ID. 8 bits = 2^8 = 256 items. That's the existing number and you could argue it's small, but I'll leave it the same for now. Bits 9-12, YYYY, would be the item modifier and would give you 2^4=16 options. The options could be stairs, fences, whatever you want. Finally, the last four bits, ZZZZ, would be for color. This gives you 16 options which matches with the number of colors already in game.
In reality, this just means that all items have 16 bit data value. Sure, you can use them for anything, but following a pattern makes it easier to code. In practice it means you could make something like this:
<Stone Block>.<Stair>.<Red>
Advantages:
1) Options - We need a larger ID range and we might as well organize the data range in a sensible manner. This makes it easier to code and easier create mods for later.
2) Flexibility - Mojang doesn't have to create a new item for each variant of a block. This gives them far more flexibility to allow any combination of material, object and color into the game.
3) Compatible - In gameplay (not coding) this proposal is consistent with the direction MC seems to be heading. For example, we have various colors of wood planks. Wouldn't it be far easier to keep track of a color instead of a wood type? So instead of saying jungle wood, we have red wood which is generic and if you make a door out of it, it keeps the color code from the original planks? Yes, there are some other details to work out, but they are minor implementation decisions, not theory roadblocks.
Drawbacks:
1) Investment - There's no doubt about it, updating the data values is not a minor task. A lot of the code will have to be re-written in order to handle it. I'd like to think that any upfront costs will yield long term savings though, but I can't say for sure.
2) Disruptive - This will essentially break all mods in existence. Sorry, but there's no way around it. Of course, I doubt most mod makers would mind because many of them already play tricks with IDs to begin with. In fact, I personally see updated object IDs as a fundamental aspect in the production of a MC API.
3) Performance - By expanding the number of bits in a data value, there is potentially a hit to performance as small amount of additional data will be stored in memory. I can't give specifics on this though because there's a lot of competing factors, but I will say that much of this data already exist anyway, so moving it to a more streamlined encoding doesn't actually change the overall amount of data, it just arranges it in a more logical way.
Possible uses:
Stairs, fences, doors, ladders, sign, etc of any material or color
Customizable weapons, tools, armor with different colors or even visual enchantments (such as a custom sword with a lapis lazuli pommel and a gold crossroads)
Torches with different colors
More mobs variety with different textures (maybe even unique to the biome spawned in)
And many more...
Further Discussion: It would be possible to add additional bits to any part of the proposed data value encoding. Remember, each additional bit doubles the number of options, so going from 8 bits to 9 bits means going from 256 options to 512 options. That just means you don't have to add a lot of bits to get a truly large number of options. I did keep my original suggestion at a rather tame 16 bits simply for ease of discussion, but expanding to more bits, such as 32, would allow easy and complete storage of all aspects items.
If that could make wool greyscale, would be awesome.
That would be really nice, but I have no idea if that would lag much.
Support.
It could be used to make more colors, including greyscale, if Mojang wanted to add a couple more bits to the color data.
I believe that a chunk in MC consists of 16x16x256 blocks for a total of 65,536 blocks. Each block is a minimum of 8 bits (more if you include damage values used to determine wool color). That means each chunk requires at least 524,288 bits or 64KB which is a trivial amount. Even if you doubled the amount of bits (from 8 to 16) per object, that's a mere 128KB. Based on the MC wiki, the game loads 441 concurrent chunks for a total of roughly 56 MB with my proposal. Clearly memory space is not the primary concern in in MC lag - ergo I don't believe expanding the data value will have significant impacts in game performance.
Actually, I almost brought that up I think most people would agree that MC isn't optimized particularly well and improvements to chunk loading system (such as mention in the cubic chunks idea) or rendering (such as with OptiFine) would more than offset any performance losses caused by expanded IDs.
Thanks for the support, though (to be nitpicky) the idea of object ID encoding was actually something I was thinking about after seeing all the various suggestions on various types of stairs, colors, etc - not just yours. Not that you aren't a special, unique snowflake though - You still are
I really wish I could tell you that I knew this could work, or that it would make everything easier, but I'm afraid my limited technical knowledge does not allow me to do so. I trust you know what you are doing, though, so I completely support.
I also get the feeling that not all people will share my belief that this would be worth the drawbacks on your list, but hopefully those people will be few and far between.
I really wish I could tell you that I knew this could work, or that it would make everything easier, but I'm afraid my limited technical knowledge does not allow me to do so. I trust you know what you are doing, though, so I completely support.
I also get the feeling that not all people will share my belief that this would be worth the drawbacks on your list, but hopefully those people will be few and far between.
Thanks, CodenameDuchess. To be honest, I'm not 100% sure it all works either. I'm a computer engineer by training, but I've not done any programming in many years nor have I dissected MineCraft to understand its code guts. What I have done is read other peoples' accounts (mostly in the mods section) to get some ideas and I think I accurately represent the current system, but I would love if someone more knowledgeable on MineCraft wanted to jump in.
What I do know for a fact is that the system was never designed from the ground up to have many items. The current system really is limited to just 256 unique items. Now, Mojang has hacked together some work arounds (such as using damage values to describe color in wool), but it's not very efficient or easy to use. I much rather have a generic encoding system for object IDs with expanded data values if it makes modding and future work easier - even if it means delaying horse mobs and such.
I didn't know Minecraft was so limited (I might have in the back of my mind). Knowing that, I completely agree the limit should be increased, especially if it leads to easier fences, stairs, and slabs. I don't know if I would delay horses for it, as they're almost complete, but I can see where you're coming from.
Anyway, that's just me, and it's not as if anyone can tell Mojang to delay or implement something.
You know, I kind of wish they would spend an update (or maybe even a complete overhaul) implementing things like this and cubic chunks. I've heard that Java is very inefficient for games, so I guess if they could rewrite Minecraft on something else it would be nice. It is entirely possible that Java is great for games, it's just what I heard from "some people somewhere".
Java is less efficient than C for various reasons and most people, even Java fans, will admit that. The advantage is that Java can be used on (almost) any system. Doesn't matter what the operating system is or even what type of hardware you have. Personally, I'm fine with that. MineCraft is a simple enough game that a little efficiency due to Java isn't problem.
The real problem is that MC was never written by (I hate to sound like a a jerk, but...) professional programmers. I'm sure Notch is a way better programmer than me and I'm sure he learned a lot during the process of designing MC, but there's a lot of issues built into the game the current Mojang team has to deal with. Why do you think Notch has moved onto 0x10c...
All of these are obviously nothing but fantasies, especially the Java one, but I don't mind.
Sadly, I think you're right. I'm not even sure why I bother to write on the suggestion forums. I guess I like deluding myself Still, maybe if enough people clamor for technical upgrades, Mojang will listen and make some changes.
Sadly, I think you're right. I'm not even sure why I bother to write on the suggestion forums. I guess I like deluding myself Still, maybe if enough people clamor for technical upgrades, Mojang will listen and make some changes.
Good to know about Java, and I wonder about Suggestions as well sometimes.
Anyway, I should let other people post on the actual topic, and I wish you good luck with supporters for this.
I see A LOT of suggestions on the forums regarding the flexibility of materials and items. By that I mean, a lot of people would like to be able to make stairs from any material, fences of any material, blocks of any color, and so forth. The current system for MineCraft object IDs (data values) is hardcoded for an extremely limited set of objects and has very little flexibility.
Proposal:
Expand the data values to include more bits for generic object implementation. What does that mean? Well, let me show you.
Proposed data value: XXXX.XXXX.YYYY.ZZZZ
The "." is just for reference (every 4 bits). So the the first 8 bits, XXXX.XXXX, are for the item ID. 8 bits = 2^8 = 256 items. That's the existing number and you could argue it's small, but I'll leave it the same for now. Bits 9-12, YYYY, would be the item modifier and would give you 2^4=16 options. The options could be stairs, fences, whatever you want. Finally, the last four bits, ZZZZ, would be for color. This gives you 16 options which matches with the number of colors already in game.
In reality, this just means that all items have 16 bit data value. Sure, you can use them for anything, but following a pattern makes it easier to code. In practice it means you could make something like this:
<Stone Block>.<Stair>.<Red>
Advantages:
1) Options - We need a larger ID range and we might as well organize the data range in a sensible manner. This makes it easier to code and easier create mods for later.
2) Flexibility - Mojang doesn't have to create a new item for each variant of a block. This gives them far more flexibility to allow any combination of material, object and color into the game.
3) Compatible - In gameplay (not coding) this proposal is consistent with the direction MC seems to be heading. For example, we have various colors of wood planks. Wouldn't it be far easier to keep track of a color instead of a wood type? So instead of saying jungle wood, we have red wood which is generic and if you make a door out of it, it keeps the color code from the original planks? Yes, there are some other details to work out, but they are minor implementation decisions, not theory roadblocks.
Drawbacks:
1) Investment - There's no doubt about it, updating the data values is not a minor task. A lot of the code will have to be re-written in order to handle it. I'd like to think that any upfront costs will yield long term savings though, but I can't say for sure.
2) Disruptive - This will essentially break all mods in existence. Sorry, but there's no way around it. Of course, I doubt most mod makers would mind because many of them already play tricks with IDs to begin with. In fact, I personally see updated object IDs as a fundamental aspect in the production of a MC API.
3) Performance - By expanding the number of bits in a data value, there is potentially a hit to performance as small amount of additional data will be stored in memory. I can't give specifics on this though because there's a lot of competing factors, but I will say that much of this data already exist anyway, so moving it to a more streamlined encoding doesn't actually change the overall amount of data, it just arranges it in a more logical way.
Possible uses:
It could be used to make more colors, including greyscale, if Mojang wanted to add a couple more bits to the color data.
I believe that a chunk in MC consists of 16x16x256 blocks for a total of 65,536 blocks. Each block is a minimum of 8 bits (more if you include damage values used to determine wool color). That means each chunk requires at least 524,288 bits or 64KB which is a trivial amount. Even if you doubled the amount of bits (from 8 to 16) per object, that's a mere 128KB. Based on the MC wiki, the game loads 441 concurrent chunks for a total of roughly 56 MB with my proposal. Clearly memory space is not the primary concern in in MC lag - ergo I don't believe expanding the data value will have significant impacts in game performance.
Anyway, thanks for the support.
Thanks again for a good comment.
Link Removed and click continue.
Thanks for the support, though (to be nitpicky) the idea of object ID encoding was actually something I was thinking about after seeing all the various suggestions on various types of stairs, colors, etc - not just yours. Not that you aren't a special, unique snowflake though - You still are
Link Removed and click continue.
Thanks!
Thanks, too!
Haha, me neither Thanks!
My suggestion is really similar but it only deals with slabs.
http://www.minecraftforum.net/topic/1815572-double-slabs-with-two-slab-types/
I also get the feeling that not all people will share my belief that this would be worth the drawbacks on your list, but hopefully those people will be few and far between.
Thanks, Redelem. I'll keep an eye on your suggestion.
Thanks, CodenameDuchess. To be honest, I'm not 100% sure it all works either. I'm a computer engineer by training, but I've not done any programming in many years nor have I dissected MineCraft to understand its code guts. What I have done is read other peoples' accounts (mostly in the mods section) to get some ideas and I think I accurately represent the current system, but I would love if someone more knowledgeable on MineCraft wanted to jump in.
What I do know for a fact is that the system was never designed from the ground up to have many items. The current system really is limited to just 256 unique items. Now, Mojang has hacked together some work arounds (such as using damage values to describe color in wool), but it's not very efficient or easy to use. I much rather have a generic encoding system for object IDs with expanded data values if it makes modding and future work easier - even if it means delaying horse mobs and such.
I didn't know Minecraft was so limited (I might have in the back of my mind). Knowing that, I completely agree the limit should be increased, especially if it leads to easier fences, stairs, and slabs. I don't know if I would delay horses for it, as they're almost complete, but I can see where you're coming from.
Anyway, that's just me, and it's not as if anyone can tell Mojang to delay or implement something.
Java is less efficient than C for various reasons and most people, even Java fans, will admit that. The advantage is that Java can be used on (almost) any system. Doesn't matter what the operating system is or even what type of hardware you have. Personally, I'm fine with that. MineCraft is a simple enough game that a little efficiency due to Java isn't problem.
The real problem is that MC was never written by (I hate to sound like a a jerk, but...) professional programmers. I'm sure Notch is a way better programmer than me and I'm sure he learned a lot during the process of designing MC, but there's a lot of issues built into the game the current Mojang team has to deal with. Why do you think Notch has moved onto 0x10c...
Sadly, I think you're right. I'm not even sure why I bother to write on the suggestion forums. I guess I like deluding myself Still, maybe if enough people clamor for technical upgrades, Mojang will listen and make some changes.
Good to know about Java, and I wonder about Suggestions as well sometimes.
Anyway, I should let other people post on the actual topic, and I wish you good luck with supporters for this.