On Sun, Dec 28, 2008 at 5:38 AM, Michael Pope <mpope@...> wrote:
> > The colony has 5 colonists; that gives a consumption of 2,5 of grain and
> > 2.5 of fish; rounded up will give 3 grain and 3 fish, which is what will
> > appear on the interface.
> No. Consumption of 3 grain, 2 fish. As I said, round, but preserve total
> consumption at the correct value, so perhaps I should have said "round
> needed". Highwind has mentioned that sorting in a priority order would
> this to be done. With the right priority settings in the specification it
> could be 3 fish 2 grain.
Yes, i got it wrong; however i still find problems with this, see other
> True, but I think you are glossing over my point that the adjustment we can
> make here is pretty coarse. *If* playtesting reveals a setting of 2 goes
> far, and we know 1 is too lax, what then? However I am happy to cross that
> bridge when we come to it.
Im glossing over it because it hasnt even been tested yet, so no point in
discarding a 10 sec.change solution before we try it.
> > Like i said, i believe this is an overly complex way of calculating the
> > consumption, for very little gain
> The main gain I wish to advocate here is that this alternative has no hard-
> coded knowledge of special "food" types other than what can be simply
> in the specification. The ideal is that food is just another resource that
> colonies consume.
Neither does the current algorithm need hard coded knowledge; it works just
fine just with the info from the spec.
Like i said, the hard coding of the food preferences was done out of
simplicity, and easily changed; nothing else is hardcoded, AFAIK.
> ; i advocate a simpler solution, both for
> > the computer, for the developers (less complex code to go through), and
> > (more importantly) for the player, which gives the same result.
> If your solution is based on the current code, then I disagree with the use
> the word "simpler". I agree the current algorithm is simpler, but its
> implementation is a mess (which is not anyones fault particularly, its what
> happens when picky special cases congregate over time). A second gain is
> could be cleaned up.
The same can be done to the current code, maintaining the simplicity and
advantages of it.
> The third gain is that it extends to other food sources/goods types with
> changes only to the specification. I was thinking we might want Hay one
> as Highwind suggested. Not a high priority, but I like future-proofing.
I would argue it extends badly.
Sampling from each type is a solution, but not even near optimal, and sure
to bring complains from players, which will see a bad allocation of
resources and cant do anything about it; actually that situation would occur
even with todays setup, that results in an artificial and inefficient
> Finally, the only defence I wish to mount against claims of complexity is
> I can not think of a simpler algorithm that is generic and extensible.
The best solution, WHEN there are other food types which ALSO have other
uses, is an allocation algorithm, which is far from simple, but is the most
generic and extensible.
Before that occurs, the current one is IMO the best:
- allows for easy change (through the spec); although not as coarse as you
would like, that still needs to be found if is a true problem; i would even
argue that is a blessing in disguise because it makes for a much easier
testing, as the changes would be more apparent.
- gives a near optimal allocation solution, with easy and predictable
results for each player change.