Better AI (Big Boost Potential)

Now before I start, I want to give a small disclaimer that I’m not familiar with EVERY single thing that is going on, but I know a trick or two (I made a simple mod for Minecraft).

Now this kinda branches off a few things that were suggested so in a way, this is a duplicate, but it would be difficult to place.

So first thing I wanted to suggest, is to have an if-then statement saying that if the queue is less than 1 don’t search for a crafting job and that should cut down on some of the load.

Next thing which may or may not be a bit easier than what was suggested is to port AI to a different thread, so you don’t have to do a LOT of rewriting
to do (because you have fewer things to call on).

Another thing that could also help somewhat, Is to have a priority system where you could have certain hearthlings do certain things first depending on what task has the highest sub-priority, (chosen second) and what job they are to do first/able to do (chosen first).

And something that would help with the AI hogging thing, would be to have a searching delay of 1-4 seconds which would stop the entities from spamming the loop that caused them to find something to do.

Anyway, just a suggestion that I think would help, and I may or may not add to this in the future.

P.S. I Love the game.

AI is already on different threads, the issue is that they can’t run at the same time as each other or other server threads because the game is not designed with that concurrency in mind because Lua is not designed with that concurrency in mind, and they opted not to try to use Lua Lanes or similar because it’s a big sandbox simulation game.

There are already delays to failed AI “thoughts” so they don’t try it again for a bit, at least for a number of the actions. The craft_items_orchestrator already suspends crafting thoughts for a crafter if they fail to find one to work on for X amount of time or until a relevant event occurs (like the craft order list changing or the crafter leveling up). If the crafting queue is empty, extremely little processing is done to occasionally think about it since there aren’t any orders to consider.

There’s already a priority system, it’s just not player-directed (aside from players being able to disable certain types of activities for individual hearthlings, or pause those types for all hearthlings). Reworking the priority system to allow more granular control has been suggested many times and would require a substantial amount of work (if it’s even possible/practical just with the Lua).

1 Like

It’s quite possible. The priority/utility is a function on each AI action, so it can query player-controlled configuration. The vast majority of work is to design the UX for configuring priorities (per action target? per action? per task group? per character? relative or absolute? how to stop the player from hurting themselves too badly? etc.) and update the relevant actions to use it.

1 Like

that is why I said that I knew that essentially all my ideas were already suggested.

You know, I forgot about how much more useful it could be to keep hearthlings away from danger with priorities, and if it ever becomes a part of the game, I think that could be a big plus for many players.

Oh cool, I thought it was just a (relative) constant or range, and worried about how impractical it would be to adjust all the priorities of AI actions and task groups, especially with dynamic adding and removing of them. Seems like a lot of things would need to get patched, and then, as you say, a whole lot of UI/UX work.

Just to chime in quickly with some relevant experience from another game:

Towns has the kind of priority system described here, where tasks can be given individual priorities on a group-by-group basis (including the default “no group” group, although not on a per-townie basis.) I don’t know what the behind-the-scenes looked like, but from a modding perspective it was relatively simple to configure from within the data files (although as a general rule, Towns is more simple to mod than Stonehearth is.)

The big issue with the system, IMO, was that most players didn’t use it or really understand it. Some of us who did dig into it found it absolutely brilliant, and it could give complete and granular control over who did what (e.g. give one townie priority to cook food and make all other jobs not considered important to them, so you could designate full-time chefs and then have everyone else effectively ignore cooking jobs.) I reckon that’s partly because the effect of a system like this isn’t immediately obvious/intuitive – setting the priorities is only part of the story, you also have to have your infrastructure set up correctly if you want the ideal/imagined outcome of your workers never running off to do random faraway tasks when there’s a better task to do nearby.

So, what lessons can be learned from the example to help improve a potential adaptation for Stonehearth? Well, the big one is to include either tooltips or some kind of tutorial (introductory mission?) which will explain the system to players and show how it interacts with their other decision-making tools. If players bump the priority of hauling to the top of the list but that doesn’t speed up hauling (e.g. because hearthlings are too busy finishing off their existing queued tasks, or because the hauling tasks keep getting assigned to slower hearthlings with low Body scores and/or speed debuffs), then it looks like the system is broken/does nothing. Considering the level of micro-management that such a priority system can introduce, some players will need a good incentive to dig into it.

Another lesson to be taken is, IMO, “work groups” (think soldier parties, but for workers) can be a very effective middle-ground between micro- and macro-management. This obviously requires another layer of system infrastructure to be modded in, but I believe that should be very possible. Stonehearth has the advantage over Towns that its Hearthling Therapist UI is more granular and accessible than Towns’ citizen context menus, so I reckon that Stonehearth can handle the extra options without becoming impossibly complicated and intimidating.

A third lesson: no matter how many options you give the player, they’re going to want more (the most popular tasks and priorities mod for Towns was one which broke every single action down into its own priority, LOL!), so I wouldn’t suggest worrying about adding too much complexity – players will mod that in themselves. This seems like a perfect candidate for ACE’s “horizontal expansion” way of doing things: give players the functionality and, eventually, someone will run with it and add the depth.

*Oxygen Not Included has a similar priority system, but that game runs so differently to Stonehearth I’m not sure how applicable its lessons are, save one: a lot of rookie ONI players will set everything to priority 9 (max) and wonder why nothing gets done faster :sweat_smile: Dwarf Fortress of course is the grand-daddy of this sort of priority system, but that’s a whole other level of complexity and IMO Towns is a closer match… although I wouldn’t personally be against going full DF, I don’t think it would be worth the effort and I reckon that a much more simple/elegant solution is possible.