Now its called the ar system. The Sun didn't explode, just the letters "Sol". Somehow.
I wish that forum games were more active in general.
I don't have homework at my school though.
ATK goes to 999999999999, then you 1-hit the strongest boss, you level up and your ATK increases by 1, causing an overflow and setting your ATK to 0.
I wish for a potato.
I do like the idea of Witches working a bit more with illagers, but I think they should retain some level of seperation, so I only can give partial support.
Ooooh, a USB from a mountain. I wonder what a mountain would store on a USB?
Okay, I just want to start with asking: Do you even live in 2018? Gender equality exists. Weapons shouldn't be more "feminine" for female players. Minecraft is a sandbox game, and certainly doesn't need anything close to gender stereotypes added to it. Plus, on Notch's old blog, he did once state that no mobs have genders, and so logically that should apply to players too. (Also there are several flaws code-wise).
And on roles:
Minecraft is a sandbox game for players to be and do anything. You shouldn't limit what players can do with roles/classes. And not everyone plays survival multiplayer.
All in all, no support. We don't need gender bias in Minecraft and the reason Minecraft: Dungeons is likely to get classes is because it's more fighting and dungeon-crawling based rather than the open ended-sandbox of regular Minecraft.
(Though I agree with C1ff and Deonyl that non-bifurcated leg-wear might be a nice addition as a toggle in skin settings)
Okay, I just would like to say something referring to the poll.
"Burn the EULA!" or "Keep EULA we Prefer Free Over Quality".
One option is supporting this suggestion. The other is almost mocking you for not supporting. Not a good way to lay out a poll.
And responding to your actual suggestion, the new EULA gives more freedom, allowing creators to make as much money as they want, as long as they don't give a player advantage over others.
This seems like a pretty neat idea, but the wall of text does make it slightly difficult to get all the details. Splitting it into paragraphs and maybe even some images would make it much easier to accurately critique this suggestion.
Padlocks and Keys: Locking and Moving Blocks with Inventories
Since the introduction of chests, there have been two constant problems in Minecraft: Thieving players and chests full of random items you don't want to move. To help with both these problems, I have a few connected suggestions, which are listed below. (For the purposes of this suggestion a block or a block's inventory being "locked" means a padlock has been applied to it, not that the inventory is necessarily completely inaccessible.)
Part 1: The Basics
1) Adding padlocks and keys for locking blocks with inventories.
2) You use the padlock and key on a block with an inventory by shift-right-clicking with a padlock, locking the inventory and giving you just the key.
3) Players without the key, droppers, and hoppers then can't access the inventory until you unlock it again by shift-right-clicking on the block with the same key, giving you the padlock and key back. You don't open the inventory this way. You can still open the inventory by holding the key in your hand and right-clicking normally without unlocking it.
4) You can break a locked block like any other block, but it doesn't drop its contents.
5) You can pick up this block and place it elsewhere, with the inventory still inside. But you can only hold it in your off-hand slot and can't place it in any other inventory.
6) Double chests need to be locked on both sides in order to stop people opening them. Locked chests won't connect to any chests they are placed next to, or which are placed beside them.
7) Locked blocks can be broken open by placing them in an anvil and paying an amount of xp levels depending on how filled the inventory is, similar to how comparators calculate their output, with the percentages of how full each slot is added up used to calculate the levels needed.
The basic idea to this isn't new, but it has always been plagued with problems, to which the solutions have always been complex, unintuitive and inelegant. When conceiving this idea I swore to make solutions that were none of those. I think I have succeeded, but judge for yourselves.
One thing to note, however, is that while I set out to help with the above problems, I don't simply want to solve them. Protecting your items from other players and cleaning up are part of the game, I feel, but the methods available are often time-consuming, frustrating and impractical for the day-to-day routine.
As you might know, Minecraft already has a locking mechanic, but only in the commands. I tried to keep my suggestion as similar to this mechanic as possible, as this would aid in keeping it simple, but some things were changed because they would have made things more complex or unworkable if I had kept them. I am not, however, suggesting this command be removed - my suggestion and this command can easily work side-by-side.
For those who are interested I'll now explain each point in more detail and explain the thought-processes behind them.
Why padlocks? Well, because, as a new feature, I decided the simplest way to add it was as an extra item, instead of overhauling the GUIs of each storage block. This, and to make locking an investment (however small). It also gives an easy way to link locked inventories to their keys and makes them reusable.
Though all of these things might apply if I had just suggested a key, having just a key would mean running into problems regarding explaining why different keys fit the same container, but the container could only be unlocked using the key it was locked with, and would circumnavigate the cost of locking a block because you could use the same key multiple times (it's either that or limiting the key to locking only one block, in which case the function would be exactly the same as the padlock and key, but you couldn't tell which key had been used already). The cost for locking each block is important, I feel, because having locking containers should be an investment, not a standard thing everybody always does.
You craft a padlock with two iron nuggets and an iron ingot, as shown here:
2) Locking an Inventory
As I said, you lock an inventory by shift-right-clicking with a padlock and key, as you would to access the inventory of a horse or llama. The padlock and key item then changes into a key item:
This change is similar to the change when you right-click with a map. However, unlike with a map, the new item is only ever called "Key". The link to the block is stored as NBT data. While the lock mechanic through commands uses renamed items in hand to let the player open locked inventories, implementing this into my suggestion would have been difficult or make little intuitive sense, since then the keys would always need to be renamed, either through randomisation, in which case you couldn't rename it again yourself to your liking (such as "Bedroom Chest Key" or "Enderpearl Dispenser Key"), the renaming would need to happen upon either crafting or applying the padlock and key (a task I would prefer to leave in the proverbial hands of the anvil, the ownership of which shouldn't be necessary for using padlocks and keys) or any not-renamed key would fit any not-renamed padlock-on-an-inventory, as well as any item renamed "Key", which would defeat the purpose of the entire operation (and preventing this would require an anvil, with the same problems as before). The part I would keep is opening the container with a left click if you have the key in hand, without formally unlocking it.
One important part to this is that if you do rename a padlock and key or a key, if you lock or unlock an inventory with it, the name remains the same.
3) Inaccessability of Inventories
I tried to limit the impact of this suggestion to just what it set out to do, to make sure it didn't infringe on other mechanics too much and become less useful. As such, while players, hoppers and droppers can't access the inventory (the latter two since otherwise other players could still mess with the inventory of locked blocks outside of how the player who locked it intended them to), the function of the block outside of that should stay the same. Dispensers should still dispense items, shoot arrows and potions and put on armour, hoppers should still push and pull items in and out of other (unlocked) inventories, and furnaces should still smelt. This means that players can't disable arrow traps by stealing the arrows, for one thing.
Regarding hoppers, this could mess with some complex redstone circuits that rely on items being pulled out of one hopper while that hopper tries to push the same item into a different inventory than the hopper that is pulling (people who care will understand that). In that case I'd suggest just not locking the top hopper. There is no workaround I can think of that is simple enough not to require a GUI of sorts, unfortunately.
4) Breaking a Locked Container
In order to prevent thieves from simply busting open a locked container, something that is far easier in Minecraft than in real life, either the container needs to be made unbreakable (or simply a lot harder to break), which allows for easy griefing by placing locked containers everywhere in someone's base, or it needs to drop without dropping the contents, something for which the shulker boxes were invented and which would be, frankly, overpowered and make shulker boxes useless. Between the pressure of this dichotomy is where these types of suggestions often break. But I think I've found an intuitive workaround: See the next section.
5) Only Holding it in your Off-hand
My workaround is to let locked containers be broken and picked up, which also lets you more easily rearrange and remove chests that are in the way without making you worry about removing and rehousing the contents.
But you can only pick it up (!) in your off-hand, and you can't place it in your or any other inventory. Think of it as jamming it under your left (or right, for you lefties) arm. This has a number of uses:
1) You can only pick up one at a time, which along with not being able to store them in other inventories helps prevent shulker boxes from becoming useless.
2) Your actions are limited until you put it down, since the off-hand right-click replaces the left hand one until the off-hand is emptied. So no torches or block-placing for you until you put it down (though you can still use buttons and such).
3) Thieves can only make off with one storage block at a time. This also means vandals need to work harder when destroying entire storage rooms, either letting each chest despawn or having to dispose of each chest one by one. This one is more in your favour.
Despite all this, if this is implemented I am positive locked chests will be used like backpacks, but this is ok, I think, because all other options for with-player item transport such as mules/donkeys, shulker boxes and ender chests are in many ways superior to carrying a locked chest around, so won't be skipped in favour of this.
One thing to note is that you can lock shulker boxes, and locking them doesn't override the fact they can be stored in any inventory slot (besides other shulker boxes). Because anything else would be silly.
Currently, this part of the suggestion is compromised because of a bug. https://bugs.mojang.com/browse/MC-84849?jql=project = MC AND text ~ offhand This should be able to be resolved, though.
6) Locked Double Chests
I thought a great deal about how to lock double chests. Before I talk about what I decided on, let me list all the ways of solving this problem I dismissed:
1) You can't have one side locked and the other unlocked.
2) You can't have the padlock split between the chests if you break one. How on earth would that work?
3) You can't have the padlock stay on the half that isn't broken, while the other half breaks and spills its contents, or vice versa have the padlock stay on the broken half while unlocking the other half.
4) You can't have the entire chest drop as a new type of double-block/item, since that would over-complicate things dramatically (having an entirely new type of item/block, having a new mechanic to place a two block wide object).
5) You can't have the double chest be broken entirely and having it split up into two items, for the reasons for rejecting or 2) or 4).
6) You can't have the padlock just drop or break when the chest is broken, because, duh.
What I settled on was admittedly a little unsatisfactory, but the only way I could think of bar stopping double chests being lockable at all.
In order to lock a double chest, therefore, you need to padlock one half and then the other before the inventory is inaccessible. Before this, the half you padlocked is considered "locked", and will drop as a locked chest when broken, but remains accessible as long as the chest it is connected to is unlocked. Only when the other half is locked does the double chest say "chest is locked". If only one half of a double chest is locked and the unlocked half is broken, the half that is locked and hasn't been broken becomes inaccessible.
If one half of a completely locked double chest is unlocked, the inventory becomes accessible again, even though the other half is still considered "locked".
If one half of a completely locked double chest is broken, that half drops as a locked chest, while the other half stays both put and locked.
Adding to this is, if a normal chest is already locked it won't connect to a chest that's placed next to it or one it's placed next to, locked or unlocked, for the simply reason that that would make stealing its contents easy. You'd need to unlock it first, then place either chest, then lock both.
While this is the only part of my suggestion that seems unrealistic and forces you to use two padlocks and keys, I decided that it was either that or not make double chests lockable at all, which wouldn't be satisfactory either, so I went with the route that didn't limit the player's freedom ingame.
7) Breaking Locks
I decided on letting players break open locked containers for two reasons: Keys can be lost, so making entire inventories completely inaccessible might be excessively frustrating, and stealing is fun, as long as not every random schmuck with a pickaxe can do it. Rogues who plan out heists and know exactly what chest to make off with shouldn't be completely thwarted, as long as they are prepared to sacrifice some xp levels (read: time) to do it. Base protection should be for thieves as well as vandals, and, while padlocks and keys can help against greed, I don't think they should be the be all end all.
What happens to a locked block when it is unlocked is simple: It becomes unlocked, nothing else. The padlock is "removed", though there is no "broken padlock" item which the player recieves, so the key becomes useless. You receive the newly unlocked block in the rightmost slot of the anvil, while any items that were in its inventory drop to the ground around you.
I decided on the anvil because what better place to literally break a lock and what better to force a player to sacrifice than levels? Levels are relatively costly, can scale, can be spent and are already somewhat abstract with no basis in reality. Any item wouldn't scale, or make sense (you wouldn't need more lockpicks to open a full chest than for an empty one, for example, and if you did, why?), and a tool could never be expensive enough and make some modicum of sense.
Through back and forth with ScotsMiser I decided on copying a system already in the game in order to calculate the amount of levels a player would need to spend, namely, the way comparators calculate their redstone output. This was to approximate the xp cost to how valuable the inventory might be, and make sure chests full of (possibly enchanted) tools were not cheaper to open than chests full of dirt. While the system is a little complicated in how it calculates the amount, all this calculation is done by the game, and players needn't be confronted with it - only with the end result, which is why I deemed it a good idea.
How this system works is follows: The amount of xp levels a player needs to pay to open a block's inventory is determined by calculating to what percentage each slot of that inventory is filled, adding these percentages up, then rounding up to the next xp level.
A couple of examples:
1) A hopper has one slot filled with 64 blocks of cobblestone. 64 is the maximum amount blocks of cobblestone stack up to, so it is a full stack, 100% filled, or 1 stack. The rest of the slots are empty, so have 0 stacks. Since a hopper has five slots, it calculates 1 + 0 + 0 + 0 + 0 = 1 xp level. You need to pay 1 xp level to break open the hopper.
2) A hopper has one slot filled with 64 blocks of cobblestone (1 stack), one slot filled with 16 eggs and one slot with a hoe. The eggs only stack up to 16, so it is also a full stack (1 stack), and the hoe doesn't stack, so it also counts as 1 stack. The other two slots are empty (0 stacks). To break open this hopper you need 1 + 1 + 1 + 0 + 0 = 3 xp levels.
3) A hopper has one slot filled with 64 cobblestone (1 stack) and one slot filled with 32 cobblestone (50% filled, or 0.5 stacks). The rest of the five slots are empty (0 stacks). The xp levels are first calculated by adding 1 + 0.5 + 0 + 0 + 0 = 1.5, which is then rounded up to 2 xp levels.
4) A hopper has one slot filled with 64 cobblestone (1 stack), one slot filled with 4 eggs (25% of a stack, or 0.25 stacks) and one slot with a hoe (1 stack). The rest of the slots are empty (0 stacks). You calculate 1 + 0.25 + 1 + 0 + 0 = 2.25, which is then rounded up to 3 xp levels you would need to pay.
The maximum amount that it is possible to pay with this system is 27 xp levels, when breaking open a chest or shulker box.
This part of the suggestion is as of now not possible, because the offhand doesn't show up when accessing blocks such as anvils. This would need to be tweaked, and the suggestion for it is here: https://www.minecraftforum.net/forums/minecraft-java-edition/suggestions/48925-small-suggestions?page=666#c13908
This was part 1 of my suggestion. Part 2 will cover all the features that could be added in addition to the above, but are not part of the core suggestion.
Part 2: Everything Else
Being able to lock doors (and trapdoors, and fence gates) is the natural thing to think of after being able to lock chests and inventories, however, there is less reason for it to exist than the above - after all, the schmuck with a (pick)axe can just tunnel through or around. That said, there are still a number of ideas why I think locking doors (as in, not being able to move the door from one state to the other without the key) is still a good feature to implement:
1) It would work well for adventure maps in adventure mode, since then the schmuck actually needs a pickaxe, and might not have one. Actually having a key item removes the hassle for mapmakers to program something that would be bog-standard in most adventure games.
2) You could control villagers more easily, without having to block doors with blocks. For the aesthetically minded dict- I mean, caretaker.
3) Being able to lock iron doors and trapdoors in an open or closed position gives builders more options - this would mean locking a door, trapdoor or fence gate would stop redstone opening it.
4) If nothing else, it might give you a few extra seconds to prevent someone entering... somewhere.
Locking Mobile Inventories
The next natural thing to think of after locking door is locking all the mobile inventories on minecarts and animals. This would work exactly like locking block-inventories: Shift-right-click on the minecart or animal with the padlock to lock the inventory, right-click with the key in hand to open the inventory and shift-right-click again to unlock the inventory. Killing the animal or destroying the minecart drops the still locked inventory block (chest or dispenser).
The only thing that would deviate from this is the furnace minecart. Since it doesn't technically have an inventory you can access I would be fine with just excluding it fro this suggestion, but you could technically lock it to prevent coal being added. I don't know why anyone would want that, but hey, might as well strive for completion. (Note: I don't actually want this. I just don't want to redo the image I made above.)
Now come the suggestions with are to do with extra convenience. You might have noticed that, since every key takes up on slot of your inventory, you wouldn't want to lock very many inventories (or doors, trapdoors and fence gates). I noticed this too. Aren't we are smart bunch of people? But I have thought of a solution: Keyrings!
Keyrings are for keys what sand and ball-pits are for kids: Places/things you can put them so you can go off and enjoy the finer things in life. (Disclaimer: Please don't abandon your kids.) Keyrings let you combine multiple keys (and their NBT data) into one item. There's no upper limit to the amount of keys you can put on it.
Keyrings are crafted using four iron nuggets, like so:
Keys are then added to it by crafting them together with the keyring:
Right-clicking on the inventory (or door, trapdoor or fence gate) with the keyring will open that inventory (or door, trap- I'll stop) as long as the key that locked that... object is on the keyring. Shift-right-clicking removes the padlock from the object and the key from the keyring, placing the combined item in another slot of your inventory. This is also the only way of removing specific keys from the keyring - no other method besides a GUI would let you specify what key to remove.
The other method of removing keys would be doing so one by one, in a crafting grid. Keys would be removed in the order they were put on the keyring, or depending on where they were on the list of keys in the NBT data:
Since every key would retain its NBT value, it would also keep the name it had, if it had been named in an anvil.
The second suggestion to do with convenience would be being able to make copies of keys. Just like with maps and with books, keys are things that might benefit from having copies made. From having multiple keys in case you lose one, to communal chests (or giving your friends the ability to access your chests).
As the above image shows, copying keys would be similar to how maps and books are copied. You craft your key with one to eight iron nuggets, and one to eight keys are created while the original is returned to your inventory. This can also be done using the padlock.
These copies are all named "Copy of Key", with "Key" being replaced by the name if you had renamed it. Instead of as with books, however, this can only be done with the original - none of the copies can be crafted with iron nuggets. This limits the damage that can be done by rogue copies.
What's interesting about the copies is that they can't be used to unlock stuff. You can use them to open the things their originals have locked, but shift-right-clicking with them on the locked object is no different from right-clicking. This fact means you can feel safer giving your friends these keys, and means you might want to carry around a copy of a key instead of the original, in case you die and lose it.
Keyrings would accept copies of keys, though the only way to remove them would be to painstakingly uncraft them. You could technically add multiple copies as well as the original to a keyring, but this wouldn't change its function.
This was my suggestion. Feel free to critique it! (Not that I could stop you.) And feel free to suggest additions or changes of your own.
05.09.18 Explicitely stated the fact you can open locked blocks with the key in hand without removing the lock.
06.09.18 Added changelog.
06.09.18 Added the problems with the current offhand.
11.09.18 Changed how to calculate how many xp levels are necessary to break open locked inventories on an anvil. Cleared up confusion on other parts.
26.02.19 Added multiple possible additions to the core idea.
Gold is one of the ores that can be used to craft Tools, Weapons and Armor, However, its rarely used to craft such items, because gold items have terrible stats
Golden swords deal as much damage as wooden swords, and have even less durability.
Golden Armor in general has both less durability and protection compared to iron, although its more rare.
Golden tools have less durability than wooden tools, but they excel in having the highest mining efficiency among all tools.
Except for one stat golden items excel at; Enchantability.
Without complex explanation of Enchantability, basically, what it does is that it increases the chance for having better enchantments, you can read further Here
Golden Items have the highest enchantability (25 for armor and 22 for tools/weapons), compared to diamond, which has the second highest enchantability after gold (10 for tools, weapons and armor), Golden items have very high enchantability, yet still, they are useless because of the low stats.
The idea here is to alter the Enchantability mechanic, to give it a stronger, and clearer impact on the system.
Respiration[/b] Level III : [/b]just stronger than I and II at the same rate
Depth strider[/b] Level III : [/b]just stronger than I and II at the same rate
Knockback[/b] level III :[/b] just stronger than I and II at the same rate
Looting[/b] level IV[/b] :[/b] just stronger than I,II and III at the same rate
Unbreaking[/b] level IV and V[/b] : resistance increases with the same rate
[b]Thorns IV [/b]: 60% proc chance, doesn't drain durability on proc, deals Thorn damage to all surrounding enemies.
[b]New Enchantments (Yellow Levels are exclusive to golden items)[/b]
Mark for Death[/b] - Swords
Attack target receives more damage from any source except weaponry enchanted with death curse.
( I ) 15% increased damage received, lasts 6 seconds
( II ) 25% increased damage received, lasts 7 seconds
( III ) 35% increased damage received, lasts 8 seconds
Arcane[/b] - Swords and Axes
increases XP gain from kills
( I - III ) increases XP drop by 10/20/30%
( IV ) increases XP drop by 50%
Armorer[/b] - Chestplate
provides bonus armor to near players of the same team and tame animals (horses, wolves, cats).
( I ) bonus 2 armor levels
( II ) bonus 3 armor levels
( III ) bonus 5 armor levels
( IV ) bonus 6 armor levels
Fertile[/b] - Hoes (though you usually want your hoes not Fertile :P)
increases growth speed on farm pods made by enchanted hoes, effect is lost after the plant is harvested and needs to be hoed again
( I ) bonus 15% growth speed
( II ) bonus 30% growth speed
Hammer strike[/b] - Swords and Axes
Multiplies damage dealt to the enemies armor.
( I ) ×4 damage to armor
( II ) ×8 damage to armor
( III ) ×16 damage to armor
( IV ) ×32 damage to armor
Leader Strike[/b] - Swords
makes attack targets especially vulnerable to companion attacks (dogs and golems only for now)
( I ) 35% increased Damage
( II ) 100% increased damage
Assassin[/b] - Swords
Limited only to golden swords, makes the sword invisible if you are invisible (potion effect)
( I ) only 1 level
Storm[/b] - Swords
grants a chance to make a thunderbolt that appears between you and target, then bounces to other nearby mobs. bolt damage is dealt as a separate damage instance, and couldn't bounce to already hit enemies until no more un-hit enemies could be found in search radius. Drains 4 durability when it acquires, except on golden swords, it drains the normal amount. has got a 20% chance of acquiring and deals 2 damage
( I ) 2 bounces
( II ) 3 bounces
( III ) 6 bounces
[b]Spectral Edge [/b]- Swords
Grants full armor penetration, can't be combined with bonus damage enchantments
( I ) only 1 level
and paste anything onto signs. Just to clarify, I am not asking for multiple signs to be copy and pasted. I am asking for a way to copy and paste any sorts of characters onto signs. I want this because I really like to make my signs look pretty. To be fair, you can already copy and paste things when naming so I don't see why this shouldn't be added. Here is a poll for votes (come on people)!
Also, if you still think I want to make multiple signs, here is another explanation
When you highlight and press Ctrl + C and then paste it with Ctrl + V
Come on guys!
Thank you so much.
Seeing the attention the Book and Quill are getting now and days I figured I'd add some features I'd like to see.
1) Ability to add images of items to the Book via Alt+hotbar slot or by dragging said item over the Book when typing. This would not consume the item.
2) Maps would be added to Book talking up most of the page(Maps are stored via map_id so this should take very little data).
3) Colored texts, though this can be done right now it's not intuitive.
4) Custom book covers via banners?
Anyways, what do you think of these ideas?
which are good?
are they all bad?
Either way I'm excited for 1.14. woot!!
I have an idea to help keep the game from getting stale potentially without costing much in terms of development resources. The idea is to have an alternate overworld on the map, laid out in a "checkerboard" pattern in which the tiles are (for example) 16,384 blocks across and the origin (0, 0 coordinates) is centered in an overworld-1 tile. The edge between overworld-1 and overworld-2 would not be sharp, rather it would change along biome edges. A biome on the edge would be counted as being in whichever side it was closer to.
The alternate biomes of overworld-2 would be very similar to the biomes we're familiar with in overworld-1, but with subtle changes:
Trees - OW2 has an alternate set of tree types:
Oak -> Elm
Birch -> Poplar
Spruce -> Pine
Jungle -> Mangrove
Dark Oak -> Willow
Acacia -> Baobab
Each alternate tree would use the same wood and leaves as the primary, however it would be shaped differently. It could also drop saplings for its own special tree type. The way this could be done is that the leaves naturally on the tree look like their OW1 type but are different internally, yet still yield the same leaf blocks of their OW1 counterpart.
Subtle biome variations - Some biomes could generate slightly differently:
Tall Birch -> Tall Poplar - generates trees more frequently since they are a narrower tree.
Jungle -> Mangrove Swamp - tends toward a lower altitude towards the center of the biome, with flatter terrain and more water coverage like a swamp, but thick with the mangrove trees and underbrush like the Jungle. Half of the jungle temples are witch huts instead.
Desert -> Sandstone Desert - generates sandstone at the surface and sand occurs in patches. Has saguaro cacti (with arms) or perhaps little decorative cacti of which you can place up to 4 on a block.
Giant Spruce Taiga -> Giant Pine Taiga - no mossy cobblestone boulders but a complete podzol coverage over the entire floor.
Badlands -> Wasteland - stone mountain cliffs with mixed gravel and coarse dirt on the flat parts of the biome. The stone cliffs are layered with different kinds of stone: stone, andesite, granite, diorite, sandstone, red sandstone with terracotta on some layers. Fossils can generate poking partway out of the ground.
Dark Forest -> Weeping Forest - The biome is thick with willow trees which due to their shape create a canopy while allowing sunlight to enter the undergrowth frequently. Instead of huge mushrooms, the forest floor is littered with small mushrooms.
Structures - Some structures could have variations:
Woodland Mansion -> Mountain Mansion - occurs on the flat parts of mountains biome and uses spruce wood instead of dark oak. The huge structure towers over the landscape.
Stronghold - silverfish spawner placed in a separate room from the end portal frame.
Abandoned Mineshaft -> Flooded Mineshaft - filled with water and has the occasional sea pickle cluster.
Flooded Caves - the world could have all caves flooded from, say, y=30 and lower. The lava at y=11 could have a layer of magma over the top.
Dungeon - dungeons could have multiple rooms and a few hallways, perhaps more than one loot chest. The extra halls and rooms would make the structure easier to find but would make it take more time to get through, giving more time for enemies to spawn in.
Land Shipwrecks - rarely shipwrecks occur in desert or wasteland terrain, indicating the land was once submerged underwater.
Once the code has been put in to change the world in this way, variations can be gradually added later. You could play for many weeks and never see this alternate world, but if you travel far then you are likely to see it.
Wither skull turret-like objects can rarely spawn on parts of Nether Fortresses that are exposed to open space, usually no more than 2-3 per fortress. They would look something like the below image (although bigger and more visible), with eyes that glow in the darkness when they detect a target.
They fire Wither Skulls every 5 seconds at the player and any other non-Nether mob within 48 blocks of it, prioritizing whoever is the closest. The skulls have the same speed and damage as normal Wither Skulls; however they don't damage any blocks. Hitting the turret with an arrow or trident damages it and causes it to fire slower blue skulls that can be reflected back, but also makes it invulnerable to other arrows/tridents.
The turret can be deactivated by an explosion, reflected skull/fireball or melee attack, which turns it into a regular wither skeleton skull that can be collected. Alternatively, hitting it with a skull/fireball only temporarily deactivates it, and to destroy it for good you have to break the block under it instead. This could be a rare and non-renewable source of Wither Skeleton skulls, as well as a sort of "ranged defense" mechanism for the Nether Fortress.
There’s not many ways to decorate your house in Minecraft. I’ve noticed a lot of people who want to make a huge mansion, but then realize that besides filling up your chests there isn’t much to do with your house. Seriously, how many paintings can you hang on your walls? Minecraft builds, whenever creative or survival, would benefit greatly from more decorations. Therefore, I’d like to suggest a new decorative item- the Statue.
Statues have been around since before ancient times, and have historically been used to represent people or animals. In Minecraft, statues would be a dynamic new way to document player progress, decorate your house, and alter the spawning of certain mobs. Each statue would be a “stone” replica of a certain mob. All mobs in the game would be represented, plus special Steve and Alex statues.
A rough model of a creeper statue.
The primary use of statues would be for decorative purposes. You could put statues on empty walls in your house, as centerpieces to fountains, or even to create a whole “museum” filled with statues. The sky’s the limit when decorating with statues! (Seriously, you can’t place statues over y 256)
Statues would be .95 scale replicas of their respective mobs. For example, a 2-block high zombie would 1.9 blocks tall. This is to accommodate space for the “platform” at the bottom of statues. The size of the statue might affect its purpose in the game- silverfish statues could be little trinkets on tables, while ender dragon statues might take up entire rooms!
You can construct statues of mobs after you have killed said mob. Therefore, you can only have a Wither Statue is you have defeated the Wither, and so on and so forth.
You can only have this guy if you’ve killed a Wither.
Statues would be constructed with a new block to PC, the Stonecutter.
Some of you may know that the stonecutter used to be a block in Pocket Edition. The old stonecutter was a crafting table for only stone blocks. The block was very tedious to use, and has since been removed. The new stonecutter will be nothing like its predecessor, save the name and texture.
Stonecutter crafting recipe
Stonecutters would be crafted with a sole iron ingot, surrounded by six cobblestone, a lever, and redstone. The iron symbolizes the gear, and the cobblestone the surrounding stone. This recipe would make stonecutters easy to make, but not too cheap that they could be made within the first couple of days. (Thanks Wolftopia for the revised recipe).
As you can see, the stonecutter’s interface is comprised of a single arrow, two large squares, and three smaller squares off to the side.
In order to create a statue, the player has to fill the three smaller squares with a stone block. This can be any block that is related to stone- cobblestone, andesite, etc. The stone block put into Stonecutter doesn’t affect the output and is consumed after the statue is created. They serve as “fuel” blocks that add a small price tag to building statues.
Alternatively, one could fill the three squares with gold ingots to create a Golden Statue. Golden statues would be an expensive way to show off. They would also give another use to gold, which is always forgotten between iron and diamond. Golden Statues could also help with egyptian and fantasy builds. (Thanks Lord_Garak for this idea).
A golden pig statue.
The large square to the left of the arrow is where input goes. The input is what determines what mob the statue represents, and varies from statue to statue. It’s always a drop, to ensure that the player has indeed fought/discovered that mob.
Most of the drops would come from the mob. However, some mobs don't have unique drops. The solution to this problem is making the input an item that typically associated with the mob in question. However, you could only build the statue after you have killed the respective mob. For example, if I put a mushroom in a stonecutter without having killed a mooshroom, nothing will happen. After killing a mooshroom, infinite statues can be made with mushrooms (provided you have enough mushrooms).
Mob variants would be built by using the drop of the normal mob (as they are nearly the same). By default, the output will show the normal mob. Right click to cycle between variations. You must kill the said mob variant for it to appear in the left click cycle
Once the input and three stone-related blocks have been put in, the Stonecutter will get to work at creating a statue! Statues take 15 seconds to create, and is measured through the arrow. While constructing, the Stonecutter would emit a unique gear or drill sound.
When a statue finishes, all blocks used to create it will be consumed. The statue will then appear in the large square to the right, ready for use.
Three statues would not be created through the Stonecutter- those being the Villager, Steve, and Alex statues. Villager statues would spawn in villages. There would always be one statue, typically spawning in a church or an open space near the middle. 5% of the time the village will spawn with a golden villager statue. Villager statues would represent finding a village.
Steve and Alex statues would be rarer. They would be found in chests all over the Overworld, from blacksmiths to dungeons to woodland mansions. These statues could represent the player.
The rest of the statues would be exclusive to the Stonecutter, and would not naturally generate.
Statues would have many other uses besides just décor. They would also prove in-game proof of player progress. This is something that I've always felt Minecraft has been lacking. We have advancements, but they’re linear and more for goals, rather then a way to look back at what you've done. Currently, there’s no way to proudly show off how you slayed an elder guardian, had a loyal pet, or discovered a mushroom island.
Because they’re so dynamic, each Minecraft statue would tell a story. Compare that to painting, which just randomly generate from a small number of presets. You could document that awesome trip to the Nether when you killed three Ghasts, or create a proper memorial for your wolf. You could set out to kill every mob in the game, and show it with statues.
Besides documenting your progress, statues would also be awesome for just decorations. How awesome would it be to have a Wither statue in front of your base? Or perhaps using villager statues to recreate the Terracotta Army!
You could also bring statues to life (with cheats of course). The command would be /statue <x y z> alive. Mapmakers could utilize this command to create some awesome sequences! Thanks coolcat430 for this great suggestion
Statues could also be put to great use in creative mode. In real life, architects constantly use statues to add detail to otherwise plain buildings. Statues would be a game-changing asset to builders. When you start thinking about it, nearly every build would benefit with them.
One final use of statues would be altering the spawn rate of certain mobs. When placed, a statue would start affecting the 5x5x5 area around it by causing its respective mob to spawn 5% more commonly, while every other mob would be reduced by 2.5%. It wouldn’t be a huge difference, but still a slightly noticeable one.
This would primarily be used to help with mob farming. However, the 5% bonus is only added at the beginning of mob-spawning algorithm. So as long as you have torches by your zombie statue, you can safely exhibit in your house. Likewise, placing a sheep statue on your wood flooring would not magically give you sheep (since sheep only spawn outside).
Of course, some statues wouldn’t affect mob spawning at all- ender dragon statues would never spawn an ender dragon, and blazes, even if with a light level of 0, would not spawn in the Overworld. Steve and Alex statues wouldn’t affect the spawning of anything.
Gold statues would be extra powerful, increasing the spawn rate of their respective mob by 20% and decreasing all others by 10%. This would provide further incentive for players to build the more expensive gold statue.
As I said before, the real use of this feature would be for mob farms. Statues would allow players to interact with their farms with an unprecedented level of customization. You would be able to create monster farms for each mob, and increase the productivity of your animal pens. For example, a smart player might place a pig statue in the middle, or underneath, their pig pen.
In conclusion, statues would be a new way to decorate, document progress, and assist in mob farms. They would be a great asset for builders and help hardcore survivalists.
They’d also be a great way to show player progression. By decorating your base with statues, each player base would be unique to each individual player. They would each tell a story, from the time you killed your very first zombie to that super complicated wither skeleton farm you’ve started up. If you did it, you can show it.
Finally, who doesn't want to have a giant Ender Dragon statue on their roof? I sure want one!
Recently, Mojang announced that they would be adding a feature called the "Super Duper Graphics Pack" (SDGP) to the non-Java versions of Minecraft. This brings many modern rendering techniques to the game, before only seen in PC shaders. Whether or not this looks good is subjective, but most likely anyone looking at it would still recognize the blockiness game.
Written in a better rendering engine, like Direct3D or Vulkan, Minecraft 2 would be able to take advantage of more efficient rendering techniques and have improvements to it to have modern graphical effects, such as seen in the SDGP. In addition, I've got an idea that could "fix" sunlight, allowing for Cubic Chunks.
Disclaimer: as I have never programmed a rendering engine, I do not know exactly how to implement most of this. Some mechanics may also require a restart if they are modified.
Okay, I'm not really fixing the sunlight problem. I'm actually just going to ignore it. Lighting, instead of being a mechanic determined by a block's light level, will now be purely aesthetic. This will allow for many new effects in lighting, including colored lights, dynamic lights, and more realistic shadows. Sunlight will also be affected by this, and would only cast shadows from blocks that are currently rendered (this would mean floating islands or high ceilings that are above render distance will not cast a shadow, but I believe it's a small price to pay). Since light would no longer have a major effect on gameplay, the only remaining cons of such a system would likely be greatly outweighed by all the pros of cubic chunks. Systems such as mob spawning and crop growth would no longer be effected by lighting and would be handled differently (which I'll detail in future suggestions in this series).
Sunlight would have a slight yellowish tint to it during the day, and have a more pinkish tint during sunset or sunrise. These colors would be modified slightly depending on the biome the player is standing in (the sunlight might have a green tint in swamps, and sunsets might be more red in deserts). Moonlight would be blue, and its strength would be modified based on the phase of the moon, being strong when full and practically non-existant when new. Sunlight and moonlight will decay rapidly 32 blocks below the global surface value, getting weaker for every block of depth beyond that, and at 64 blocks below, will stop being rendered entirely (caves are going to be much deeper than in the current game). This will prevent abnormally large underground rooms from being lit by sunlight with a low render distance, as well as save on performance, though it could be an issue for players who decide to build at that depth. For performance reasons, the game will only render either the moonlight or the sunlight, but never both at the same time (during sunset or sunrise, the lighting will transition to a weak ambient light, and then to the opposing global light source).
As you've probably guessed by now, the new lighting system will include colored light. Beyond your standard torch, there will be many light sources, and several will have the ability to give out a color other than yellow. Light passing through translucent colored blocks would be tinted depending on the base color of the block (light passing through red stained glass will always be pure red, even if you've retextured it to be purple or several colors).
Dynamic lights will also be a thing. They aren't really laggy when implemented correctly, though with the addition of shadows, they will have more of an effect on performance than the current dynamic lights mod, but not by much.
For performance, players will be able to adjust the light quality in their video options. Low quality will have low-resolution shadows and colored lighting will be disabled. Medium quality (default) will have a medium shadow resolution (comparable to the shadows made by sunlight in the original Skyrim). High quality will have high-resolution shadows and light going through transparent/translucent blocks will take into account the opacity of the individual pixels on the block. Ultra will be like High, but will also take into account the colors of the individual pixels on the block the light is passing through for colored light.
(Based off Ouatcheur's idea) Chunks, when they come into or out of render distance, will fade into or out of view, and any shadows they cast will fade with them. This will make the shadows transitions not as jarring.
Volumetric God Rays will also be a thing. By default they are disabled, but can have their quality cycled between low, medium, and high. Higher qualities will increase the density and distance of God Rays.
This applies some feathering around the edges of objects to reduce the jaggedness of diagonal lines. It can be set to off, FXAA (cheap, "fake" anti-aliasing), 2x, 4x, 8x, and 16x.
Bloom is an effect where a small amount of blur is composited into the rendered frame to add a more "film-like" effect. It causes bright pixels to "bleed" into dimmer pixels, and the effect is greater the higher the contrast. It is enabled by default.
Depth of Field
This causes blur on pixels which are a certain distance away from wherever the camera is focusing. It can be set from 0-100, where 0 is disabled and 100 causes only pixels the exact distance away from the focus to be in complete focus.
All textures can optionally have an additional texture (textureNameBM.png) which gives them a bump map. A bump map is an invisible texture put on top of an existing one that tells the game how to shade the texture. This simulates depth even when the surface the texture is on is completely flat, and is used in most modern games. It is enabled by default.
Some surfaces are reflective, such as glass and water. There are three settings available for this, one for liquids, one for blocks, and one for items. All three would have four quality settings, from disabled to high, and would affect the resolution of the reflection, as well as the quality of the distortion filter applied. Liquids and blocks are set to low by default, while items are set to medium by default.
This applies a smaller resolution of a texture on far-away blocks. It is similar to the current mipmaps setting, going from disabled to four levels of mipmapping. Blocks far enough away to be using mipmapped textures would have their bump maps disabled.
Connected Textures and Random Textures
The game would come with connected textures support, accomplished by making a folder with the same name as the base texture, and including all the textures as well as a text file that says how they all connect. There would also be random textures available, whose usage are also specified in the text file. They are enabled by default.
Well, I think that's it. If you can think of anything else, I might add it. Keep in mind that these mechanics will require a more modern graphics card to play the game, though if your card is old, you may be able to get by if you set everything to the lowest possible quality. Now that we've got the background stuff out of the way, though, we can now move on to the meat of this series, actual game mechanics! Stay tuned for part 3!
Note to Critics-Please Read
Why we could use a Minecraft 2, and what the goals of a sequel would be (in my eyes)
Now, I think you understand that I want a new experience, but certainly there must be more to justify the time and resources into a sequel? Well, I've got a bunch of ideas, but it would make this suggestion a wishlist to include them all, so I'll just give you an idea of the guidelines I'm following for these suggestions:
Now, I'm not going to get too technical with this, as I'm sure that would be gibberish to a lot of you, and frankly I'm only an amateur programmer myself. However, there may be some basic programming terminology mentioned in this, such as a class, which is basically just a section of code meant to handle a specific thing.
Minecraft's current engine is in need of a lot of work. The code is convoluted, filled with "spaghetti" code, and runs inefficiently. The names of the classes are obfuscated, which is supposed to prevent piracy, but mostly serves only to break mods between versions. However, instead of just rewriting it, how about some new features as well? In addition, what about some background information, like development and platforms?
Note that this suggestion will only talk about the game engine. Other engines, such as the rendering engine, will not be discussed in this suggestion, though they may be discussed in later suggestions in this series.
The Game Engine
All platforms of the game would be written in the same language, probably C++. This would allow for cross-platform play across all versions (where the platform owners allow), and all versions could easily be updated at the same time. The engine would likely run on DirectX 11, which would allow for better graphics and better performance. This would, unfortunately, increase the system requirements a bit, but most modern computers should be able to run it.
Minecraft 2 would be developed by a whole new team hired by Mojang to work on the game (Mojang YZ?) while the original team continues to work on the original game and provides guidance. Thus, we would still get updates to the prequel during the time (likely three or four years) it takes the sequel to develop. As for after release, I assume the original Minecraft would get one more update, and then only get bug fixes. The game would be released on all major platforms simultaneously (Xbox One, PS4, Switch, Mobile, Steam, and Windows App Store).
Well, that's all there is for the engine, as while it's integral part of the game, it's not very interesting to discuss, and most people only see the game itself, and not the engine behind it. Still, there is loads more about Minecraft 2 to discuss, but I will save them for later entries in this series to avoid this being considered a wishlist. Stay tuned!