The recent Minecraft update's (13w04a) bonemeal nerfing made me think that such a thing should not be part of a 'redstone' update, but of a "farming' update. And then that started me thinking about farming crops in general and that getting food (from crops) is just way too easy.
Take a typical 'small' farmland plot: 9x9 farmland size with a water block in the center. From side to side, you have your crops in happy little rows: pumpkins, melons, carrots, potatoes, and 2 rows of wheat. Nice and simple.
By the time you return from a single relatively small mining trip (mining is usually a 'high-hunger' activity), your farm's already ready for harvest! And even from such a relatively small plot, you will get enough food for several more mining trips.
Heck, you won't even have time to finish harvesting and replanting, that new stuff will already be ready to be harvested again! Being unable to ever "fully complete one round of farming", even on small plots, is actually quite frustrating, at least to me.
There is just so much food, I can go mining for hours and hours on end using only a fraction of only a *SINGLE ONE* of the types of food I make. That's just ridiculous, way too fast, and just sad.
So I propose a discussion/analysis of how it could be improved in a future "farming" update.
Instead of making almost all plants mature in approx 1-2 Minecraft days, they should mature much more slowly.
(-A-) Make the game have only 1 block update per tick instead of 3.
This would take care of a factor of 3 right here and there.
Apart from plant growth, other things would be affected too:
- Fire burning out? No biggie, currently it happens way too fast. Try to check the roleplay of new players trying their new fireplace in their nice little house, and see the deception as their fire sputters out way too soon to their taste.
- Fire spreads out too slow? Hmm, easily fixed, because fire did spread out too fast before, so this means a value was changed somewhere, so just put that value back up by a factor of 3 and you get the same result again.
- Farmland becoming hydrated? It's already so fast and unimportant now that nobody cares, so 'meh'.
- Leaves decaying slower? If you're that much in a hurry, just break them by hand, otherwise they'll drop after 2-3 minutes (on average) instead of 70 seconds, whoopeeedoo, players should just continue doing like they already do anyway by not being stupid enough to just stand by idly waiting for leaves to fall, after all one quick trip to a felled trees area every 5 minutes is enough to grab the saplings before they despawn.
- Ice melting slower? Ok, now, that could seem weird, but surely it's not weirder than torches lasting forever, right? Personnally, I'd prefer my ice walls not to be destroyed quite as fast, mind you.
- Lava flows lasting seemingly forever before disappearing? They already do, so no biggie there either, just continue doing the usual trick and gravel them into oblivion.
So yeah, overall, I think reducing block updates from 3 to 1 per tick would definitely way more thasn it would hurt. And that's even before taking into account the reduction of server processing load!
(-B-) Any light that is not sunlight grows stuff 4 times slower than sunlight.
This is because artificial light works 'around the clock', while sunlight lasts only a bit over half the daynight cycle (plus, some days are 'bad weather' days). So overall sunlight would grow stuff twice as fast as for an underground farm. Adding torches to a sunlit farm would give an extra speed boost of about 25%. Those figures seem about right to me.
(-C-) Adjust growth rates according to common sense to get a nicer, smoother and more instinctive "range" of growth speeds.
There is a big difference between making something "realistic" (which Minecraft definitely doesn't have to be) and making it have "common sense" or making it "make sense internally as a game" (which Minecraft should have more of).
Currently, Reeds grow 6 times faster than the rest. That is too big a difference. Currently, a tree requires about the same speed to grow as most plants do, and this doesn't feel natural at all, while also not making much sense for something that uses up much more processing to create (when compared to other crops).
I propose to use a "natural feeling" of how quick things grow, and attribute speed accordingly, without too big a spread, maybe like this:
Things that grow... (in about that amount of time in real life) [Examples]: Speed
---------------------------------------------------------------------------------
Really fast (weeks) [Grass]: 300%.
Fast (months) [Reed aka 'Sugar Cane']: 200%.
Normally (seasonal/yearly) [Wheat, Carrot, Potato]: 100%, the "normal speed" for "normal crops".
Slowly (some years) [cactus, Birch Tree]: 50%
Really slowly (lots of years) [Oak Tree, Spruce Tree, Jungle Tree]: 25%.
One of the game's aspects that attract players is it's simplicity, so instead of having EACH crop have its own specific growth speed value, crops are defined as being of one of the 5 "easy to remember" speed categories. Note also how the numbers are very easy to remember and represent a real, and thus noticeable, yet not exagerated, difference of values.
(-D-) The penalty for planting crops not in a line should count more and be better computed.
Comparing a "best speed" farmland plot A (spaced rows) vs a "fully packed" farmland plot B:
- Construction time: B wins by a factor of 2.
- Ease of use: B wins because it is more tolerant to positioning errors, since there is no line pattern to respect.
- Ease of navigation: B wins because it takes slightly less movement to farm it than A.
- Ease of moving around to get at something else beside or behind the plot: B wins easily because it's plot is half as big.
These speed should take into account the hydration of the farmland, and instead of checking for the amount of "same crop" not on a line, it should check for the amount of "air" not on a line and the presence of "not the same crop" on the line. Because currently
if you have rows of wheat, carrots, wheat, carrots, then you reach max density without any speed penalty.
The speed penalty should be at least x1/3, preferably x1/4, so as to avoid the fact that farming a packed plot half as often while taking less work and movement produces the same total amount of crops compared to farming a spaced-with-empty-rows plot twice as often.
(-E-) Give us back a useful hoe.
Harvesting should be doable by hoe (maybe pumpkins too). Any other "non optimal" way should give clearly reduced drop rates. This would put back the hoe as a useful and often used tool, and cut back the efficiency of automatic farming.
I sadly agree... Right now I have an automatic pumpkin pie farm; which with hoppers is crazy overpowered right now.... In finate food that is just as good as stake, and you don't have to cook it.. XD it's taken away my love for farming... I am however happy about the bonemeal Nerf. People are saying 7 bonemeal for wheat is too much, but skeletons drop upto 3 bones which is 9 bonemeal. the fact it can be automated now is only more of a good reason to Nerf it... Though it will put more pressure on people using it to grow trees... which is the backbone of mc...
Love it. I would change some things here and there and will definitely be posting my thoughts later, but overall I really like the ideas.
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!
The funny part is I was sure the mc team was trying to avoid people from having to make auto farms (at lest monster farms) but then they add something like the hopper which makes these sorts of things almost perfectly automatic.... I really hope they don't allow for automatic seed planting and animal feeding... otherwise things will become very broken very quickly...
(-A-) Make the game have only 1 block update per tick instead of 3.
This would take care of a factor of 3 right here and there.
Apart from plant growth, other things would be affected too:
- Fire burning out? No biggie, currently it happens way too fast. Try to check the roleplay of new players trying their new fireplace in their nice little house, and see the deception as their fire sputters out way too soon to their taste.
- Fire spreads out too slow? Hmm, easily fixed, because fire did spread out too fast before, so this means a value was changed somewhere, so just put that value back up by a factor of 3 and you get the same result again.
- Farmland becoming hydrated? It's already so fast and unimportant now that nobody cares, so 'meh'.
- Leaves decaying slower? If you're that much in a hurry, just break them by hand, otherwise they'll drop after 2-3 minutes (on average) instead of 70 seconds, whoopeeedoo, players should just continue doing like they already do anyway by not being stupid enough to just stand by idly waiting for leaves to fall, after all one quick trip to a felled trees area every 5 minutes is enough to grab the saplings before they despawn.
- Ice melting slower? Ok, now, that could seem weird, but surely it's not weirder than torches lasting forever, right? Personnally, I'd prefer my ice walls not to be destroyed quite as fast, mind you.
- Lava flows lasting seemingly forever before disappearing? They already do, so no biggie there either, just continue doing the usual trick and gravel them into oblivion.
So yeah, overall, I think reducing block updates from 3 to 1 per tick would definitely way more thasn it would hurt. And that's even before taking into account the reduction of server processing load!
No. Frequent block updates are a good thing for the game. It doesn't just affect the farm. No support here.
(-B-) Any light that is not sunlight grows stuff 4 times slower than sunlight.
This is because artificial light works 'around the clock', while sunlight lasts only a bit over half the daynight cycle (plus, some days are 'bad weather' days). So overall sunlight would grow stuff twice as fast as for an underground farm. Adding torches to a sunlit farm would give an extra speed boost of about 25%. Those figures seem about right to me.
Most of my farms are above ground ones, so this only really penalizes "dwarf" playstyles. Can't really see the point here. No support.
(-C-) Adjust growth rates according to common sense to get a nicer, smoother and more instinctive "range" of growth speeds.
There is a big difference between making something "realistic" (which Minecraft definitely doesn't have to be) and making it have "common sense" or making it "make sense internally as a game" (which Minecraft should have more of).
Currently, Reeds grow 6 times faster than the rest. That is too big a difference. Currently, a tree requires about the same speed to grow as most plants do, and this doesn't feel natural at all, while also not making much sense for something that uses up much more processing to create (when compared to other crops).
I propose to use a "natural feeling" of how quick things grow, and attribute speed accordingly, without too big a spread, maybe like this:
Things that grow... (in about that amount of time in real life) [Examples]: Speed
---------------------------------------------------------------------------------
Really fast (weeks) [Grass]: 300%.
Fast (months) [Reed aka 'Sugar Cane']: 200%.
Normally (seasonal/yearly) [Wheat, Carrot, Potato]: 100%, the "normal speed" for "normal crops".
Slowly (some years) [cactus, Birch Tree]: 50%
Really slowly (lots of years) [Oak Tree, Spruce Tree, Jungle Tree]: 25%.
One of the game's aspects that attract players is it's simplicity, so instead of having EACH crop have its own specific growth speed value, crops are defined as being of one of the 5 "easy to remember" speed categories. Note also how the numbers are very easy to remember and represent a real, and thus noticeable, yet not exagerated, difference of values.
Actually IRL reeds and bamboo stuff grow ridiculously fast, but I do agree more with this point. I'd put reeds and grass in the same category personally, and pines should go with birch as they are also a fairly fast growing tree. Other than that, I support.
(-D-) The penalty for planting crops not in a line should count more and be better computed.
Comparing a "best speed" farmland plot A (spaced rows) vs a "fully packed" farmland plot B:
- Construction time: B wins by a factor of 2.
- Ease of use: B wins because it is more tolerant to positioning errors, since there is no line pattern to respect.
- Ease of navigation: B wins because it takes slightly less movement to farm it than A.
- Ease of moving around to get at something else beside or behind the plot: B wins easily because it's plot is half as big.
These speed should take into account the hydration of the farmland, and instead of checking for the amount of "same crop" not on a line, it should check for the amount of "air" not on a line and the presence of "not the same crop" on the line. Because currently
if you have rows of wheat, carrots, wheat, carrots, then you reach max density without any speed penalty.
The speed penalty should be at least x1/3, preferably x1/4, so as to avoid the fact that farming a packed plot half as often while taking less work and movement produces the same total amount of crops compared to farming a spaced-with-empty-rows plot twice as often.
I don't understand what this means. Staying neutral.
(-E-) Give us back a useful hoe.
Harvesting should be doable by hoe (maybe pumpkins too). Any other "non optimal" way should give clearly reduced drop rates. This would put back the hoe as a useful and often used tool, and cut back the efficiency of automatic farming.
Meh, I suppose it gives you a reason to make a diamond hoe. If it happens it shouldn't really apply to melons or pumpkins though, as all that needs doing is to cut the stalk and pick it up. No problems with this on carrots and potatoes as underground crops. Maybe wheat should be done by shears as IRL you'd use a sythe or sickle to harvest it? Either way, some support for that part.
Rollback Post to RevisionRollBack
Why do creepers only ever show up when you're building something important?
No. Frequent block updates are a good thing for the game. It doesn't just affect the farm. No support here.
Yes, it doesn't just affect farms, and that is why I checked everything else too to see it it would "break" (or even stress) the game, which was not the case. On the contrary most of the time it would help. The thing is, frequent blocks updates for rare events are NOT a good thing mainly because they waste processing for no good reason.
Compare these two algorithms:
Algorithm #1:
- Every tick, choose 3 blocks for a 'block update'
- On a block update event, this block has 10% odds that 'something' happens.
Algorithm #2:
- Every tick, choose 1 block for a 'block update'
- On a block update event, this block has 30% odds that 'something' happens.
In the long run, both algorithms will have the same effect, the first one is just 3 times more wasteful in processing time. I propose that Minecraft simply switches from algorithm #1 to #2, while re-multiplying (by up to 3) the % odds of the events occuring for only some of all the types of block update events, and definitely not for farming.
If for some types of events they should occur more often, then to still save the processing time, block updates should simply be split like this:
Algorithm #3:
- Every tick, choose 1 block for a major block update and 2 block for minor block updates.
- On a major block update events, check for all types of events.
- On a minor block update events, check only for the types of events that need quickness/fast evolution times.
(for example, things that should occurs less fast like farming would go into the "slow" events only on major updates, while other stuff would occurs too infrenquently otherwise like lava flows reduction or fire spreading or ice melting, would occur on both major and minor updates).
This kind of approach can be refined even further to "pool" the kinds of events so that processing time is preserved as much as possible. Events could be split into let's say 5 categories:
Events that should happen...
A- Very frequently... (3 times out of 3)
B- Normally Frequently (2 times out of 3)
C- Infrequently (1 time out of 3)
D- Very Rarely (1/5 out of 3)
E- Super rarely (1/20 time out of 3)
Then on each tick, 3 blocks chosen: 1 block checked for veryfrequently updates (checks A events), 1 block checked for frequently updates (checks A B events), 1 block checked for infrequent updates (checks A B C events, also checks D events if tick counts in the current second of play is a multiple of 5, and also checks E events when tick count is reset to 0).
Just thrust me when I say I know how to optimize algorithms and do code balancing - working as a C++/assembly programmer does that!
Actually IRL reeds and bamboo stuff grow ridiculously fast, but I do agree more with this point. I'd put reeds and grass in the same category personally, and pines should go with birch as they are also a fairly fast growing tree. Other than that, I support.
I did check, and yes I agree reeds and bamboo do grow "stupidly fast" in real life.
However, the reeds in the game are actually more like Sugar Canes, which doesn't grow nowhere near as fast as "mere" reeds or tropical bamboo. If the reeds in the game produced ONLY paper, then I'd have put them in the "Very fast" category, but since they also allow to make the food item sugar, I put them in the fast category instead. It's no biggie anyway.
I don't understand what this means. Staying neutral.
I'll try to summarize differently.
The way the current algorithm was designed was to encourage players to plant its plot rows like this: wheat, empty row, wheat, empty row, etc. If you plant your wheat otherwise you get a x1/2 speed factor penalty.
However on a "wheat, wheat, wheat, wheat, etc." farmland plot, that penalty is just not big enough to compensate for the following advantages:
- less work and material needed to create the plot,
- easier to using it because when you farm you don't have to follow a particular line pattern
- easier to navigate in it because you'll have to move less because the plot is smaller
- and easier to circumnavigate it because again its smaller
- and finally the fact that its less work to get resources because to get the same amount of resources you will have to go to harvest you plot it half as often in order to get the same amount.
You just can't beat such compactness with a mere penalty factor of 2. Especially when plants grow so fast anyway.
And especially when simply by planting different types of crops in different rows, you thereby also allow players to "ignore" the speed growth penalty. If it's done like that, the penalty code might as well be removed entirely, to at least save on the processing time. Either you have a "philosophy" and you code it correctly, or you ave no such code at all, instead putting a big useless loophole, a toothless philosophy.
Initially it worked very good. This is because the algorithm was made when there was only wheat, back before carrots and potatoes. The algorithm checked for the presence of wheat in more than one directions, and is "transparent" to other stuff. Like, "gee, you have wheat growing in a wrong direction, thus, you get a penalty!". yeah you had pumpkins and melons, too, but somehow it seemed to affect the "straight line" philosophy less: these plants followed other rules, their stem seems small enough to "ignore" the penalizing effect, their fruits "isolated from the dirt" enough to also feel separate, so for that philosophy of farming the code worked okay, even though the penalty was too small to compensate for the advantages of simply packing a farmland plot 100%.
But now farmland can also grow other stuff that should also respect the "straight line" philosophy. Anything else surrounding your crop has no ill effect, duh, that goes against the "plant in a straight line" philosophy that Mojang seems to find important (personally I couldn't care less I always plant my plots 100% packed, way simpler and more efficient that way, especially since my mining trips last for hours). The algorithm should stop simply checking for "same crop type but in bad direction", for this makes it unable to make a distinction between air-over-farmland and other types of crops. It should instead check for the amount of "air-over-farmland" blocks, and penalize when _anything else_ is found, while also allowing an _exception_ for finding "the-same-crop-type-but-only-on-a-single-line", thus becoming able to make the distinction. Paired with a penalizing factor of say x1/3 or x1/4 instead x1/2, this would really encourage players to try to follow the farming philosophy their want to encourage, instead of wasting processing on a useless "big-loophole" algorithm.
Meh, I suppose it gives you a reason to make a diamond hoe. If it happens it shouldn't really apply to melons or pumpkins though, as all that needs doing is to cut the stalk and pick it up. No problems with this on carrots and potatoes as underground crops. Maybe wheat should be done by shears as IRL you'd use a sythe or sickle to harvest it? Either way, some support for that part.
I agree somewhat with the pumpkins/melons thing, however currently you already need an axe to harvest pumpkins faster. I'd also allow the hoe as a "preferred tool" there, and also apply this axe/hoe stuff to melons too. If having 2 preferred tools for such actions is too complicated, then I'd prefer to just have the hoe as the tool of choice for all farming purposes. Sure, its not perfectly logical, but it doesn't have to be so, not in a game with eternal torches, it just needs to make at least _some_ sense. Regular use of the axe is already definitely a requirement of the game (can't go anywhere without wood!), so unless both can be used, I'd gladly prefer to let the hoe have it's place to shine for all the farming stuff.
I love your idea of using shears for wheat, however shears is a more advanced item and a higher cost item because it is metal-only, and I think bread should be available without absolutely needing iron. I'd love to see shears as a full-materials tool (from wooden to diamond shears, but that is another discussion. Absolutely requiring iron shears for harvesting wheat seems a bit "costly" to me, not so in terms of the iron used, but in terms of having an early access to wheat. Maybe wheat could also be harvested with shears or hoe, but if harvested with shears, you get a 10% chance of getting 2 wheat instead of 1 (same as odds as gravel yielding flint). As for harvesting crops by hand, I'd leave it with the same drop rate, but it would not work as fast as with the tool.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Take a typical 'small' farmland plot: 9x9 farmland size with a water block in the center. From side to side, you have your crops in happy little rows: pumpkins, melons, carrots, potatoes, and 2 rows of wheat. Nice and simple.
By the time you return from a single relatively small mining trip (mining is usually a 'high-hunger' activity), your farm's already ready for harvest! And even from such a relatively small plot, you will get enough food for several more mining trips.
Heck, you won't even have time to finish harvesting and replanting, that new stuff will already be ready to be harvested again! Being unable to ever "fully complete one round of farming", even on small plots, is actually quite frustrating, at least to me.
There is just so much food, I can go mining for hours and hours on end using only a fraction of only a *SINGLE ONE* of the types of food I make. That's just ridiculous, way too fast, and just sad.
So I propose a discussion/analysis of how it could be improved in a future "farming" update.
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Instead of making almost all plants mature in approx 1-2 Minecraft days, they should mature much more slowly.
(-A-) Make the game have only 1 block update per tick instead of 3.
This would take care of a factor of 3 right here and there.
Apart from plant growth, other things would be affected too:
- Fire burning out? No biggie, currently it happens way too fast. Try to check the roleplay of new players trying their new fireplace in their nice little house, and see the deception as their fire sputters out way too soon to their taste.
- Fire spreads out too slow? Hmm, easily fixed, because fire did spread out too fast before, so this means a value was changed somewhere, so just put that value back up by a factor of 3 and you get the same result again.
- Farmland becoming hydrated? It's already so fast and unimportant now that nobody cares, so 'meh'.
- Leaves decaying slower? If you're that much in a hurry, just break them by hand, otherwise they'll drop after 2-3 minutes (on average) instead of 70 seconds, whoopeeedoo, players should just continue doing like they already do anyway by not being stupid enough to just stand by idly waiting for leaves to fall, after all one quick trip to a felled trees area every 5 minutes is enough to grab the saplings before they despawn.
- Ice melting slower? Ok, now, that could seem weird, but surely it's not weirder than torches lasting forever, right? Personnally, I'd prefer my ice walls not to be destroyed quite as fast, mind you.
- Lava flows lasting seemingly forever before disappearing? They already do, so no biggie there either, just continue doing the usual trick and gravel them into oblivion.
So yeah, overall, I think reducing block updates from 3 to 1 per tick would definitely way more thasn it would hurt. And that's even before taking into account the reduction of server processing load!
(-B-) Any light that is not sunlight grows stuff 4 times slower than sunlight.
This is because artificial light works 'around the clock', while sunlight lasts only a bit over half the daynight cycle (plus, some days are 'bad weather' days). So overall sunlight would grow stuff twice as fast as for an underground farm. Adding torches to a sunlit farm would give an extra speed boost of about 25%. Those figures seem about right to me.
(-C-) Adjust growth rates according to common sense to get a nicer, smoother and more instinctive "range" of growth speeds.
There is a big difference between making something "realistic" (which Minecraft definitely doesn't have to be) and making it have "common sense" or making it "make sense internally as a game" (which Minecraft should have more of).
Currently, Reeds grow 6 times faster than the rest. That is too big a difference. Currently, a tree requires about the same speed to grow as most plants do, and this doesn't feel natural at all, while also not making much sense for something that uses up much more processing to create (when compared to other crops).
I propose to use a "natural feeling" of how quick things grow, and attribute speed accordingly, without too big a spread, maybe like this:
Things that grow... (in about that amount of time in real life) [Examples]: Speed
---------------------------------------------------------------------------------
Really fast (weeks) [Grass]: 300%.
Fast (months) [Reed aka 'Sugar Cane']: 200%.
Normally (seasonal/yearly) [Wheat, Carrot, Potato]: 100%, the "normal speed" for "normal crops".
Slowly (some years) [cactus, Birch Tree]: 50%
Really slowly (lots of years) [Oak Tree, Spruce Tree, Jungle Tree]: 25%.
One of the game's aspects that attract players is it's simplicity, so instead of having EACH crop have its own specific growth speed value, crops are defined as being of one of the 5 "easy to remember" speed categories. Note also how the numbers are very easy to remember and represent a real, and thus noticeable, yet not exagerated, difference of values.
(-D-) The penalty for planting crops not in a line should count more and be better computed.
Comparing a "best speed" farmland plot A (spaced rows) vs a "fully packed" farmland plot B:
- Construction time: B wins by a factor of 2.
- Ease of use: B wins because it is more tolerant to positioning errors, since there is no line pattern to respect.
- Ease of navigation: B wins because it takes slightly less movement to farm it than A.
- Ease of moving around to get at something else beside or behind the plot: B wins easily because it's plot is half as big.
These speed should take into account the hydration of the farmland, and instead of checking for the amount of "same crop" not on a line, it should check for the amount of "air" not on a line and the presence of "not the same crop" on the line. Because currently
if you have rows of wheat, carrots, wheat, carrots, then you reach max density without any speed penalty.
The speed penalty should be at least x1/3, preferably x1/4, so as to avoid the fact that farming a packed plot half as often while taking less work and movement produces the same total amount of crops compared to farming a spaced-with-empty-rows plot twice as often.
(-E-) Give us back a useful hoe.
Harvesting should be doable by hoe (maybe pumpkins too). Any other "non optimal" way should give clearly reduced drop rates. This would put back the hoe as a useful and often used tool, and cut back the efficiency of automatic farming.
-
View User Profile
-
View Posts
-
Send Message
ModeratorWant 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
i'll add it to my thread found here: http://www.minecraftforum.net/topic/1662860-chilly-effect/
No. Frequent block updates are a good thing for the game. It doesn't just affect the farm. No support here.
Most of my farms are above ground ones, so this only really penalizes "dwarf" playstyles. Can't really see the point here. No support.
Actually IRL reeds and bamboo stuff grow ridiculously fast, but I do agree more with this point. I'd put reeds and grass in the same category personally, and pines should go with birch as they are also a fairly fast growing tree. Other than that, I support.
I don't understand what this means. Staying neutral.
Meh, I suppose it gives you a reason to make a diamond hoe. If it happens it shouldn't really apply to melons or pumpkins though, as all that needs doing is to cut the stalk and pick it up. No problems with this on carrots and potatoes as underground crops. Maybe wheat should be done by shears as IRL you'd use a sythe or sickle to harvest it? Either way, some support for that part.
Yes, it doesn't just affect farms, and that is why I checked everything else too to see it it would "break" (or even stress) the game, which was not the case. On the contrary most of the time it would help. The thing is, frequent blocks updates for rare events are NOT a good thing mainly because they waste processing for no good reason.
Compare these two algorithms:
Algorithm #1:
- Every tick, choose 3 blocks for a 'block update'
- On a block update event, this block has 10% odds that 'something' happens.
Algorithm #2:
- Every tick, choose 1 block for a 'block update'
- On a block update event, this block has 30% odds that 'something' happens.
In the long run, both algorithms will have the same effect, the first one is just 3 times more wasteful in processing time. I propose that Minecraft simply switches from algorithm #1 to #2, while re-multiplying (by up to 3) the % odds of the events occuring for only some of all the types of block update events, and definitely not for farming.
If for some types of events they should occur more often, then to still save the processing time, block updates should simply be split like this:
Algorithm #3:
- Every tick, choose 1 block for a major block update and 2 block for minor block updates.
- On a major block update events, check for all types of events.
- On a minor block update events, check only for the types of events that need quickness/fast evolution times.
(for example, things that should occurs less fast like farming would go into the "slow" events only on major updates, while other stuff would occurs too infrenquently otherwise like lava flows reduction or fire spreading or ice melting, would occur on both major and minor updates).
This kind of approach can be refined even further to "pool" the kinds of events so that processing time is preserved as much as possible. Events could be split into let's say 5 categories:
Events that should happen...
A- Very frequently... (3 times out of 3)
B- Normally Frequently (2 times out of 3)
C- Infrequently (1 time out of 3)
D- Very Rarely (1/5 out of 3)
E- Super rarely (1/20 time out of 3)
Then on each tick, 3 blocks chosen: 1 block checked for veryfrequently updates (checks A events), 1 block checked for frequently updates (checks A B events), 1 block checked for infrequent updates (checks A B C events, also checks D events if tick counts in the current second of play is a multiple of 5, and also checks E events when tick count is reset to 0).
Just thrust me when I say I know how to optimize algorithms and do code balancing - working as a C++/assembly programmer does that!
I did check, and yes I agree reeds and bamboo do grow "stupidly fast" in real life.
However, the reeds in the game are actually more like Sugar Canes, which doesn't grow nowhere near as fast as "mere" reeds or tropical bamboo. If the reeds in the game produced ONLY paper, then I'd have put them in the "Very fast" category, but since they also allow to make the food item sugar, I put them in the fast category instead. It's no biggie anyway.
I'll try to summarize differently.
The way the current algorithm was designed was to encourage players to plant its plot rows like this: wheat, empty row, wheat, empty row, etc. If you plant your wheat otherwise you get a x1/2 speed factor penalty.
However on a "wheat, wheat, wheat, wheat, etc." farmland plot, that penalty is just not big enough to compensate for the following advantages:
- less work and material needed to create the plot,
- easier to using it because when you farm you don't have to follow a particular line pattern
- easier to navigate in it because you'll have to move less because the plot is smaller
- and easier to circumnavigate it because again its smaller
- and finally the fact that its less work to get resources because to get the same amount of resources you will have to go to harvest you plot it half as often in order to get the same amount.
You just can't beat such compactness with a mere penalty factor of 2. Especially when plants grow so fast anyway.
And especially when simply by planting different types of crops in different rows, you thereby also allow players to "ignore" the speed growth penalty. If it's done like that, the penalty code might as well be removed entirely, to at least save on the processing time. Either you have a "philosophy" and you code it correctly, or you ave no such code at all, instead putting a big useless loophole, a toothless philosophy.
Initially it worked very good. This is because the algorithm was made when there was only wheat, back before carrots and potatoes. The algorithm checked for the presence of wheat in more than one directions, and is "transparent" to other stuff. Like, "gee, you have wheat growing in a wrong direction, thus, you get a penalty!". yeah you had pumpkins and melons, too, but somehow it seemed to affect the "straight line" philosophy less: these plants followed other rules, their stem seems small enough to "ignore" the penalizing effect, their fruits "isolated from the dirt" enough to also feel separate, so for that philosophy of farming the code worked okay, even though the penalty was too small to compensate for the advantages of simply packing a farmland plot 100%.
But now farmland can also grow other stuff that should also respect the "straight line" philosophy. Anything else surrounding your crop has no ill effect, duh, that goes against the "plant in a straight line" philosophy that Mojang seems to find important (personally I couldn't care less I always plant my plots 100% packed, way simpler and more efficient that way, especially since my mining trips last for hours). The algorithm should stop simply checking for "same crop type but in bad direction", for this makes it unable to make a distinction between air-over-farmland and other types of crops. It should instead check for the amount of "air-over-farmland" blocks, and penalize when _anything else_ is found, while also allowing an _exception_ for finding "the-same-crop-type-but-only-on-a-single-line", thus becoming able to make the distinction. Paired with a penalizing factor of say x1/3 or x1/4 instead x1/2, this would really encourage players to try to follow the farming philosophy their want to encourage, instead of wasting processing on a useless "big-loophole" algorithm.
I agree somewhat with the pumpkins/melons thing, however currently you already need an axe to harvest pumpkins faster. I'd also allow the hoe as a "preferred tool" there, and also apply this axe/hoe stuff to melons too. If having 2 preferred tools for such actions is too complicated, then I'd prefer to just have the hoe as the tool of choice for all farming purposes. Sure, its not perfectly logical, but it doesn't have to be so, not in a game with eternal torches, it just needs to make at least _some_ sense. Regular use of the axe is already definitely a requirement of the game (can't go anywhere without wood!), so unless both can be used, I'd gladly prefer to let the hoe have it's place to shine for all the farming stuff.
I love your idea of using shears for wheat, however shears is a more advanced item and a higher cost item because it is metal-only, and I think bread should be available without absolutely needing iron. I'd love to see shears as a full-materials tool (from wooden to diamond shears, but that is another discussion. Absolutely requiring iron shears for harvesting wheat seems a bit "costly" to me, not so in terms of the iron used, but in terms of having an early access to wheat. Maybe wheat could also be harvested with shears or hoe, but if harvested with shears, you get a 10% chance of getting 2 wheat instead of 1 (same as odds as gravel yielding flint). As for harvesting crops by hand, I'd leave it with the same drop rate, but it would not work as fast as with the tool.