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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

Per I. Mathisen wrote:
> <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.

I don't get that, exactly.  But growth depends heavily on distribution 
of specials, so one city may grow quickly and another not at all.

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

I don't want to add any new free worked tiles if that's what you mean. 
The free-city-center patch eventually chose a name of 
is_free_city_center().  Note that is_city_center should still be used in 
a few places and shouldn't go away.  I think is_free_worked_tile is a 
more useful name.

>>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.

Probably.

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

Hey, I said it was experimental!

>>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?

No-free-city-center should be a ruleset option yes.

> 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.

These are all valid reasons.  On the other hand we have some good 
reasons to keep it:

1.  Players expect it and will miss it.
2.  It is needed for compatibility modes.  Civ1 and Civ2 compatibility 
are both on our list of goals.

jason