FORUM ARCHIVED

ALPHA 43C NOW ON EXPERIMENTAL BRANCH

Discussion in 'Clockwork Empires General' started by Nicholas, Oct 16, 2015.

  1. Nicholas

    Nicholas Technology Director Staff Member

    Alpha 43D is on the experimental. I have definitely fixed the church thing; I am *fairly* sure I have fixed the new horrifying stockpile issues.

    If I could request that a couple of you can quickly verify that those are fine, let me know and I'll go ahead and do the official hotfix announcement/post. Thanks!
     
  2. berkstin

    berkstin Member

    Can I use a save from 43C?
     
  3. berkstin

    berkstin Member

    OK, I just loaded my save from 43C and the Chapel pop-up issue is FIXED! I didn't have the stockpile issue so can't say one way or the other on that one.
     
  4. Nicholas

    Nicholas Technology Director Staff Member

    Hotfix 43D is up, and it should alleviate many of these problems if not all of them. now, back to it...
     
  5. Wolg

    Wolg Member

    Does this preclude being able to allow simultaneously assigning work crews to both a workshop as well as one or more farms, while keeping the utility calculations sane? (At first glance it seems to me that this would just be a per-workcrew test of workshop job utility versus our-assigned-farms utility, which sounds straightforward enough -- unless I'm missing something -- since the inter-workcrew contention isn't there.)

    Previous builds allowed surplus work capacity from idle workshops to go into farming or other jobs, it would be nice to allow shops/offices that take a direct farmed input (chemist for opium, carpentry for bamboo, etc) and usually operate on standing orders to "grow their own" in idle time when their quotas and one-off jobs are met, rather than taking up another overseer.
     
  6. TurboTodd

    TurboTodd Member

    Just loaded the save I sent you into 43D, the colonists who were stuck are still stuck. I'll run it a while longer and see what happens.
     
  7. Nicholas

    Nicholas Technology Director Staff Member

    If they were stuck before, it's probably still a mess. I'm interested in new games starting in 43D where they are stuck.
     
  8. TurboTodd

    TurboTodd Member

    Fari enough, I'll start up a fresh game!
     
  9. Tikigod

    Tikigod Member

    Thanks for taking the time to write that explanation Nicholas.

    Now my perspective is certainly limited as I can only see it from how the game plays and not how it's actually designed behind the scenes and there's a good chance what I'd think might work might be horrible for performance with how things are designed, but in a general sense at least I would picture something along the lines of:

    Overseer Deciding Where They Fit

    * Knowing how many jobs a farm plot will generate can be a known value in advance without the plot having to generate 'tend me' requirements, taking in the plots size. E.G. A farm that is x by y will only support z plots, therefore the maximum number of tasks that farm could ever create all at once would be 'z'.

    * Farms could expose/advertise/broadcast this when queried by a overseer who is looking to farm and is deciding what plot to work.

    * Workcrews have a 'effective power' value, based upon size of workcrew and skill proficiency... and if they factor into job behaviour at all, any trait influences.

    * Overseer looking to decide what free farm to work compares the fields 'z' value to their own 'effective power' and if the two balance out within a predetermined 'adequate end result' range, then the overseer immediately just concludes they're a good fit and that's that... sure they may be a better field by a couple of points, but really for having something that just delivers reliable results that doesn't really matter until the player does something like build a 30x30 flax plot and then finds their 15x7 wheat plot is getting the bottom end of the farm skill pool and the results aren't what they would like... but that's a player learning and colony planning exercise IMO.

    * If their fit however falls outside of the predetermined range, they put the farm to the bottom of the list.

    * After putting the first field to the bottom of the list they retain how over/under the 'adequate end result' they were before querying the next field. They then repeat the last stage, if still not a fit they compare the discrepancy if it's greater than the one stored they remove the current field from the list completely rather than also moving it to the bottom... no matter what it's never going to be a better option so no need to keep it. If however the discrepancy is less, they remove the field at the bottom from the list completely and add the current field to the bottom and the stored value is updated.

    * This repeats until a field is found where they fall within the 'adequate end result' range, or the number of fields to consider is 1.


    It doesn't need to be give 100% optimal or always perfectly accurate results... it just needs to make a proper attempt and provide a workable and reliable result for the current situation at the time of checking, which I could see the above doing for the most part.

    But this by itself even I would say isn't ideal to have happen every single morning especially as all farm seeking overseers would hit the thing at the same time... that would likely not work or rather it may work but the results would be horrible overall. :p

    But I also can't imagine that the game will only ever have activities that fall under the three categories of:

    * Is a Workshop Job so is only ever done by the workshops assigned crew.
    * Is a Office Activity so is only ever done by the offices assigned crew.
    * Anyone can do the job but it will never last more than the same day that person adopts the job.

    Sooner or later I can only imagine there will need to be the concept of a job life cycle somewhere that can be referred to in places where a larger activity will extend across multiple days and where it really only makes sense if the person(s) who start it, continue that activity through to the end of that life cycle.


    To use farms as a illustration of life cycles in relation to the previous Overseer decision making design:

    Job Life Cycles

    * A fresh farm is assigned a crop. When this happens it starts the life cycle.

    * When the life cycle starts the farm calculates how many plots it can support based on its width and length. (In case you ever plan to allow farm resizing :p)

    * Based on the crop, each plot then represents xx number of events in the life cycle.

    * The farm now knows exactly how many individual segments make up its life cycle. The life cycle behaviour itself doesn't need to know what those actions are, or even what the concept of harvesting is. It just knows that it involves xx number of events.

    * When a overseer decides they're a sufficient match or that a better match isn't available they 'own' that field for the duration of that life cycle... 'own' isn't really the best word but it's the easiest one to illustrate the general idea behind it... essentially it inherits aspects not dissimilar to players assigning a work crew to a field like now... except the overseer is initiating the assignment when they decide on a field and then retain that for the duration of the life cycle.

    * As plots get worked on and the crop moves to the next stage in their growth, the life cycle registers that one more step has occurred leading to the end of the jobs life cycle.

    * If a event occurs such as a crop wither before completion, the wither event can be relayed back to the life cycle as being worth however many steps were left in growth. So if a crop had 5 phases + harvesting and at the 2nd stage it dies, the transition to the dead state is relayed as 3 stages, and then a worker clearing it up provides the final event equalling the same worth as a full crop growth for the life cycle duration.

    * Once the life cycle is complete it stops . The work crew is released. And the process repeats upon the next overseer deciding they can work the field.


    The idea being the concept of life cycles and the overseer decision making can be applied to a range of vastly different jobs without actually requiring any real details about the job itself outside of outsourced variable figures for things like:

    Wheat has xxx cycles and there are 10 plots. So Life cycle is xxx multiplied by 10.

    or

    I want to take this assignment and the developer gods who doth oversee all have decided my skill and crew size equate to a worth of x, and the aspects of the assignment equate to ideally being done by a crew with the range of y and z.


    Applying it directly to farming, something along those lines would require rebalancing of certain things if applied to farming, especially in light of the removal of the "Immediately replant crop after harvesting or whenever the heck you feel like it", as replanting would only occur once a new life cycle begins.

    But it would at least be actual colonist decision making, yet (where needed) additional control to allow something that can be factored into with larger balancing more accurately, but with room for the player to still manipulate. But most importantly retaining the flexibility and ability to react to a wider range of things without needing player nannying for future actions that exist outside of:

    * Is a Workshop Job so is only ever done by the workshops assigned crew.
    * Is a Office Activity so is only ever done by the offices assigned crew.
    * Anyone can do the job but it will never last more than the same day that person adopts the job.
    (* Otherwise is something utterly inconsequential like hacking at a tree.)

    Though as said, that's just how I could imagine it being approached. If it's even remotely practical for how CWE is designed or if it might otherwise generally be considered bad practise for some reason, I can only speculate.
     
    Last edited: Oct 18, 2015