Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2004:
[Freeciv-Dev] Re: (PR#11311) death to smallpox?
Home

[Freeciv-Dev] Re: (PR#11311) death to smallpox?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#11311) death to smallpox?
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Fri, 3 Dec 2004 08:27:16 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=11311 >

On Thu, 2 Dec 2004, Jason Short wrote:
> The game design is based on ideas from MoM.

Very nice. Although playing it is... not so good. My cities never grow.

Why is_free_worked_tile()? Do you want to generalize this? Why?

> This is quite experimental for now.The ruleset needs to be balanced,
> the AI needs to be fixed

Your AI fixes look mistaken, since we only check best and second best
now, and this must change. Should not be hard to implement autobonuses,
though.

Although I cannot tell exactly what you are doing, since your code is
sorely lacking in documentation (eg function headers). This is bad.

> 1.No free city center, of course.  I didn't take Mike Jing's patch but
> just hard-coded this.(Tile workers are still allowed, unlike in MoM,
> but without a free city center and with reduced tile inequities this is
> more of a micromanagement issue than a fairness issue.)Unlike the
> Mike/James patch there is no free per-city food given.

Do you intend to make it an option?

I would strongly advice that we at least consider the idea of removing the
worker model entirely. Here are my reasons:

 1. If we combine workers and autobonuses, then workers will be even less
important to micromanage, and hence the effort to do so will remain the
same but the yield much less results. Therefore, we should stick to one
model only. Make it simple.

 2. The worker model code is very complex and will be hard to maintain.
The logic in the server's auto arrange worker code to ensure that cities
do not step on each others' worker allocations is insanely complex and not
well designed. See eg freeze_workers() function header comment, and
auto_arrange_workers(). We go to great pains to avoid infinitely recursive
calls. So if it is not used in default, it will quickly bitrot.

 3. The worker model code (including CM) is still bug-ridden. Although the
core code is now well tested, it is not well designed. Future changes are
very likely to break it badly.

 4. Worker arranagement is extremely CPU intensive. After path-finding, I
believe this is the largest server (AI) CPU sink. It is a limit on what
the AI can do, as whenever a city changes, we want to rearrange, but this
is expensive, so we sometimes do (eg govt eval) and sometimes don't (eg
building eval).

 5. It is a (mis)feature that won't be missed by most players anyway.

  - Per





[Prev in Thread] Current Thread [Next in Thread]