Algorithm questions

[Grotus]

PR_CalculateProductionTime

The core calculation is this:

Code: [Select]


timeTemp = (maxworkers - PRODUCE_WORKERS);
timeTemp = timeTemp / PRODUCE_WORKERS;
timeTemp = timeTemp * timeDefault;
time = timeDefault - (int)timeTemp;


In a more mathmatical writing with T = time, Td = timeDefault, W = workers, Wb = PRODUCE_WORKERS (Workers baseline):

T = Td - Td * ((W - Wb)/Wb) = Td( 1 - ((W - Wb)/Wb))

The problem I see with this algorithm is that if W >= 2*Wb (20 in the case of the current code) then all production times are 1 hr.  I haven't looked through the code to see if there is anything that prevents you from putting two workshops and 20 workers in a base.

I'm also not sure why 18 guys would build something 5 times as fast as 10 guys.  What was the intended scaling of production?

Inverse proportional would seem to be the simplest way to go (twice as many guys go twice as fast).  More realistic would be diminishing returns, where each additional man contributes less and less, but that's harder to code.

Inverse proportional would look like this:

Code: [Select]


timeTemp = PRODUCE_WORKERS / maxworkers;
timeTemp = timeTemp * timeDefault;
time = (int) timeTemp;


Mathmatically:
T = Td * (Wb / W)

With diminishing returns you would have an amount of work to be done, and each additional worker would add a decreasing amount of work to the total each time unit.  So if worker 1 adds L amount of labor to the total, then worker N would add L * Pf**N, where Pf is the parallelization factor of the labor, a number between 0 and 1.  A Pf of 1 would be the same as the inverse proportional case.  A Pf of 0.5 would mean the second worker adds half the work of the first, the third a quarter, and so on.

The mathmatical way to calculate how much labor W workers would supply would be (geometric series calculation):

Lt = L * ((1 - Pf**W)/(1 - Pf))

I suppose that this could be related to the timeDefault and formulas worked out, but that is more than I want to do at this time.

[Zenerka]

The problem I see with this algorithm is that if W >= 2*Wb (20 in the case of the current code) then all production times are 1 hr.  I haven't looked through the code to see if there is anything that prevents you from putting two workshops and 20 workers in a base.

If you have a lot of workers and workspace (note that to use 20 workers you need to have two workshops, which are expensive), you are able to reduce production times to very low, yes. That is on purpose. (Though it wasn't massively tested yet, because this feature is not in 2.1.1)

Inverse proportional would seem to be the simplest way to go (twice as many guys go twice as fast).

I though about that but discarded this way as 'not realistic'.

More realistic would be diminishing returns, where each additional man contributes less and less, but that's harder to code.

I am not quite convinced that this would be more realistic.

With diminishing returns you would have an amount of work to be done, and each additional worker would add a decreasing amount of work to the total each time unit.  So if worker 1 adds L amount of labor to the total, then worker N would add L * Pf**N, where Pf is the parallelization factor of the labor, a number between 0 and 1.  A Pf of 1 would be the same as the inverse proportional case.  A Pf of 0.5 would mean the second worker adds half the work of the first, the third a quarter, and so on.

The mathmatical way to calculate how much labor W workers would supply would be (geometric series calculation):

Lt = L * ((1 - Pf**W)/(1 - Pf))

If you want, i can provide patch implementing this for testing purpose. I am really not sure that this would be "realistic".

Thanks a lot for your suggestions!

[BTAxis]

More realistic would be diminishing returns, where each additional man contributes less and less, but that's harder to code.

I am not quite convinced that this would be more realistic.

Leaving realism aside, such a mechanism would affect the strategic gameplay by introducing the need for more micromanagement (however slight). Since that isn't the focus of this game, I'd vote against diminishing returns on those grounds.

[Grotus]

Although workshops are expensive, it just seems unbalancing to be able to completely equip a team with the latest researched weapon eight hours after learning how to make it.  It would really be unbalanced with aircraft parts where the baseline time is over 2000 hours.

Also, note that you also need a second workshop if you want to have 11 workers, so I imagine that it wouldn't be a rare thing to build.

I haven't attempted to compile yet (running Intel Mac OS X), so I wouldn't be able to test anything yet.  I only downloaded the game a week ago.

Apportioning workload among the number of workers could get extremely complex, if realism were desired.  

Most of the stuff produced could probably be pipelined, for instance, so the first item produced would take a while, but subsequent ones would come out much faster, until the production switched to a different item.  

Producing small items, like clips of ammo, would probably be done in parallel rather than one item at a time, so the ten guys would each be working on one clip rather than all ten of them working on each clip.  Or even five teams of two guys per clip.  This would result in 10 clips showing up after X amount of time rather than each clip showing up after X/10 amount of time.

There would be a limited amount of tools available in each workshop, so even if you have 100 guys making widgets, if there is only 2 widget presses in the shop, you'll have 98 guys twiddling their thumbs.

But, this isn't a game about building stuff, its about defending the earth from aliens.  So, some kind of balance is required between realism and playability.  I agree that micromanaging workers is not desirable.  From a player perspective, you should only need to know that more workers get stuff done faster.    Some sort of feedback to the player would be good, for instance updating the time to completion for the top item in the queue.  That way the player could try out adding a worker to see how it affects the time required (went from 120hrs to 100hrs for example).

[Grotus]

To illustrate a bit better, lets consider an item which has a baseline of 200 hours.  

Workers -> Time to complete

The current algorithm (basically a linear function) produces time to complete as follows:
1 -> 380 hrs, 2 -> 360hrs, 3 -> 340hrs, 4->320hrs...
8 ->240hrs, 9->220hrs, 10 -> 200hrs, 11 -> 180hrs, 12 -> 160hrs...
16 -> 80hrs, 17 -> 60hrs, 18 -> 40hrs, 19 -> 20hrs, 20+ -> 1hr

Inverse proportional would go like this:
1 -> 2000hrs, 2 -> 1000hrs, 3 -> 667hrs, 4 -> 500hrs, 5 -> 400hrs...
8 -> 250hrs, 9 -> 222 hrs, 10 -> 200hrs, 11 -> 182hrs, 12 -> 167hrs...
16 -> 125hrs, 17 -> 118hrs, 18 -> 111hrs, 19 -> 105hrs, 20 -> 100hrs...
30 -> 67hrs, 40 -> 50hrs, 50 -> 40hrs, 60 -> 33hrs

Diminishing returns would go something like this (at 0.9 Pf):
1 -> 1303hrs, 2 -> 686hrs, 3 ->481hrs, 4 -> 379hrs, 5 -> 318hrs...
8 -> 229hrs, 9 -> 213hrs, 10 -> 200hrs, 11 -> 189hrs, 12 -> 181hrs...
16 -> 159hrs, 17 -> 156hrs, 18 -> 153hrs, 19 -> 151hrs, 20 -> 148hrs...
30 -> 136hrs, 40 -> 132hrs, 50 -> 131 hrs, 60 -> 130hrs

[Wanderer]

To illustrate a bit better, lets consider an item which has a baseline of 200 hours.  

Workers -> Time to complete

(HACK SNIP)

Inverse proportional would go like this:
1 -> 2000hrs, 2 -> 1000hrs, 3 -> 667hrs, 4 -> 500hrs, 5 -> 400hrs...
(CHOP SnicketySNICK)

Diminishing returns would go something like this (at 0.9 Pf):
1 -> 1303hrs, 2 -> 686hrs, 3 ->481hrs, 4 -> 379hrs, 5 -> 318hrs...
(HAMMER THWACK)

Okay, the 200 baseline hours is a large number, however, given that you can start the game with a really small industrial force, and gain only a few per round (at the H/VH levels), I'm not entirely sure i'm a big fan of either of these low # of people numbers.

However, I agree the #'s need to be altered.  I'd love to see a straight linear progression, and an alteration making the 'base time' off *1* person, not 10.  Max workers should be a restriction on # of PRODUCE_WORKERS, not actually affect the final calculations on how much workspace is utilized.

Or am I completely reading this algorithm wrong?

I could see something more intrinsically easy to impliment, with a simple diminishing returns result, along the following lines.

If your base time is 200 hours for 10 people, simply expand it to 2000 for 1 person.   2000 is now the basetime.

W = # of Workers in Workshop(s)
B = Base time of the product.
T = Time to complete item

T = ( B / W ) + ( ( B / 10 )  * ( W / 100) )
T = (2000 / 1 ) + ( ( 2000 / 10 ) * ( 1 / 100) ) = 2000 + ( 200 * .01) = 2020
T = ( 2000 / 10 ) + ( ( 2000 / 10 ) * ( 10 / 100 ) ) = 200 + ( 200 * .1) = 220
T = ( 2000 / 20 ) + ( ( 2000 / 10 ) * ( 20/ 100 ) ) = 100 + ( 200 * .2) = 140

This adds a 10% extra time at 10 workers, 20% at 20 workers... it's rather linear but I'd need some time to come up with a coherent bell curve calculation that didn't skew at an overly intense rate.  I think it would work for this purpose.  It does run into a problem, however:

T = ( 2000 / 100 ) + ( ( 2000 / 10 ) * ( 100 / 100 ) ) = 20 + ( 200 * 1) = 220

Again, the calculation would need to be nailed down, but this would seem to give us the simplest base algorithm from which to work that has *some* loss as you increase people, but nothing exaggerated.

[Grotus]

200 would correspond to a plasma rifle, mainly I picked that number because it was easy to work with and was big enough to show the curves.

Probably the most reasonable way to get the algorithm would be to pick an item and pick the hours required for 1-60 people to build it.  Then fit a function to the numbers.

I think the basic production mechanism could be tweaked as well to make it easier to give feedback.

In the production_t struct there are two ints, timeLeft and workers.  The workers value is currently unused.  I would propose redefining those two values to be workLeft and workPerHour.  The produceTime of the tech would be used to calculate the initial value of workLeft, and the number of workers would be used to calculate workPerHour.

Time remaining (displayed to player) = workLeft/workPerHour
% complete = 1 - workLeft/initialWork

In PR_ProductionRun, the prod->timeLeft-- would change to prod->workLeft -= prod->workPerHour.

When number of workers change, the only thing that would need adjustment would be workPerHour (for all items in queue, don't skip the first one).

And keep in mind that the units of workLeft and workPerHour could be something like milliManHours so that int arithmatic could be used, and still be able to fit any desired production curve.