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.