Jobs require a better priority system, so lets make one.

[The Arcanian]

4 minutes ago, The Plum Gate said:

This right here... this is what it was exactly - lol, two different systems smashed into one when they gave it to us - it was as I described - a bit of a mess to discern. You are justifiably confused by my rambling explanation because this kind of sums up the discussion of it. And I have to put it in the context that it was given to us.

What you've been reading, being described by others, and even me is speculation, or suggestion, the system was aborted, so further speculation about how it would have or should have functioned is frivolous. Further more, trying to expand upon an errant and already tested system is going to come with caveats of being errant in the context of the previously attempted system. So I would advise starting from scratch and not look to hard at my explanation of the issues we testers had with it - the underlying duplicant behaviour was not easily discerned by the players as it was implemented - only end of day results could be measured, you know? Could I get things done by using these settings? or was I having to fiddle with things too much? ..turns out a lot of people were having to fiddle with things, and what people perceived of priority was general confusion and speculation mixed with suggestion. Duplicants were getting distracted (check bug reports) - so they changed things. Eventually, the changes made to jobs and job associated tasks this was the nail in the coffin for the double system, it was no longer relevant regardless of if it was functional or dysfunctional- jobs only had one task associated with them, so performance remained dependent on the underlying priority while a job role dictated preferential execution in a manner similar to a perceived +1 priority on said job relative to other errands or tasks not that job. This is the only aspect of the priority system change that still lingers - this information can be gleaned from some of the original early preview branch patch notes as to how jobs work.

 

@Lacost had an excellent and not so dumbfounding take on what a simplified priority system might look like.

11

No, you were literally describing two different stages of priority systems during the preview, not one. (See here for when the change occurred)

8 minutes ago, Keyimin said:

OK, as @The Plum Gate tried to express in his "rambling" but quite accurate description is that you're trying to simplify a system down to a theoretical explanation that nobody truly knows is correct. I played all versions of the preview, and I cannot tell you if the above represents how the system was supposed to work because that's simply not how it "appeared" in practice.

Whether or not that's because the above isn't true in any case or because of the "knock-on effects" the devs referred to, nobody but the devs themselves can answer with certainty. And nobody had enough time with any of the implementations to adequately test because it was clear that all implementations were flawed in one way or another. That, of course, is precisely why the devs shelved it for a future update.

What I can tell you, however, is that the system you describe above, even if taken at face value, presents a problem: the conflict between "jobs" and "tasks" (i.e., what "tasks" are inherent and necessary to a "job" but are not actually part of the "job"). It's a problem you and others have seen me explain several times now in other threads on this topic, so I won't reiterate it here, and it's the one that I still believe is at the core of the flaws in ALL systems we've seen thus far. 

 

Ok, thank you, that helps me understand him better (but he was still describing two systems). I had tried to explicitly ask people if I was understanding the system correctly and often the answer I got was yes.

My first post on this forum was actually an attempt to describe a way resolve this conflict.
So correct me if I'm wrong, but the conflict is this: As an example, a build order has up to 3 subsequent tasks, dig the material in the way, deliver the building material, and finally build the object. If I recall Klei kind of fixed the digging part in one of the preview patches, but builders would still have to wait for a gopher to deliver the building material before they could build. Or as another example, farmers would not water or fertilize crops.
If this is the case then the fix is that, under the hood, Klei needs to add more tasks. So, you would have hidden distinctions like Supply(general), Supply(building), and Supply(Farming). All these supply tasks would be part of the gopher job, but Supply(building) would also be part of the builder job and Supply(Farming) would be part of the farmers' job.

[Keyimin]

OK, so here's my wish list for what I'd like to see from a future implementation of a revised jobs and priority system:

1. Entry-level positions are available for every occupation in the first tier (architect, miner, farmer, cook, artist, researcher, groundskeeper, gofer). This resolves the problem of dealing with immediately increased expectations for what should be considered basic starting jobs.
2. We start with four dupes with an appropriately larger starting supply of nutrient bars (not essential to the system working, but would make the early game requiring occupations a bit less painful).
3. Occupations include essential tasks by default (e.g., farmers can fertilize and water plants by virtue of being a farmer).
4. Each dupe's assigned occupation would have a list of essential tasks (sub-tasks or whatever you want to call it). For the farmer example above, that would include "supply water and fert." For an architect, it would include "dig out terrain" and deliver materials." If you want that dupe to NOT perform the underlying tasks, you can uncheck a box. That way, if you DON'T want your architect to worry about digging and delivering for the build job, you can easily and clearly stop them from doing it without messing with the general tasks pane. On the flip side, a gofer, for example, would still do all supply jobs as part of their main job so however you decide to sort it for you own dupes, all jobs would still get done.
5. Reserve the "tasks" pane for dupes that have no occupations or to serve as an addition to an occupation. For example, if you want your miner to also build when there's no mining to do, you give them the "build" task.
6. Restrict higher speed skill-ups to the main skill of an occupation, reduce the speed for "essential tasks" of an occupation, and allow "additional" tasks and athletics/strength to skill up at a much slower rate based on use of said skills (except in the case of a gofer, whose main job requires athletics/strength, for example). While I realize that players could choose to just give all dupes all tasks to level them, if the benefits of occupations outweigh the speed at which "additional" skills level, that will disincentive that gameplay. It should be clear that occupations are the best road to follow without completely denying the benefits of dupes doing other things.
7. Return the preference for occupation-related tasks above all else.
8. Reinstate the 1-5* priority system, BUT to work in this manner: 1-5 covers occupations, which are always preferred by virtue of #5 above. 1-5* acts as an override to occupations for any dupes to whom you've assigned "additional" tasks, IF any ONLY IF the starred priority is equal to or higher than a 1-5 occupation-related priority. The key to this working as one would envision is numbers 3, 4, and 7 above.

Asking for a lot? Probably. But I'd rather wait 3 months or more for a good system to be implemented than getting something that remains flawed or frustrating.

Also, I've thought about this a fair bit, but I haven't exactly wracked my brain to think of all the possibilities. If any of you lovely people see a flaw in this, please do point it out (not that you wouldn't anyway, but just in case!). I don't want to have a wish list for a good system that results in more problems lol.

EDIT TO ADD: I should probably note that I envisioned the "essential tasks" list of #4 as a dropdown menu or hover menu of said tasks specifically in the jobs panel at the job assignment (not the tasks pane). So you could spend a lot more time in the jobs pane and a lot less time expanding the tasks pane.

[The Plum Gate]

28 minutes ago, The Arcanian said:

No, you were literally describing two different stages of priority systems during the preview, not one. (See here for when the change occurred)

Right - we tested what we were given using active colonies. Any my rambling is mostly concerning your original post favoring how 1-5 was supposed to be implemented and how it related to the old 1-9. Using the observations of it being implemented and how it was functioning ( or in this case, causing confusion simply on account of players attempting to acclimate to it ), I had to add the historical testing context.

I'd just like to break this here, because I liked the notion 1-5/1-5* system and don't see any reason to all out abandon it and we seem to agree about this much.

28 minutes ago, The Arcanian said:

So, you would have hidden distinctions like Supply(general), Supply(building), and Supply(Farming). All these supply tasks would be part of the gopher job, but Supply(building) would also be part of the builder job and Supply(Farming) would be part of the farmers' job.

...and this is what a good many people thought was supposed to happen. Without fine tuning throughout the whole job structure - in my opinion this over burdens a builder, and creates less work for gophers and couriers. Hopefully they can sort this part out - for instance, assistant builders deliver to architects, ...or the sous chef delivers to the chef. That kind of hierarchy makes sense... then gophers and couriers could deliver to the lowest tiers, or the highest tiers, or simply cater to all with preference to delivering to specific tiers? ...groundskeeper could handle generic deliveries or handle low tier deliveries. Such 'Jobs and associated tasks' would need to be flexible.

I like having a master architect and a good courier. The courier delivers enough materials such that the master architect rarely leaves a build site because he doesn't have to go get the materials, he spends more time actually building. So if they were to apply a gopher-builder characteristic to assistant builder - this would supplement the next tier up quite well. But having it as a stand alone ( only the builder can deliver, dig and build ) would be a nuisance when trying to build over granite or other corner cases where an experienced miner is needed to clear a tile. < this corner case being why I run my diggers and builders through the same first tiers and allow them to dig, deliver, and build anyway.

[Keyimin]

3 minutes ago, The Plum Gate said:

Hopefully they can sort this part out - for instance, assistant builders deliver to architects, ...or the sous chef delivers to the chef. That kind of hierarchy makes sense... then gophers and couriers could deliver to the lowest tiers, or the highest tiers, or simply cater to all with preference to delivering to specific tiers? ...groundskeeper could handle generic deliveries or handle low tier deliveries. Such 'Jobs and associated tasks' would need to be flexible.

See, I like this idea except for one thing. It requires even more dupes than the occupations already require compared to the system without occupations. Because if lower-tier occupations are doing the subtasks for a higher tier, you'd want at least one dupe in every lower tier. It also leaves open the question, So how do the associated tasks work BEFORE you reach that point (particularly early to mid-game or in smaller colonies)?

[The Plum Gate]

Just now, Keyimin said:

See, I like this idea except for one thing. It requires even more dupes than the occupations already require compared to the system without occupations. Because if lower-tier occupations are doing the subtasks for a higher tier, you'd want at least one dupe in every lower tier. It also leaves open the question, So how do the associated tasks work BEFORE you reach that point (particularly early to mid-game or in smaller colonies)?

The chef will remember the prior job, yes? So he will be able to deliver to himself. So would a builder, .. so it's not about having someone in that role that supplements him, but making the builder be able to carry more, or spreading the load of delivery to appropriate jobs when they are filled - I'm just worried that dupes won't be effective at a job alone because they can't be helped on account of priority or can't effectively help themselves because they can't be bothered to deliver more than one ingredient or have a very low athletics, or low low carry capacity.

[Keyimin]

6 minutes ago, The Plum Gate said:

The chef will remember the prior job, yes? So he will be able to deliver to himself. So would a builder, .. so it's not about having someone in that role that supplements him, but making the builder be able to carry more, or spreading the load of delivery to appropriate jobs when they are filled - I'm just worried that dupes won't be effective at a job alone because they can't be helped on account of priority or can't effectively help themselves because they can't be bothered to deliver more than one ingredient or have a very low athletics, or low low carry capacity.

Ah, I see what you're saying. Hmmm ... so what would happen during early days or before you're ready to bump the entry-level builder in your example up to the next tier? 

I do get your concern about not being effective. I tried to address that in my own wish list. The gofer job would still exist, of course, so nobody would ever be lacking help in that a gofer's main job would still be to supply. Although I'm thinking perhaps I should specify, rather than leave it as an assumption, that a gofer would still be able to do all of the supply jobs, even if some of those supply jobs are "essential tasks" to a job. Just like a builder's ability to dig wouldn't nullify a miner's job and so on. 

<thinking>

 

[The Arcanian]

@Keyimin Your list looks basically like how I thought the new priority system worked/should work, with a few more improvements.
Only two things:
I am still not seeing anything the justifies more starting dupes. Jobs feel like more of a long-term thing, they help keep things running smoothly when tasks get farther apart, the starting area is small enough that that is much less of an issue.
I do not see how #5 is significant. #4 and #5 sound like things that are already doable with the current task panel. If jobs provide a list of essential tasks and you do not want them to do one of them, uncheck it on the task panel. And if you want them to do a task other then their job when idle, just make sure it is checked on the task panel.

[Keyimin]

1 hour ago, The Arcanian said:

@Keyimin Your list looks basically like how I thought the new priority system worked/should work, with a few more improvements.
Only two things:
I am still not seeing anything the justifies more starting dupes. Jobs feel like more of a long-term thing, they help keep things running smoothly when tasks get farther apart, the starting area is small enough that that is much less of an issue.
I do not see how #5 is significant. #4 and #5 sound like things that are already doable with the current task panel. If jobs provide a list of essential tasks and you do not want them to do one of them, uncheck it on the task panel. And if you want them to do a task other then their job when idle, just make sure it is checked on the task panel.

More starting dupes: Because the original point of the occupations was that said occupations should be necessary. Not for later, but for right now. And there are quite a few much-needed occupations when the system works that way. As such, having only three starting dupes and having to wait for the pod to give you an even semi-decent dupe at all, let alone for one particular occupation, is a bit of a pain (so much so that people started making much more use of the "save/reload" trick to get the pod to switch out potential dupes). Again, not a necessity, but it would be an improvement over what we had when the preview first launched IMO.

My number 4: This is actually critical to solving the biggest problem that I've mentioned previously. It's a way to break the current conflict between tasks that you want a dupe to perform because it's necessary to getting the job done vs. assigning the task in the current task pane, which has them doing that task FOR ALL JOBS. You proposed a breakdown of supply (general), supply (build), supply (farm) to address this same issue. I'm not saying my #4 is THE answer, but it was my answer.

My number 5: It's significant only in that it clarifies the difference between the "sub-task" list that each dupe would have connected to their occupation per #4 vs. how the larger task pane would be used with that in place.

[The Plum Gate]

3 minutes ago, Keyimin said:

Ah, I see what you're saying. Hmmm ... so what would happen during early days or before you're ready to bump the entry-level builder in your example up to the next tier? 

Well, that, I would have to revert to the tasks list and allowed duties - really, this is kind of a doubled over issue the system has already - if it were only jobs based, then I suppose almost nothing would get done the way we've been accustomed to and would have to rethink colony management. So this really reverts to the task matrix, and barring any duplicant stupidity, anyone with an ability to deliver or dig would help him...

My thoughts on the matter of jobs assumes a more serious/functional management-level A.I. overhaul controlling how duplicants perceive their job vs. how we can interact with that system using priority.

Honestly, the jobs system is a nice addition for focusing a specific dupe, other than that, it's only purpose seems to buff dupes into carry capacity and previously unlocked tasks. So I'm on the fence with it anyway.

So a job only system would require more dupes to start with, but then be functional - leading me back to my original thought about starting with 4 dupes and more rations - when the preview first launched, I had a food problem and desperately need another dupe because of how work was being put off.. ( so much sweeping! ) It launched in it's original form with much to be desired when it came to understanding how exactly jobs affected priorities in general.

[The Arcanian]

3 minutes ago, Keyimin said:

More starting dupes: Because the original point of the occupations was that said occupations should be necessary. Not for later, but for right now. And there are quite a few much-needed occupations when the system works that way. As such, having only three starting dupes and having to wait for the pod to give you an even semi-decent dupe at all, let alone for one particular occupation, is a bit of a pain (so much so that people started making much more use of the "save/reload" trick to get the pod to switch out potential dupes). Again, not a necessity, but it would be an improvement over what we had when the preview first launched IMO.

My number 4: This is actually critical to solving the biggest problem that I've mentioned previously. It's a way to break the current conflict between tasks that you want a dupe to perform because it's necessary to getting the job done vs. assigning the task in the current task pane, which has them doing that task FOR ALL JOBS. You proposed a breakdown of supply (general), supply (build), supply (farm) to address this same issue. I'm not saying my #4 is THE answer, but it was my answer.

My number 5: It's significant only in that it clarifies the difference between the "sub-task" list that each dupe would have connected to their occupation per #4 vs. how the larger task pane would be used with that in place.

 

I see what you are getting at. As a side note, that same argument for more starting dupes could work just as well as an argument for less randomness from the printing pod.

Are you basically just saying, for example, to be able to toggle on supplying for their job while toggling off supplying while idle? Because it actually sounds like you are just exposing my proposed change and making the parts togglable. My proposed breakdown is actually more of necessary background logic change to allow for a distinction between tasks needed for a specific job and tasks that are of the same nature but not needed for that job. The only caveat being that I do not know how ONI is coded so I can only make an educated guess. Also, just to make it clear, the three "supply" I gave are just for example and more than that would be needed.

[Keyimin]

1 minute ago, The Arcanian said:

Are you basically just saying, for example, to be able to toggle on supplying for their job while toggling off supplying while idle? Because it actually sounds like you are just exposing my proposed change and making the parts togglable. My proposed breakdown is actually more of necessary background logic change to allow for a distinction between tasks needed for a specific job and tasks that are of the same nature but not needed for that job

I understood what your proposed changed was, but I'm suggesting my own. I don't want this to be a background logic change for precisely the concern expressed by The Plum Gate. If it's a behind-the-scenes AI change, then we as players have zero way to address the weaknesses that arise, and we're back to where we've been. What if I DON'T want my farmer delivering? What if I want ONLY my gofer to deliver because I want my builder to stay put and carry on building?

There is not only varying preference in terms of how players manage their dupes and their projects/maintenance, there is also the changing needs that occur from early game to mid-game to late game. So early on, I might want everyone doing everything because I only have a few dupes. But late game, I might have such specialized dupes, and enough dupes, that I want my farmer to ONLY harvest and my master architect to ONLY build. Having a set of toggled "essential tasks" provides a system where all of those things can be satisfied in a simple, easy-to-understand way.

[The Arcanian]

4 minutes ago, Keyimin said:

I understood what your proposed changed was, but I'm suggesting my own. I don't want this to be a background logic change for precisely the concern expressed by The Plum Gate. If it's a behind-the-scenes AI change, then we as players have zero way to address the weaknesses that arise, and we're back to where we've been. What if I DON'T want my farmer delivering? What if I want ONLY my gofer to deliver because I want my builder to stay put and carry on building?

There is not only varying preference in terms of how players manage their dupes and their projects/maintenance, there is also the changing needs that occur from early game to mid-game to late game. So early on, I might want everyone doing everything because I only have a few dupes. But late game, I might have such specialized dupes, and enough dupes, that I want my farmer to ONLY harvest and my master architect to ONLY build. Having a set of toggled "essential tasks" provides a system where all of those things can be satisfied in a simple, easy-to-understand way.

Ok, I see.
Just let me be clear that the change to the logic that I was talking about was not optional, it is a necessity to allow for the possibility of dupes doing everything required for their job and nothing more. You are just saying that it should not be hidden to allow for more player choice, like letting another dupe\job do some part, and I can get behind that.