Food decay

[Erik]

Previous threads relevant to the dicussion:

For those who don't know, the next major update will introduce a new feature: Food decay.

Food will rot and become less effective or turn into compost after a certain amount of time. Don't worry though, there will be methods of preservation introduced, so you can keep your food fresh for longer or even indefinitely at the price of more work and probably also lower nutrition. This feature is planned to be introduced alongside season, where the winter makes farming impossible. The players will have to household and plan food usage and conservation to make it through winter.

Players will also be able to deactivate the spoilage mechanic, so don't worry if you are not a fan of the general concept.

However this new decay system has some problems that I want to outline and how they could potentially be fixed. I'll first introduce the system as it is currently planned/started to be implemented:

Food items/stacks each get a timestamp when they have been created. As time goes by, they will eventually start to spoil. When spoilage reaches 100% they will turn into a pile of rot an be uneatable. Eating items with a spoilage value will reduce the saturation and nutrition gained by that percentage, so you ideally want to eat your food when it still is fresh. The spoilage of a stack represents the spoilage of each item in the stack, and they will all turn into compost at the same time.

Items with different timestamps don't stack, there will however be a certain tolerance for value differences, so stacks only a few seconds/minutes apart will still stack, probably gaining the average spoilage/timestamp of all items in the two stacks.

The problem:

The real problem with this system is the stacking limitation. It can easily result in the players having different stack of the same food, but with different timestamps, cluttering their inventory. This is a huge issue, because inventory space is already very limited in VS and micromanaging the different food stacks can quickly turn into a huge pain for players. This will be most exaggerated in the early game, because players have almost no inventory space then already and no option of storage either, as well as living from several types of berries they usually pick up some time apart from each other.

As the early game is the most important part to get right from a marketing perspective, this is unacceptable.

Possible solutions:

TonyLiberatto suggested having the timestamp only record the day of harvest. This will lead to all food being harvested on the same day stacking and while not fixing the problem, makes it much less noticeable. But this workaround comes with its own problem:

Players are rewarded for harvesting their food at the beginning of a day and are punished for harvesting them at the end of the day. This may not sound dramatic, as food harvested at the beginning of the day will only last a maximum of a day longer compared to food harvested at the end of a day. But as a day is 40 minutes in VS, that is a quite considerable amount.

A real solution to this problem would be to implement decay in the same way as Ark Survival Evolved did it: Food stacks have a spoilage meter constantly ticking down and when it reaches zero, the stacksize is reduced by one. Combining stacks would also combine the values of the spoilage bar. This system of decay works very differently and constantly spoils some food into compost rather to spoiling it all at once. Stacks can now be combined without limitations, so that problem is eliminated. 

The system however also has a huge problem: Splitting your food into two stacks makes it spoil faster than having it as one stack. This forces the player to micromanage his stacks again. This is because the rate of decay in constant and not relative to the size of the stack.

There is however a way to fix this: Rather than having a constant decay rate, stacks would just need to have a half-life. The half-life of the stack describes the time it takes for a stack to loose half its food. This half life would be the same on each stack of the same type of food. 

Example: Apples have a half-life of 4 days. A stack of 40 apples will a stack of 20 apples after 4 days. Two stacks of 20 apples will be two stacks of 10 apples after 4 days, so still 40 apples turning into 20 apples. With a half-life, the sizes and number of stacks don't matter, the same amount of food will always decay after any time.

This completely removes the need for micromanaging your stacks and makes combining them possible at all times.

There is however a small problem: That if you have 40 stacks of 1 apple? Won't they just all be gone after 4 days?

This problem stems from stack sizes being whole numbers and not having any decimal or lower values. This can however also be easily fixed by emulating the decimal point with a durability bar:

Decay will slowly lower the bar over time, until it is empty: Then the stacksize gets reduced by one and the bar is filled up again. Eating half an apple will obviously also only give half the saturation and nutrition of an apple.

This would also have other benefits, such as showing the decay in real time, having players be able to eat half an apple if they are almost saturated or crops dropping not 1 or 2 food items, but any number of items between 1 and 2 items, like 1.6 carrots (representing a carrot and a smaller one).

Problems with a half-life system:

While the player only needs to understand one thing (Half your apples will be gone in 4 days), the system is definitively harder to explain and understand. Confusing the player is never good and this system might also potentially confuse players.

The bigger problem however is, that the compost resulting form the rotting food has no way to go. In Tyrons system, it just takes the place of the food, as the food gets turned into compost at the same time. This flaw in my design will also lead to cluttering of inventory space by compost. This however isn't the big problem, as all the compost from all food stacks, but when there is no inventory space, the compost has nowhere to go. It would probably need spill on the floor, which isn't good.

Fixing all problems of both systems with one change:

Making inventories weight based would solve all problems, as there wouldn't be a competition anymore over inventory slots and better inventory management features could be implemented.

Edited June 14, 2019 by Erik

[redram]

In the context of Tony's expiration date method, I'm not sure why you say they can't be combined.  As I recall, Tyron said that the game would *automatically* stack them within a range, but you could still manually combine stacks of very different dates.  This would alleviate much of the problem.  How that combination affects the expiration is an issue.  Averaging effectively allow the player to 'refresh' old stacks, it would at least need to be weighted.  Possibly with bias.   The stricter way of having everything go to the worse decay value would probably raise cries of being unfair. 

As for the half life idea, I'm not clear how that's not just a different form of expiration date.  You're still tracking the date when the stack starts decaying aren't you?  If your stack is already 2 days into it's decay and you pick up more items and the timer is the same, then you are strictly disadvantaging the subsequent pickups.   If instead you're averaging new pickups into the pile, so they increase the half-life on a weighted average, well that's just like manually combining the expiration date stacks and weighted averaging them.   Either way, you're still creating a situation where the player is losing food over time at a rate.  It's just not smooth, but stepped.  Also your graphics confuse me, as they make it look like just an ark system.   Ark system is workable, but not realistic.

Also, I don't see a case of 40 small stacks at a problem.  Players naturally want food to stack.  I can't even think why they would ever want a bunch of tiny stacks, quite aside from any decay issues.

The advantage to the all-then-nothing expiration system (cliff system?) is the player has all their food for that a long time.  As I understand it, the current plan is the decay would occur relatively quickly at the end.  This is pretty similar to how a lot of foods - especially fruits and vegetables - decay irl in my experience.  Once that banana starts to go bad, it goes bad pretty fast.  I think generally the softer the flesh the quicker that last stage of decay happens.   Other food like bread and cheese takes longer, but still, relative to the time it is good, once that mold starts being visible, it spreads really fast.   And I could even see that final decay stag being of variable time based on the food, or maybe proportional to the initial good time.   Some foods might have an advantage like that (preferably certain cooked ones). 

The other think I like about a more a more cliff-like expiration is that it would make the possiblity of food poisoning more tolerable I think.  You'd get the vast majority of the time risk-free, but if you must eat that food in the last decaying stage, maybe there could be a chance for some kind of adverse effect (not without herbs to counter it though).

Edited June 13, 2019 by redram

[Erik]

2 hours ago, redram said:

In the context of Tony's expiration date method, I'm not sure why you say they can't be combined.  As I recall, Tyron said that the game would *automatically* stack them within a range, but you could still manually combine stacks of very different dates.  This would alleviate much of the problem.  How that combination affects the expiration is an issue.  Averaging effectively allow the player to 'refresh' old stacks, it would at least need to be weighted.  Possibly with bias.   The stricter way of having everything go to the worse decay value would probably raise cries of being unfair. 

I mentioned Tyrons method of automatically combining stacks in the tolerance frame. Obviously making it possible to combine stuff with very different dates leads to all kinds of issues and the player will need to worry about these if he wants to combine stacks. And that's the problem, the player shouldn't worry about potentially wasting freshness of food when combining stacks. So yes, they can theoretically be combined, but that makes the whole method very prone to exploits and hard for players to predict behavior.

2 hours ago, redram said:

 As for the half life idea, I'm not clear how that's not just a different form of expiration date.  You're still tracking the date when the stack starts decaying aren't you?  If your stack is already 2 days into it's decay and you pick up more items and the timer is the same, then you are strictly disadvantaging the subsequent pickups.   If instead you're averaging new pickups into the pile, so they increase the half-life on a weighted average, well that's just like manually combining the expiration date stacks and weighted averaging them.   Either way, you're still creating a situation where the player is losing food over time at a rate.  It's just not smooth, but stepped.  Also your graphics confuse me, as they make it look like just an ark system.   Ark system is workable, but not realistic.

No, the half-life would be handled constantly in real time. Half the stack of apples isn't removed every 4 days, but the stack gets smaller in real time. It doesn't even have to be constantly tracked, you can just calculate the state of an stack with the time of the last time the stack was updated, so there is not even a performance loss compared to Tyrons method.

So to get back to the apples: A stack of 40 apples with a half-life of 4 days will be a stack of roughly 28,3 apples after 2 days. Any yes, it looks a lot like the ark system, because it is a lot like the ark system, there is a constant food loss.

2 hours ago, redram said:

Also, I don't see a case of 40 small stacks at a problem.  Players naturally want food to stack.  I can't even think why they would ever want a bunch of tiny stacks, quite aside from any decay issues.

It is a problem, at least in ark. When storing multiple larger stacks in a chest in ark, they all decay into smaller stacks. The rate of decay is constant for each stack, so two stacks decay twice as fast as one stack. So when some time passes and the 40 full stacks turn into half full stacks, the rate of decay will still be the same. But if the player were to constantly restack the stacks, so there would only be full stacks and be less stacks, the rate of decay would lower. This encourages micromanagement on the players side, which is a problem.

2 hours ago, redram said:

The advantage to the all-then-nothing expiration system (cliff system?) is the player has all their food for that a long time.  As I understand it, the current plan is the decay would occur relatively quickly at the end.  This is pretty similar to how a lot of foods - especially fruits and vegetables - decay irl in my experience.  Once that banana starts to go bad, it goes bad pretty fast.  I think generally the softer the flesh the quicker that last stage of decay happens.   Other food like bread and cheese takes longer, but still, relative to the time it is good, once that mold starts being visible, it spreads really fast.   And I could even see that final decay stag being of variable time based on the food, or maybe proportional to the initial good time.   Some foods might have an advantage like that (preferably certain cooked ones). 

It may not be as realistic as Tyrons approach, but it is much more usable and I value usability over realism in this case.

2 hours ago, redram said:

The other think I like about a more a more cliff-like expiration is that it would make the possiblity of food poisoning more tolerable I think.  You'd get the vast majority of the time risk-free, but if you must eat that food in the last decaying stage, maybe there could be a chance for some kind of adverse effect (not without herbs to counter it though).

I don't think adding food poisoning is a good idea. Spoiled food is useless enough in Tyrons system, having lower saturation and nutrition. Making them potentially harmful will just cause players to get rid of them as soon as they become spoiled. In that case, it wouldn't make a difference if they were just removed from the inventory if the timer expired, with no stages of spoiling.

[redram]

 

2 hours ago, Erik said:

No, the half-life would be handled constantly in real time.....

It doesn't even have to be constantly tracked, you can just calculate the state of an stack with the time of the last time the stack was updated....

These statements seem a bit contradictory?  Or are you talking player's inventory vs in a container?

But so ok, I've never claimed to be good at math, but are you saying that the per-piece decay time is dynamically adjusted for any given stack based on the size of the stack, such that the decay of half the stack at that time would take X days?  How does this stack of Zeno's apples not end up stretching into infinity?  I see what you're doing keeping two separate stacks with the same result in X days as you would if they were in one stack, that seems to be the issue you're focused on.    But ok now your 40 stack is down to 20 after 4 days.  Well now your 20 will be 10 after 4 days won't it?  Losing 10 apples in 4 days is clearly better than losing 20.  And losing 5 in 4 days is better yet.  That seems to me like you'd be penalizing the player at the front end; the larger the stack the larger the penalty.  All this assuming you're not tracking an initial start time, which it seemed like you said you were not.  Forget about multiple stacks issue, can you just explain what happens to the single stack of 40 apples at 4-day intervals? 

 

Edited June 13, 2019 by redram

[Erik]

48 minutes ago, redram said:

These statements seem a bit contradictory?  Or are you talking player's inventory vs in a container?

Both. You can calculate in real time or with just a timestamp of the last update in an event based way when trying to minimize performance impact.

50 minutes ago, redram said:

But so ok, I've never claimed to be good at math, but are you saying that the per-piece decay time is dynamically adjusted for any given stack based on the size of the stack, such that the decay of half the stack at that time would take X days?  How does this stack of Zeno's apples not end up stretching into infinity?

Yes the infinity-problem is a thing with using a half-life. It can however easily be fixed: Just have the stack disappear if it only has 0.1 apples in it.

52 minutes ago, redram said:

I see what you're doing keeping two separate stacks with the same result in X days as you would if they were in one stack, that seems to be the issue you're focused on.    But ok now your 40 stack is down to 20 after 4 days.  Well now your 20 will be 10 after 4 days won't it?  Losing 10 apples in 4 days is clearly better than losing 20.  And losing 5 in 4 days is better yet.  That seems to me like you'd be penalizing the player at the front end; the larger the stack the larger the penalty.  

The more food the player has, the more is going to rot. This is not a penalty for larger stacks, if the player would split all his stacks into smaller ones, the resulting loss in apples would still be the same: Half the apples after four days.

55 minutes ago, redram said:

All this assuming you're not tracking an initial start time, which it seemed like you said you were not.  Forget about multiple stacks issue, can you just explain what happens to the single stack of 40 apples at 4-day intervals?

For clarity, this is not tracking the start time in any way. The only thing that can be tracked is the last time the stack was updated to reflect the amount after rotting. From that point the size of the stack can be calculated. This will be useful for long term storage, where the stack doesn't get updated for a long time.

40 apples (It doesn't matter how they are stacked) will be 20 apples after 4 days, because apples have a half-life of 4 days. Half the apples will however not suddenly disappear at the 4th day, but they will get less at all times and they will be exactly 20 apples after 4 days. And after yet another four days they will be 10 apples, then 5, then 2.5, then 1.5, then 0.75, then 0.375. then 0.1875 and then they will finally be gone.

[redram]

I was exaggerating when I said infinity.  I didn't think it would be actually programmed as infinite; obviously we'd cut it off, but it would create a - what, logarithmic? - distortion.   Cutting off at .1 doesn't change the fact that those first 20 apples lasted only four days, but that last apple went for 28 days before it was entirely gone.   And I realize you'd eat it before then most likely, but this is not a logical system, and I think players would not enjoy it. I feel like saying it's easy to understand is oversimplifying.  It's easy to know how much food you'll have in four days.   But 20 days?  Not so easy.

Not only is this system illogical, and a constant needling of the player with continual food loss, but it scales in a deeply unfair manner.  No player is going to enjoy that they lose 20 apples over the first four days, and 10 the next.   That's a communist system of decay - you produce more we take more.   I don't think this system would be intuitive to a player.   Why did those first 20 apples decay faster than the next 10?  At best it would be disguised from the player to a degree by the constant rate change.  I think any reasonable person upon first seeing the tooltip or whatever that the stack would decay by half in X days would reasonably assume they'd have nothing in 2X days.  At least the surprise would be on the pleasant side I guess.    I think you're overly concerned about minimizing exploitation of stack management, at the expense of the fundamental system.   This system will penalize the early game most, when you have less than 1 stack of a given food.  And it will always penalize in that fashion, for the entire game, and even for preserved foods (that aren't infinitely preserved).  

Compare that to the cliff system - you have all the food for a long time, and then it decays quickly at the end.  You allow the player to combine stacks manually if they want.   Don't just average, weight the rottener portion.   Exploits handled.  No needling of constant food loss.  Logical.  And I would argue that a system that is logical will rarely be considered unfair.  I do agree that it may be an annoyance in the early game, for those who can't stand to combine stacks and lose a bit.  Though I could also see it being annoying in the frame of not automatically picking up a food item because your inventory is full and the game won't auto-combine.  That would possibly be confusing and annoying.  But again, probably more an early game thing.   In the later game, you'll likely mostly be harvesting your own crops at your base with plenty of storage, so it should not be a problem.  Nevertheless the early game is indeed the first impression and you don't want it to go badly.  But I think it's worth trying.

That's my take on it.

 

 

[Erik]

7 hours ago, redram said:

I was exaggerating when I said infinity.  I didn't think it would be actually programmed as infinite; obviously we'd cut it off, but it would create a - what, logarithmic? - distortion.   Cutting off at .1 doesn't change the fact that those first 20 apples lasted only four days, but that last apple went for 28 days before it was entirely gone.   And I realize you'd eat it before then most likely, but this is not a logical system, and I think players would not enjoy it.

There is nothing illogical about a half-life system. Then radioactive decay would be illogical... 

7 hours ago, redram said:

I feel like saying it's easy to understand is oversimplifying.  It's easy to know how much food you'll have in four days.   But 20 days?  Not so easy.

Does the player need to know exactly how long his food will last? That would be pointless with this system, it doesn't help the player to know when he will have no apples, because he will have almost no apples long before that. He already has a good indication for the near future: Half the stack is gone in X days. It's not that hard to understand, as the player can see that it is ticking down in real time.

7 hours ago, redram said:

Not only is this system illogical, and a constant needling of the player with continual food loss, but it scales in a deeply unfair manner.  No player is going to enjoy that they lose 20 apples over the first four days, and 10 the next.   That's a communist system of decay - you produce more we take more.   I don't think this system would be intuitive to a player.   Why did those first 20 apples decay faster than the next 10?  At best it would be disguised from the player to a degree by the constant rate change.  I think any reasonable person upon first seeing the tooltip or whatever that the stack would decay by half in X days would reasonably assume they'd have nothing in 2X days.  At least the surprise would be on the pleasant side I guess.

The system is not scaling deeply unfair. In Tyrons system, no matter how many apples you farm, they would all be gone after 6 days. In my system many of them will be gone by then, but not all of them. Tyrons system punishes players for overproducing, making every apple overproduced a waste. In my system, every apple overproduced practically makes all the other apples last longer. Disguising the system with adding a constantly changing rate to the tooltip of stacks would confuse the player a lot more and give him false assumptions. The simple "Half the stack is gone in X days" is a much less confusing way to introduce the system. And if the person first thinks the system is a cliff system, he will shortly after see that A: The tooltip never changes, because it is always accurate. B: Food is going down over time. 

7 hours ago, redram said:

I think you're overly concerned about minimizing exploitation of stack management, at the expense of the fundamental system.   This system will penalize the early game most, when you have less than 1 stack of a given food.  And it will always penalize in that fashion, for the entire game, and even for preserved foods (that aren't infinitely preserved).  

It will be least problematic to player in the early game: They don't store food, because they eat it all within a short timeframe. The system penalizes players for storing food for long times, that is correct and also what a decay system should archive. I think it's valid critique to say that it penalizes the player regardless of him having done a wrong thing and storing food for a long time, because the system constantly and actively takes food away from the player, while Tyrons system only punishes the player when he has been storing the food for a long time.

Non-indefinite preserving obviously doesn't make the penalty go away, it just lowers it by having a longer half-life and therefore the penalty.

8 hours ago, redram said:

Compare that to the cliff system - you have all the food for a long time, and then it decays quickly at the end.  You allow the player to combine stacks manually if they want.   Don't just average, weight the rottener portion.   Exploits handled.  No needling of constant food loss.  Logical.  And I would argue that a system that is logical will rarely be considered unfair.  I do agree that it may be an annoyance in the early game, for those who can't stand to combine stacks and lose a bit.  Though I could also see it being annoying in the frame of not automatically picking up a food item because your inventory is full and the game won't auto-combine.  That would possibly be confusing and annoying.  But again, probably more an early game thing.   In the later game, you'll likely mostly be harvesting your own crops at your base with plenty of storage, so it should not be a problem.  Nevertheless the early game is indeed the first impression and you don't want it to go badly.  But I think it's worth trying.

The cliff system doesn't work. There would have to be a time stamp on stacks to keep track of when the stack will half. That would not allow combining stacks without issues. There are several ways of handling combining stacks here:

A: Average the date between the two, weighted on stacksize.

Works, but lets player safe food about to be halved by throwing it into a bigger stack in time. The whole system then also becomes much more confusing, because the time when the stack will be halved changes whenever the player combines stacks or even when new items get added to the stack. The player will have no idea when the stack will half, because that changes with every apple they pick up. This is obviously therefore a very bad idea and would make the system seem very illogical to players.

B: Spoil what would be spoiled when combining stacks.

Also works, but punishes players for combining stacks or picking up new items that would go into the stack, because then it would be updated and some food be lost prematurely. This obviously is highly problematic and hides the constant food loss by only making it appear when players do edit the stacks. This is also properly illogical: Why should combining stacks cause food to be lost?

C They don't stack.

This would work, no exploits possible, easy for player to understand. But it spams your inventory. It would be Tyrons system, a bit more complicated because food doesn't completely spoil, but gets halved when the timer runs out and then the timer would reset. So it would be worse than Tyrons system, because there is no huge gain from the half-life mechanic, other than making it a bit more complicated, because the timer resets.

 

[redram]

3 hours ago, Erik said:

There is nothing illogical about a half-life system.

That's like saying there's nothing illogical about math.  No, there is nothing illogical about math.   But applying math in certain ways to certain situations can be.  Food is not uranium.  It doesn't decay like that.

3 hours ago, Erik said:

Does the player need to know exactly how long his food will last?

So you say that one of the strong points about this system is that the math is simple but when it's pointed out it's not simple past the first iteration, you hand-wave away the non-simple part?  The rate of the tick-down changes over time.  There's a real potential there for the player to feel mislead and confused.

 

3 hours ago, Erik said:

The system is not scaling deeply unfair. In Tyrons system, no matter how many apples you farm, they would all be gone after 6 days.

That's because it's a logical system with respect to food.   irl if you pick 100 fruits, they're all probably going to rot around the same time.  Each fruit is individually spoiling the moment it's picked.  Not half at X time and a few at 7X.  It's made quite clear in the cliff system, and the player doesn't have to question it.  In this half-life system, the more work you do, the more you lose after the first iteration.   In the cliff system all that food is available for you to use right up till near the end (I'm presuming, I don't know what the ratio will actually be).

 

3 hours ago, Erik said:

It will be least problematic to player in the early game: They don't store food, because they eat it all within a short timeframe.

But one of your criticisms of a time-stamp system is that is clutters inventory in early game.  If the player eats all of it in a short timeframe, then that is also not a problem.

As for your last several points, I'm not sure what you're getting at.  It seems like you're criticizing the cliff system at times, but you also refer to halving, which is not a thing in the cliff system.  If you're talking about a half-life system with time stamps, then ya I agree that's probably the worst of both worlds.

Tyron stated in discord that current plan is indeed to simply weighted average combined cliff stacks.  And that does indeed effectively 'extend' the life of the lower stack.  I would perhaps have went with an average that weights the 'more rotten' stack more heavily.  Perhaps as if it was double it's weight or something.  But, a straight up average is only going to benefit the player, not punish them.  So it's not the worst thing in the world.

I'll say this additional thing for the cliff system - it's easy to balance.  You know exactly how long that food is going to be fresh.  The half-life system, you gotta do the maths.

[Erik]

52 minutes ago, redram said:

That's like saying there's nothing illogical about math.  No, there is nothing illogical about math.   But applying math in certain ways to certain situations can be.  Food is not uranium.  It doesn't decay like that.

So you say that one of the strong points about this system is that the math is simple but when it's pointed out it's not simple past the first iteration, you hand-wave away the non-simple part?  The rate of the tick-down changes over time.  There's a real potential there for the player to feel mislead and confused.

That's because it's a logical system with respect to food.   irl if you pick 100 fruits, they're all probably going to rot around the same time.  Each fruit is individually spoiling the moment it's picked.  Not half at X time and a few at 7X.  It's made quite clear in the cliff system, and the player doesn't have to question it.  In this half-life system, the more work you do, the more you lose after the first iteration.   In the cliff system all that food is available for you to use right up till near the end (I'm presuming, I don't know what the ratio will actually be).

The half-life system is not realistic, but not illogical either. I understand what you're getting at and Tyrons system is better in that regard, but it still has the stacking problems.

57 minutes ago, redram said:

But one of your criticisms of a time-stamp system is that is clutters inventory in early game.  If the player eats all of it in a short timeframe, then that is also not a problem.

There is a difference between losing a tiny amount of food and having the inventory full because of food stacks with different harvest dates. The player might not have a lot of food, but he certainly has a lot of different food types with different harvest dates.

59 minutes ago, redram said:

 As for your last several points, I'm not sure what you're getting at.  It seems like you're criticizing the cliff system at times, but you also refer to halving, which is not a thing in the cliff system.  If you're talking about a half-life system with time stamps, then ya I agree that's probably the worst of both worlds.

 Yes, I though you were talking about a half-life system with time stamps, which would be the worst.

1 hour ago, redram said:

Tyron stated in discord that current plan is indeed to simply weighted average combined cliff stacks.  And that does indeed effectively 'extend' the life of the lower stack.  I would perhaps have went with an average that weights the 'more rotten' stack more heavily.  Perhaps as if it was double it's weight or something.  But, a straight up average is only going to benefit the player, not punish them.  So it's not the worst thing in the world.

Well, it can punish the player if he combines his small stack of very fresh food with the big stack of food, close to spoiling. The then would have lost the freshness of the small stack only to have the big stack last a tiny bit longer. So combining stacks still requires thought, so while it is a solution, it is not ideal.

1 hour ago, redram said:

I'll say this additional thing for the cliff system - it's easy to balance.  You know exactly how long that food is going to be fresh.  The half-life system, you gotta do the maths.

I wouldn't say that the half-life system is harder to balance. The relations between the half-life of different food would still be the same, double half-life means lasting double.

[stefano franzini]

Hi guys,

I just wanted to chime in to say that I really like Erik spoiling system, kudos to you for coming up with it, but I think it could be explained in a slightly different way
to show that it is not illogical at all. If you say that half the stack will be gone in a certain amount of time you are absolutely correct, but I think it is a bit
misleading with respect to what it's going on: in reality the food simply has a constant rate of decay!

I will get a bit mathematical here, but bear with me: if you have N apples, which decay with a rate K (in some unit of time) the number of apples that are going to rot 
away with this method in a time T is going to be N*K*T. Thinking of N as a continuous variable you could put this into a differential equation and you would obtain that
after a certain time elapses the original stack gets reduced to N(T) = N*exp( - K*T ). From this you can compute the half-life of a stack, which as Erik points out does
not depend on the size of the stack at all ( in fact T_half  = log(2)/K ), which I think is one of the nice things of this method. The other nice thing is that it does not require
time stamps, because the decay rate is a constant and does not depend on the time at which you pick up your food, which means that you could stack things or unstack
them without worrying about optimization ( I really dislike the idea of spoilage introducing micromanagement in the game ).

Of course the main problem is that the number of objects is an integer, not a real number. Introducing floats as Erik suggest is something I honestly dislike (sorry): I feel like
games thrive on being as simple as possible (which is not the same as being easy). Basically less is more, and convoluted mechanics tend to make a game less attractive to
me. My solution would be to work in the background: let the number of apples be an integer, but make the number of apples which rot away in a given time frame a random variable.

Again I will get a bit mathematical: to achieve a constant decay rate K you can also say that the probability of an item decaying in a time T is P = K*T. So for each item you
would draw a random number between 0 and 1 and check whether it is smaller than P. If it is, the item decays, otherwise it does not. In this way if you have 64 stacks of 1
apple each, with a decay rate of 32/day, what will happen is that some of these will decay in a day, and other will not. Of course this adds a bit of randomness in the process,
but the fluctuations should not be too severe, especially if you consider large amount of food items.

What impact such a method would have on the game performance is something I have no idea how to assess, so maybe an implementation is not possible, but if it is I think
this would be one of the most elegant solutions (mostly thanks to Erik idea), as it really does not change anything in the way the game works, except introducing decay.

I think the last kink to iron out is the question of where the rot would go once an item decays, especially if there is no space in the inventory.

[Tyron]

On 8/2/2019 at 9:55 AM, stefano franzini said:

I think the last kink to iron out is the question of where the rot would go once an item decays, especially if there is no space in the inventory.

Thats indeed a notable challenge which was easily solved with the harvest timestamp approach thing.

[Erik]

On 8/2/2019 at 9:55 AM, stefano franzini said:

I think the last kink to iron out is the question of where the rot would go once an item decays, especially if there is no space in the inventory.

The most straight forward option would be to remove the whole rot mechanic and replace it with a proper composting mechanic, where you have to put your unwanted food in a composting bin or something, but implementing this new mechanic would probably require a lot of work.

[redram]

On 8/6/2019 at 9:46 AM, Erik said:

The most straight forward option would be to remove the whole rot mechanic and replace it with a proper composting mechanic, where you have to put your unwanted food in a composting bin or something, but implementing this new mechanic would probably require a lot of work.

That wouldn't fix the issue.  Players always want all their food, at least in times when decay matters.   Decay is a mechanic that tries to keep food relevant as a limited resource, and drives the player to use other game mechanics like cooking and preserving.  It's not to force players to 'count their calories' and throw out food they don't think they'll need in the next few days.   When you're running around looking for a place to settle in the early game, you're fighting decay, you want every scrap, but it's a race against time, and composting isn't even relevant. 

I think the only way to fix this issue of a half-life system might be to have all containers (and the players inventory) have a special 'output' slot that they cannot put anything into.  That slot would basically be reserved just for rot.  Might even only show up if the container has food, otherwise it's hidden.  However that single slot would need to be able to accept an entire inventory of rot, otherwise you're back to the same problem.  That or there would need to be able to be a dynamic number of these output slots.  As many as required.  And theoretically they could dynamically place the rot back into the regular chest slots, once slots open up due to the entire stack decaying.  That would be more helpful if not for the infinity issue, of course.  If chests auto-combined stacks as they rotted, that would help a lot though, I think.

Edited August 19, 2019 by redram

[Erik]

42 minutes ago, redram said:

That wouldn't fix the issue.  Players always want all their food, at least in times when decay matters.   Decay is a mechanic that tries to keep food relevant as a limited resource, and drives the player to use other game mechanics like cooking and preserving.  It's not to force players to 'count their calories' and throw out food they don't think they'll need in the next few days.   When you're running around looking for a place to settle in the early game, you're fighting decay, you want every scrap, but it's a race against time, and composting isn't even relevant. 

It would fix the issue. It would just put the rot/compost into a very different position, as a resource the player has to actively produce if he wants it and not something he gets if he screws up his food storage. Think of it more as a removal of rot and addition of compost.

Doing this, not keeping the rot mechanic and replacing it, would imo be better than trying to keep the rot system and making it work in some weird hacky way like the extra slot you suggested.

[Yukihira_S]

Hello everyone. It took a while but I red all the interesting contributions that you added. 

About this topic I can share with you my real life experience. That's why I'll use potatoes instead apples. I hope you won't mind. 

I start from the assumption that a single potato shouldn't have a decay but be simply edible or unedible. Well, when I go to supermarket and get a 2 kg bag of potatoes it's likely that all of them are edible but anyway I check every single one when I prepare them. Obviously I don't use 2 kg of potatoes in a single shot then I have to store the rest. The day I cook potatoes again I look in the bag and sort out if there are some potatoes which are went bad. If there are I just discard them and use the good ones.

How to adapt it to the game? 

Simply a bag of potatoes is a stack. A stack should have a bar which don't equal the decay of the stack or of a single potato but the chance (DC decay chance) to sort out an edible potato from that stack.

For example, if I have a stack of 40 P with an empty DC bar I'll be able to sort out 40 edible P. If the DC bar is 25% full I should obtain (it's a probabilistic calculation) 30 edible P and 10 rotting ones.

Combining 2 stacks should give a single stack with a DC bar which is the ponderate average of the 2 stacks. For example. S1 (40 P with 50% DC) + S2 (20 P with 0% DC) = S1+2 (60 P with 33% DC). 

The same mechanics should apply to the single potato which is a stack made by 1 item: you will still have to sort out if it's edible or not which, in my opinion, is realistic. 

The DC should have a non-linear increase. In other words, higher the DC, bigger will be the next increase. For example, if stack's starting DC is 0% i should wait 7 days to reach DC=5% but if DC=60% I'll have DC=65% after just 1 day. This is the opposite of he half-life system and more similar to reality.

Edited August 21, 2019 by Yukihira_S

[Erik]

1 hour ago, Yukihira_S said:

The DC should have a non-linear increase. In other words, higher the DC, bigger will be the next increase. For example, if stack's starting DC is 0% i should wait 7 days to reach DC=5% but if DC=60% I'll have DC=65% after just 1 day. This is the opposite of he half-life system and more similar to reality.

While I really like the general idea of your system, this last piece ruins it from a gameplay perspective. It does not only not fix the issue with a linear decay rate, but amplify it: 64 stacks of one potato still decay much faster than one stack of 64 potatoes AND combining/mixing stacks with a high DC with stacks with a lower ones (but not too low ones, because that would waste some decay rate) is vital because the lower weighted average DC lowers the decay rate. It's micromanagement hell and exploiting the system correctly is hard, which leads to more micromanagement.

With a half-life decay rate this system would work however and would be the best system yet, having no gameplay issues. I especially like how it avoids the rot problematic, by giving you the rot when you find it (failing the DC check when eating). The issue is minimized (so not fully eliminated) to the rot having nowhere to go only when the player eats with a full inventory.

The issue could be fully eliminated however, by making the system not based on probabilities, but having the bar represent the actual rotten potatoes in the stack. So when the player eats the last non-rotten potato in the stack, or it decays, the stack turns into a stack of rot. I.e. the half-life system, but decay doesn't decrease the stack size, but adds to the "rot bar".

BY THE NINE DIVINES, A SYSTEM WITH SEEMINGLY NO ISSUES (apart from it not being fully realistic).

[Yukihira_S]

22 hours ago, Erik said:

64 stacks of one potato still decay much faster than one stack of 64 potatoes

Please, try to think about dice: every time a die is drawn you have the same chance to obtain a certain number. No matter if you draw 64 dice at once or a single die 64 times.

About linear decay, I should say again that I don't think that it's good and it should increase overtime. 

[Erik]

 

6 hours ago, Yukihira_S said:

Please, try to think about dice: every time a die is drawn you have the same chance to obtain a certain number. No matter if you draw 64 dice at once or a single die 64 times.

About linear decay, I should say again that I don't think that it's good and it should increase overtime. 

Yes, I'm wrong here, you're right, assuming the DC increase rate is still linear (which still means a non-linear DC increase) your system would work without any stacking issues.

But the system has still the issue of of there being no place for the rot to go when eating with a full inventory, which a deterministic version of the system wouldn't have. However the deterministic version needs a constant decay (i.e. DC increase) rate or eating will cause food to spoil faster, which is clearly not wanted.

So it's a choice between a more realistic chance based system with a minor gameplay issue or a less realistic deterministic system without gameplay issues.

[Yukihira_S]

On 8/22/2019 at 10:36 PM, Erik said:

 

But the system has still the issue of of there being no place for the rot to go when eating with a full inventory, which a deterministic version of the system wouldn't have.

Once the weight based inventory system will be implemented that won't be an issue anymore.