My idea about priority system vs. jobs

[Kasuha]

My train of thought was kind of along the lines that we as players need our miner to keep digging the tunnel when there are plants in the base asking for harvesting because we have a farmer to do the job. But we need him to leave the place if there's emergency and we still want him to go harvest if he's got nothing better to do or just goes by.

The idea is a compromise between the preview's 1-5/* system and current "flat" 1-9 system. It would make use of both a number and an emergency marker (like the1-5/*) but I think it's a good idea to stay with higher number of levels so I'd like to see it as 1-9/*, just with slightly different approach.

First step would be to broaden the reach of what's a task related to the job. I think that both miners and architects should cover basically the same tasks - digging, building, delivery of material to build. Every miner needs to build a bit and every architect needs to dig every once in a while so why make a distinction between them - you'll still need both and they would be just separate paths to get their appropriate job perks and stat points. Preventing miners to build or architects to dig is not a good idea in my opinion. In a similar way the reach of other jobs should be "completed" so that all things that are related to their job falls under it, even if some tasks count as job-related to multiple jobs. Cook should both deliver to the cooking station and to food containers besides cooking, farmer should fertilize, irrigate, plant, uproot, harvest, and of course operate the farming station and care of plants. And so on.

Second step would be dynamic extension of job-related tasks by all tasks that are not covered by existing job. If a player doesn't have a groundskeeper in their base then every duplicant sees mopping as their job-related task until there is at least one groundskeeper.

Third step is the priority system. Like in 1-5/* there would be "standard" and "emergency" priority levels. Like in 1-5/* (and current 1-9) the "star" (emergency) priorities would be seen at the given priority to everyone. But they would be really only intended (and should be used) for emergencies.

The most important difference between the proposed system and both the preview 1-5/* and current 1-9 system would be in how the "standard" priority is handled.

A duplicant of a job related to the task would see it at the priority set for the task.

A duplicant of a job unrelated to the task (assuming there is another duplicant with matching job) would see its priority reduced to highest priority of all his accessible job-related tasks.

For example if an architect can see a priority 6 build as his highest priority job-related task and there is a priority 7 harvest waiting to be done, the architect would consider that harvest priority 6. If he's standing closer to the harvest, he'll do the harvest. If he's standing closer to the build, he will do the build. If he does the build and that's his last priority 6 task and all that remains are priority 5 tasks, he'll now see the still waiting harvest as priority 5 task. That will mean the architect will have tendency to stay in place where he's got his own work to do but if player manually sends him to the farm, he'll do the harvesting. Or if he'll start harvesting after lunch, the player will be able to send him back to his site to continue building. But a farmer will see that harvest at priority 7 and so he'll prefer that harvest over all 

Separate attention may need to be paid to long term tasks (research, hamster wheel, cooking, outhouse cleaning, oil refinery operation, etc). Here, duplicants of corresponding job should consider the machine empty if it's occupied by unrelated job when looking for a new task and eventually take it over from its current user. Though this is more about making players happy than about actual performance of duplicants.

Will this system be perfect? No. If you have priority 7 plants for the farmer and priority 7 deodorizers for the groundskeeper, the farmer will go refilling deodorizers and the groundskeeper will go harvesting plants if they both come up to be done at once and they happen to be at wrong places. But at least it will not be like that everyone from all around the base will collect at the farm when harvest is due or a deodorizer needs a refill.

[ScottFree]

53 minutes ago, Kasuha said:

First step would be to broaden the reach of what's a task related to the job. I think that both miners and architects should cover basically the same tasks - digging, building, delivery of material to build. Every miner needs to build a bit and every architect needs to dig every once in a while so why make a distinction between them - you'll still need both and they would be just separate paths to get their appropriate job perks and stat points. Preventing miners to build or architects to dig is not a good idea in my opinion.

Had a similar suggestion

 

[Master Miner]

Let's also consider a different approach.

TL;DR: instead of fiddling with priorities and rules, the scheduling algorithm can be improved to find good solutions in acceptable time.

The goal is to get a set of tasks completed as quickly as possible. The advantage of professionals is that they need less working time on tasks that match their profession. But if a professional needs more time to get to the site before even starting to work on a task, then it is better to let another dupe do it. This can lead to situations where a farmer is "locked" at a remote site and digs while a miner is at a farm and harvests.

Generally, this problem has high complexity - generally it can not be solved both optimally and efficiently. No matter what rules are introduced, there will always be plenty of situations where the performance will be sub-optimal. One can try to approach the optimum with acceptable effort.

Given a list of tasks (location, type. priority) and list of dupes (skills, traits) along with their availability (when available and for how long) and distance (travel time), the scheduler can try to assign tasks and minimize the cost. The cost is represented by a "cost function", in ONI it would be the total time to complete a set of tasks.The additional costs like energy needed for tube travel can be omitted.

A good scheduling algorithm has to have a strategy on how to find a good solution in acceptable time. The idea here is to wisely span a search tree over the possible schedules and then to search for an optimum while skipping the search tree branches which don't look promising.

The search should be done in advance - as soon as the list of task changes, and not at the moment when a dupe would become idle. It should look forward and consider several tasks in advance. It should consider travel times and break times. It can use heuristics and save partial search results so they can possibly be reused.

Path calculations can be prepared and updated for the whole map in a separate thread. A personal map can be derived from the common map.

These algorithms need to be designed in advance to provide needed performance.

With a suitable scheduling / planning algorithm, the player wouldn't need to remember priority rules and wouldn't need to constantly fight with priorities, travel times and "dupe's stupidity", wouldn't need workarounds like locking dupes in or out.

[Kasuha]

1 hour ago, Master Miner said:

instead of fiddling with priorities and rules, the scheduling algorithm can be improved to find good solutions in acceptable time.

Your idea is in a sense perpendicular to mine. The way how duplicants see task priorities is the cornerstone of my idea while you approach them as given. My idea does not deal much with how exactly are tasks assigned besides proximity and seen priority while you go a lot into details in this direction. My idea is to not pull a miner to high priority maintenance task because the miner won't see it as high priority task (unlike the appropriate maintainer) while your idea is more of an attempt to assign tasks at their set priorities and even pull duplicants across the map if there's enough high priority tasks that they can't be covered from local sources. Both approaches can be implemented separately and would work together just fine.

2 hours ago, Master Miner said:

The search should be done in advance - as soon as the list of task changes, and not at the moment when a dupe would become idle.

There's about the same amount of task additions and duplicant becoming idle events. The question is what advantage should the advance search have. You don't seem to go much into details about what should the planning actually prepare.

2 hours ago, Master Miner said:

It can use heuristics and save partial search results so they can possibly be reused.

The question is what heuristics. That's the important part. There's nothing like "generic heuristics that will solve all your problems".

2 hours ago, Master Miner said:

Path calculations can be prepared and updated for the whole map in a separate thread. A personal map can be derived from the common map.

Precalculated accessibility map containing all possible steps and jumps, yes. I wouldn't be surprised if it already was used. But the flood fill needs to be done for each duplicant separately because the path may differ per duplicant's stats. A high athletics duplicant may go straight while low athletics dupe may take a slight detour and a tube to transfer between the same two points. Of course it assumes that actual transfer time is calculated which AFAIK is not the case in the current pathfinder.

[Master Miner]

12 hours ago, Kasuha said:

Your idea is in a sense perpendicular to mine.

Yes, they are complementary - on one side better scheduler will require less specific rules, on the other side specific rules / heuristics make the job simpler for the scheduler.

How to design that scheduler and its search tree, what rules to use, how far to look for an optimum, what should be the time limit, how to handle changes in the task list?
That's a task that increases heartbeat of every true software developer.

Even if the scheduler wouldn't be a masterpiece, a bit more planning, few steps in the right direction would already bring significant benefit. For example if dupes wouldn't head out on a trip that lasts 10s only few seconds before bedtime.

[vovik]

Scheduling is doable, just given enough resource.