Many hands make light work.

[goitre]

Two or more people working on the same project should be more efficient than those people working on individual projects.

---

I might give an example to illustrate.

If one person gathers wood alone, they gather at roughly 300g per day.
If two people gather wood together, they gather at roughly 350g per day (each).
and so on...

This would encourage collaboration and teamwork. I.e. You scratch my back, and I'll scratch yours.

Forgiveness please, if this is a re-post. I did a brief search and couldn't find it elsewhere.

[kabl00ey]

Although collaboration and altruistic-appearing behaviour would be lovely, if that's how Cantrians chose to act, I'm not sure this is realistic. If I was gathering branches with you, goitre, I can't see any reason why I'd do it faster. If anything, in all honesty I'd probably stop to chat every five minutes, and you'll do all the work.

[Just A Bill]

Ideally, each project should have an ideal workforce size and as the labor force gets closer to the ideal size, their productivity goes up. I suspect most gathering projects the ideal force would be one and not change much with larger ones. That being said a second hand around when building a house would be a great help.

I would also like to see projects that take a fraction of a persons time. I can watch herbs dry, while at the same time cooking something, and perhaps making something else when neither the rack or the oven needs tending. This would probably be a nighmare to implement, but would be more realistic.

[SekoETC]

You know what, that does make sense. It's pretty insane how a single person can build a cottage all by himself but with two people it would be much easier.

[Shaderon]

I would also like to see projects that take a fraction of a persons time. I can watch herbs dry, while at the same time cooking something, and perhaps making something else when neither the rack or the oven needs tending. This would probably be a nighmare to implement, but would be more realistic.

Actually I would like to see this too, I wonder if it's possible to have a project that takes a third or a quarter of your resource so you can do three or four at once? For example Cook meat in an oven, dry meat on a rack and cure leather in a tub. In reality it could all be done at once, in Cantr it could take 3 times the time if it is looked on as an unfair advantage but really we should be able to set a few things up at once.

[Yoldash]

As "Just a bill" says..

According to the "marginal addition" theory.. to a certain level, any contribution may add greatly.. but after it each partcipitants effort starts to add less to the job even the efort given is same as others.. and after another certain level, if more people get in to the job, they will hinder the process.

[Savanik]

In reality, there are very few tasks that actually demonstrate higher than 100% efficiency when you add people to a task. This is because of the law of diminishing returns.

When you add people into a project, these people have to communicate back and forth while they're working. As the number of people goes up, the amount of communication needed to work on the project increases - depending on your organizational style, this can be exponential.

As an example, imagine you're replacing the oil in your car. Let's say that takes 120 minutes by yourself. With a friend handing you tools and the oil and such, he can save you a lot of work. But you have to tell him 'hey, can you give me that 3/8th inch grippy' and so forth. Still, it's a lot easier than doing it all on your lonesome. You could probably get it done in 65 minutes.

Now let's say you have ten friends over to help you change the oil. Not all of them are going to be able to work on the thing at the same time. And the question goes from, 'Can you give me that 3/8th inch grippy' to, 'Say, who's got the 3/8th inch grippy', 'Oh, Bob's got that', 'No, I handed it to Mark', 'Hey, where's that beer you promised?' and so forth. It'll still probably take you around 20 minutes, provided Mark doesn't think beer is as good at lubricating engines as it is at lubricating throats.

You get a similar problem in distributed networking problems with computers. The more computers you add to a cluster to finish a single task, the more they have to communicate with each other to organize the task. Eventually, adding more computers doesn't significantly decrease the time it takes to complete the program.

I think the present system we've got in Cantr works just fine.

Sav

[Confutus]

In reality, there are very few tasks that actually demonstrate higher than 100% efficiency when you add people to a task. This is because of the law of diminishing returns.

Sav

That's not to say that there are none. For instance, two people can often carry furniture in less than half the time it would take one because the distribution of weight affects the effort required. A bucket brigade is more efficient because there is much less walking back and forth per bucket of water moved, and when there is a lot of setup and task switching that can be eliminated by specialization, such as in producing autos on an assembly line versus having each one handcrafted by a single artisan. But eventually, such increases in efficiency do drop off and became decreases as the principle of diminishing returns begins to bite.

[T-shirt]

Like it had little to do with adding realism and more with trying to make people work together, the resource slots scarcity was introduced. A change that has added little cooperation and more iritation, but that's another issue.

A change where working together on a project means better results is a positive way to increase cooperation. Even if the results are small, like a project with two people working on it will be finished in 45% of the time, instead of 50%.

[kabl00ey]

Sav, that's a very good way of explaining what I couldn't (exams! exams! *sigh*).

But T-shirt also makes a good point.

I guess it comes down to whether you want realism or assisted-altruism. Hey, I guess its positive or normative

[nitefyre]

In reality, there are very few tasks that actually demonstrate higher than 100% efficiency when you add people to a task. This is because of the law of diminishing returns.

When you add people into a project, these people have to communicate back and forth while they're working. As the number of people goes up, the amount of communication needed to work on the project increases - depending on your organizational style, this can be exponential.

As an example, imagine you're replacing the oil in your car. Let's say that takes 120 minutes by yourself. With a friend handing you tools and the oil and such, he can save you a lot of work. But you have to tell him 'hey, can you give me that 3/8th inch grippy' and so forth. Still, it's a lot easier than doing it all on your lonesome. You could probably get it done in 65 minutes.

Now let's say you have ten friends over to help you change the oil. Not all of them are going to be able to work on the thing at the same time. And the question goes from, 'Can you give me that 3/8th inch grippy' to, 'Say, who's got the 3/8th inch grippy', 'Oh, Bob's got that', 'No, I handed it to Mark', 'Hey, where's that beer you promised?' and so forth. It'll still probably take you around 20 minutes, provided Mark doesn't think beer is as good at lubricating engines as it is at lubricating throats.

You get a similar problem in distributed networking problems with computers. The more computers you add to a cluster to finish a single task, the more they have to communicate with each other to organize the task. Eventually, adding more computers doesn't significantly decrease the time it takes to complete the program.

I think the present system we've got in Cantr works just fine.

Sav

The fixed input being land slot, and the variable input being amount of laborers, in the short run, if Cantr adopts the Law of Variable Proportions, finding the Marginal Product and Average Product, or rather, where they meet for maximum average product/minimum average cost, in gameplay will be kind of difficult. Someone'll have to keep graphing it, and it'll just become a big chore to find out should we have 3 people on a rice field, or 4, or 2, to discover the point where AP and MP meet. Especially if the production function for each is changed per material, type of project, leaving this Law out of Cantr may not be economically true, but at least in the interest of keeping softcore players (since machines would probably have different formulae), I agree. However if Cantr used the same function (i.e. the same formula for all goods), I think it could be applied fairly well (although it would be nice at least to be shown the Total Output and Variable Input (of Labor), and next to it, the MP and AP, and of course, where the maximum productivity/minimum opportunity cost is achieved) in the case of Cantr, as long as it is transparently done.

[Just A Bill]

With a a lot of DB work, you could set up a table for each project, with fields 1..max number of workers each field would have an "Project Size Multiplier" say between .8 and 1.2. When work is done by a person on this project, the amount of work actually acomplished would be multiplied by the value. A few suggested examples might be...

Building Cottage
People Multiplier
1 .9
2 1.15
3 1.16
4 1.16
5 1.16

Harvesting Carrots (not sure exactly what a harvester is, but there is only one machine so I suspect sharing it might be difficult)
1 1.0
2 .8

Gathering Sand (If each person has space on the beach it they should be independent of one another)
1 1.0
2. 1.0
...

This would probably be a large pain for an already overstressed progD so probably not worth the time.

You could use a method like this in place of resource slots where the total number of workers is the total number of workers gathering that resource at that location, not just on the project and let the multpliers go really low to reflect crowding in the field. That might look like this

Gathering Rice
1-3 1.0
4-6 0.9
7-10 0.7
11-14 0.4
15-20 0.2
...

[Nick]

Nice explanation Sav.
I'm not as willing to come up with a good reason so I'll summarise my view in one, long word.
Boooooooooooooooooooooooooooooooooooooooooooooooooo!!!!!