Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Strik3r]

I actually proposed having the stomach be a special container(and be handled similarly to how the game treats things like bags, chests, backpacks, etc.) that is inside a creature and over time digests any food-items eaten. The benefits of this are threefold:
The stomach capacity can be calculated directly from the size of the actual organ, and scales with creature size.

It is the purest way to handle eaten food, closest to reality, any other solution is an abstraction. After all, when you eat food IRL, it doesn't get magically converted into energy, it ends up in your stomach(as the first stop, anyway). While we don't exactly shove whole loaves of bread down our throats, it's still much better than having any eaten food just fill up some hunger meter(s).

Finally, this allows any eaten food to add to a creature's weight. While in a lot of instances, the difference would be negligible, theres a few where it would be very significant. Reptiles and especially monitor lizards are a great example, they can consume a rather large amount of food relative to their body weight, which slows them down pretty considerably.

In summary, my issue with the current hunger system of this game is the title of this thread, specifically that the game does not attempt to model these things at all. I hardly care whether the game has one hunger bar, or a hundred of them, just that the underlying processes be more complex than just hunger bar(s).

A lot of the complexity you propose is redundant and inefficient resource wise.  Having the food in things bellies, then means we have to continually model the turning of that food into vomit and the transition between the stomach and the guts.  It is surely better simply to record that Creature X ate Y item Z time ago and then create the necessary items when it is needed to do so (a creature is slaughtered or it's stomach is cut open in combat) than to keep track of the whole process at every stage?

So you're proposing making the stomach a sort of a "quasi-inventory"? Besides, containers already exist and giving creatures innate containers(with special functions)
 doesn't seem like that much of a leap.
Assuming your solution gets used, how do you make sure that the game will

create the necessary items when it is needed to do so (a creature is slaughtered or it's stomach is cut open in combat)

? How will the game know what to create? In what damage state? How do you maintain all the properties(such as say color) of an eaten item?

Im not saying the tracking of stomach contents can't be optimized, but it needs to be actual optimization.

Also you could pull it out after cutting open the belly of the beast and empty it to get those (partially digested) items/people back. Or carry it around like an alternative backpack, with an epicness level dependant on whether ”the beast” was a dragon or a cow.

Yup, that's the idea.

[GoblinCookie]

? How will the game know what to create? In what damage state? How do you maintain all the properties(such as say color) of an eaten item?

Im not saying the tracking of stomach contents can't be optimized, but it needs to be actual optimization.

Good point.  The information needs in any case to be stored for the last item eaten and how long ago the item was eaten.  However having the object in the game, as in a container means the item needs to be tracked and the calculations need to constantly be done in order to modify the item's state as it is digested. 

If we simply track the information about the item when it was eaten and then create the item when we need to, there is only one set of calculations to be made occasionally rather than constantly all the time having to modify a large set of objects.  Since normally the object info only has to be loaded when the creature poops and far less information is needed at this point, that means only a small amount of the object info would have to be loaded, mostly to calculate it's nutrient value. 

[Strik3r]

? How will the game know what to create? In what damage state? How do you maintain all the properties(such as say color) of an eaten item?

Im not saying the tracking of stomach contents can't be optimized, but it needs to be actual optimization.

Good point.  The information needs in any case to be stored for the last item eaten and how long ago the item was eaten.  However having the object in the game, as in a container means the item needs to be tracked and the calculations need to constantly be done in order to modify the item's state as it is digested. 

If we simply track the information about the item when it was eaten and then create the item when we need to, there is only one set of calculations to be made occasionally rather than constantly all the time having to modify a large set of objects.  Since normally the object info only has to be loaded when the creature poops and far less information is needed at this point, that means only a small amount of the object info would have to be loaded, mostly to calculate it's nutrient value.

When you get to the point of tracking all the information about an item, it does become another container just implemented differently and I'm okay with that. I hardly care how something is tracked as long as the information is complete and stuff doesn't get lost or corrupted when moving it about.

This includes proper energy release per-frame from eaten items, destroying the items when completely digested and making sure if the game needs to release these items, whether by butchering, combat wounds or regurgitation, that proper items be produced.

However there is no reason to assume Toady wouldn't just reuse the current container/inventory system and apply the same set of optimizations(updating the contents only when needed) if at all possible.