Revisiting Mealtime AI

Gameplay
1

I found that many of the issues that I have been experiencing are around mealtime mechanics. In this when the AI segment surrounding the hearthlings eating habits, the code implements a drop and forget method that derails other continuous systems.

At this time I would recommend revisiting the implementation and procedures used to complete this task as to allow it to suspend and remember the last known task in a more procedurally correct order. My studies are more around LISP and not LUA or what have you. So I will be more pseudo for this example.

Currently the code implements a problem where the last object held by the worker is lost to the world as unclaimed items and drops them where they last stood. In this we find objects in unintended and often unrecoverable locations. Such as on the middle of ladders, on roof tops and even inside other objects.

Would that the code require the hearthling to place the object into a temporary pocket/inventory and then retrieve the object after they have finished eating it may alleviate much of the issues currently arising in the current builds.

Other solutions could be dropping the object to a special temporary work zone style resource table that is created at the beginning of the feeding process and destroyed as the individual hearthlings return and collect their objects, final destruction being the last hearthling to pick up the last object; then the table would be removed.

Further, the AI could implement a more structured object management approach and allow for object tagging. In this any object could receive a tag say called [hearthlingName]_constructionResource and then the hearthling would be tasked to recover the object with their tag on it after finishing their mealtime.

I thank you all for your time and consideration of these matters at hand and I look forward to your feedback. I also want to thank everyone working on this project as it has been a resource of inspiration for my children to learn programming and game design. It is a wonderful game and I hope to see it mature and be shared with the wider world.

Respectfully
Illian Amerond

11 Likes
2

This is not an issue related to eating; it’s an “issue” (if you wish to call it so) of the stonehearth:drop_carrying_now (I believe it’s called) action. I don’t believe that the items are necessarily “lost” either - technically, wherever they are standing at right now, the pathfinder should be able to get there again (after all, they got there the first time, right…). There might be a lease issue though.

It’s vital that items can be dropped immediately, i.e. if the unit has to run away quickly or other such things. We can’t rely on the PF finding a free location (I’m somewhat sure there is no concept of “free”/“save” location yet) and then drop it - because that wouldn’t work with the way the AI currently works, or rather, it could work, but in a really not-so-nice way.

The tagging of entities is not necessary. If there is a stockpile that has A) free space and B) its filters are matching, any item that can be found (using a BFS algorithm) will be ordered to be restocked. The problem with items lying around on roofs is that there is no way to get there after the scaffolding has been removed. Building ladders therefore creates a path again and units should take any resources lying around and take them to stockpiles.

Sometimes it might be necessary to use the loot tool on dropped entities to set the owner of said entity again. It shouldn’t happen, but it could.

So, long story short, there’s nothing wrong with the whole eat-actions, because they’re not causing the behaviour you describe. All in all, none of the things you mention should happen at all, with the exception of items being dropped in “unreachable destinations”. I can’t say what is unreachable though, as far as I know, items dropped in the middle of ladders aren’t unreachable either… So, uh.

The current behaviour “Just drop stuff on the ground when something important comes up” is somewhat ugly, but I think that introducing pocket dimensions add unnecessary complexity (for example, what if the unit dies? What if the unit eats for twelve hours straight - the item would be “lost” during the entire time, unless you add pickpocketing of course).

The only thing that might could be improved is the scheduling. Currently, the observer will schedule checks for eating at pre-defined intervals (or even times). The basic is kind of like “Every X hours, if calories is below Y then eat”. If there was some sort of “soft enrage” on the whole hunger thing (“Every X/2 hours, if calories is below Y + 10% then schedule eating as next task”) this could improve a lot of things. However, I’m not entirely sure if task scheduling in this sense can already be done. The whole task business is rather “new” (I think a few months), compared to the eating which was already part of the very first Alpha.

3 Likes
3

I think what we may be finding here is more of an inside/outside argumentative state. I am sorry again for the late response as stated earlier, I am quite busy with odds and ends.

As far as the subject, I would like to outline a more specific issue with the eating as described before. It is not so much as the dropping an item immediately is right out, or the action of freeing up the hearthling for important things; it is more what happens to the item, especially when they are not supposed to be dropped objects, when it is dropped by this script.

Poking around a bit I found that specifically the benches (and similar items) are not recoverable once they are picked up by workers and they do not bring them to any stockpile. This may have to do with the item pickup segment or what have you. Yet for as many times as I have repeated the task the current iteration of the BFS/IDDFS algorithm used does not return positive effects. Would that the current AI had a small bit of color in which characters in a non emergency state would drop items held under certain circumstances while still attending to the escalated directives, it would clean up a bit of the odd behavior. Blocks stuck on roofs and other such shenanigans.

I am not privy to the inner workings of the dev teams goals as to how robust the AI will function; however, I am hesitant to state that it is in good order in all states. Much like the fact that Go To and Stop are still functions in many programming languages, yet it is poor taste to utilize such harsh terms when more eloquent solutions abound.

Sorry for the miscommunication, just have not had time to poke into the code. It is on the “to do” list of late. Thanks again for your time and consideration of the matters at hand and I look forward to the outcome of this fun and entertaining game.

Cheers
Illian Amerond

1 Like
4

tl;dr : Read bold print.

I too think that the hunger system should be revisited, I mean it kind of sucks that every now and then they all seem to want to eat at the same time. I understand that my workers have been slaving away for hours in the mines mining ore, and the footman who has been leisurely walking around camp just grabbed the last squirrel jerky and now my poor worker has to suffer and wait to pick some berries.

The hunger system should take into how much work each hearthling is doing to justify hunger, for instance if the health of a hearthling is low and they have been slaughtering goblins left and right I think they should be more hungry than the heathling who stayed at camp and tended the sheep. Although this is early stages of the game and I’m sure it’s in the works to be revised, this is just some of the stuff that I think should be implemented.

5

The idea behind this was likely to have some sort of “village feasting”. Instead of one hearthling eating after another, they all get together and eat together. It’s cute and I approve of that behaviour. If you let them eat whenever they’re hungry, that would probably make them eat at the same time-ish anyway, but not precisely. In the end, you would have 1-2 people eating at any given moment - there would be no such thing such as a “community spirit”.

Not really feasible. Making hunger dependent on some other stats, such as health, is easily doable, but anything else (“idle < walking < carrying < working < fighting”) would require a strict binding of AI actions to calories, which would mess a lot with the modular approach.

6

I was thinking this first too. But after playing a longer time it is getting annoying. Eating and sleeping is such a downtime when all of the people do it at the same time. I prefer eating at different times.
I think eating together should be reserved for festivities. Makes festivities the community thing.

2 Likes
7

i think in some ways they all should eat around the same time and go to bed around the same time, but i dont think everyone should just drop what they are doing and go eat at exactly the same time. perhaps something more like from 12:00pm-1:30pm is “lunch time” and 12:00am-1:00am is “bedtime” . so your hearthlings would individually go eat/sleep in around the same time yet not the exac time, this would also allow them to finish their work before eating.

P.S. sorry if this was said before, just dropping my thoughts in without reading the rest :blush:

1 Like
8

I agree with @Miturion and @8BitCrab. Although the communal touch is nice, there currently isn’t enough reason to have this established time game-wise. Thinking realistically with a new settlement or band of survivors, you would never want everyone doing all their eating and sleeping at the same time–it’s too taxing on early resources (cooking ware and beds, places to safely and comfortably eat and sleep) and–safety and development. You always want at least someone doing something at all times and someone watching for threats with patrols. These last two points are more critical for Stonehearth as a game: like @Miturion said, it’s frustrating to the player to not have any available units for at least two moments every single day, and I’d prefer a way to have my guards be able to alternate schedules.

1 Like
9

that would be very helpfull, and somewhat needed once our towns start getting larger, even just a day and night patrol teams kinda thing would be nice.

10

For guards, I agree. However, the game is not unit-based, that is, you can’t control single units (because micromanaging is not something you should encounter on a regular basis). Therefore, I kind of disagree that you should have two units “available” at any time of day. In the end, it’s a lot more SimCity than Sims. You merely supply the infrastructure, you don’t manage their lives.

1 Like
11

True, but it’s been mentioned several times that civilian squads are being considered in the future to manage specific tasks. You can control them, to an extent.

But creating the infrastructure in a colony historically equates to managing their lives. Think of a group of units you’re planning to have go mine away from town (once civilian groups can be assigned). Would you want them to get to where the quarry is, then–whoops, it happens to be midday. Time to go straight back home for food. Wouldn’t it be better to have them eat before they leave or later on when the mining’s closer to being done? We may have the luxury of lunch breaks today, but colonists of an entirely new world/region didn’t.

This starts to get into the issue of a task schedule–being able to coordinate specific groups for certain jobs, and–if that’s a particularly long task, like building a structure over a few days or clearing a whole forest–when the units should start and stop working on that task during the day and how their sleeping and eating cycles should work. For example, you’d have a group of woodcutters eat in the morning, gather during the day, and then stop working once the sun sets (assuming night will draw more foes in the future). Conversely, a “monster-hunter” squad might sleep in the morning, eat in the afternoon/evening, and set out to hunt throughout the night.

Another future issue is eating while travelling (as in caravans). What if you’re trying to get your units to a settlement rapidly, since there’s goblins right behind them, then all of a sudden, they just sit down and crack out the corn cobs and squirrel jerky, all because it’s technically “meal time” according to the hardwired game clock? And granted, maybe you can control them like a combat squad (where they’ll just stand or walk to death), but that starts to become more demanding of the player’s attention and coordination.

Most of these points are highly hypothetical of course, but for now, it all comes back to the original problem: it’s boring to the player that all the hearthlings adhere to a very similar daily cycle which also results in two periods every day where they drop everything and give the player nothing to do. If more interesting features are ADDED to units eating as a group–listening in to conversations/lore, getting hints about upcoming events, or even just a morale boost to the settlers–it’d serve the gameplay a whole lot more efficiently.

And I’m not saying do away with it altogether–having those group meals looks nice and has a lot of future potential. But if you have ~50 settlers in a game, it’s going to seem strange and unnatural that they all stop and start eating at the same general time.

1 Like