Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2001:
[Freeciv-Dev] comments on ics solutions
Home

[Freeciv-Dev] comments on ics solutions

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <freeciv-dev@xxxxxxxxxxx>, <silakka@xxxxxxxxxxx>, <mike_jing@xxxxxxxxx>
Subject: [Freeciv-Dev] comments on ics solutions
From: "Michael Kiermaier" <michael.kiermaier@xxxxxxx>
Date: Wed, 28 Feb 2001 02:06:48 +0100

hello everyone.

i write this email because i want to comment on some of the
suggested methods how to overcome ics, especially on mike jing's
"persuit of happiness" (http://www.freeciv.org/tutorials/nopox.html)
and on the suggestions recently made by jussi asp
(http://arch.freeciv.org/freeciv-dev-200102/msg00387.html).

first i describe how a enjoyable game should look like in my
opinion:
each player has to find a balance between building new cities and
develop existing cities. the optimum should be somewhere
between these two extremes and there should be a variety of
successful strategies.

with the default rules ics is by far the most successful strategy. but
ics does not fulfill the mentioned criterion.

so the rules must me changed in some way. i agree with mike jing
that a good solution should adress the cause (see jussi asp's mail
for the causes) instead of the symptoms. this is not true for these
two suggestions for example:  minimum distance between cities
and for the no science for size-1-cities. the former also makes an
interesting strategy impossible: to connect two oceans with two
cities.


but i think that also mike´s solution does not really adress the
cause: the main reasons for ics, free city center and growing
granary size, are still valid. it rather restricts the most important
symptom, the infinite city sprawl, in a somehow artificial way, and
you can use ics in the used way until you reach this barrier.

in my opinion it is simply not logical that at some point it is bad to
get a new city, no matter if built, conquered or more dramatically
found in a hut.
maybe you want to argue that it gets more difficult to reign over the
people as the country grows. but this could also be achieved with a
unhappiness which depends on the form of the government and the
distance (or as someone proposed the travel-distance) from the
capital (like corruption). so there would not be a sudden penalty for
all the cities but a more intuitive penalty for remote cities.

now one could argue that this is a further reason to build the cities
close together. but together with jussi asp´s changes it will be better
to have one big city instead of two or three small ones that have to
share its space.

please note that i did not say that i do not like higher unhappiness. i
agree with mike jing that the game is way too fast. decreased
happiness is a elegant method to slow down the game, because it
brings the luxury rate back to the game.


to get rid of the causes for ics i would suggest to use jussi asp´s
proposals. in his mail it sounded like he already implemented some
of them. it would be nice if he posted some patch.

>> 1. granary size doesn't grow, always the same as foodbox.
>> ( done by setting option granary_food_inc        = 0
>>   in game.ruleset )
>> - to make city growth faster

i suppose a basic size about 30 and maybe a slight increase (2 or
3),

>>2. settler/engineer takes away 2 workers instead of 1 ( this i had
>>to hack in )
>>?? should this option be made to game.ruleset or make
>>units.ruleset more
>>flexible by adding amount of workers unit takes from city ??
>>   from city and costs 60 ( set in units.ruleset )
>>  ( either this or standard settler should build a city which only
>>   has 1 worker, which I feel would be too odd. )
>>- to prevent exponential empire growth with new cities

a elegant way to stop the exponential growth.
maybe at this point the settler unit should be split up in two units (as
already proposed by some people):
* a settler unit which can found new cities (costs 60 prod and 2
workers,  needs food upkeep)
* a "pioneer" unit which can build roads, mines, irrigations... (costs
40 prod, needs no food upkeep)

>>3. city, trireme, caravel, galleon, frigate, ironclad view radius is
>>bigger
>>( city view radius I had to hack in, other can be set in
>>units.ruleset )
>>?? is game.ruleset right place to put option city_view_radius,
>>which would
>>probably be better to have minimum of default city work area ??
>>- I feel city should be more easily defendable against land-
>>atacks,
>> and to balance things I gave ships a better view radius too.

sounds reasonable.

>>4. city improments cost 3/4 of default. ie 80 -> 60, 100 -> 75
>>( set in improments.ruleset )
>>- this makes city improments more attractive to build

maybe this is not really necessary. but i always felt that city
improvements cost too much. i think 3/4 is a reasonable factor.

>>5. min_city_center_shield = 0, ie. city center gets no free
>>production if
>>terrain has no production.
>>( set in game.ruleset )
>>- i see no reason to give free production.

restricts the number of squares suitable for city foundations, so
cities cannot be built so close together. maybe this should also be
done for the food value.

>>6. initially visible radius is 6
>>( set in game.ruleset )
>>- find a good spot for first cities easier, as it is more important
>>when new
>>cities are harder to get.

very good point. with the default value it depended too much on
luck.

>>7. settlers have 2 movepoints, which means they also work
>>faster.
>>( set in units.ruleset )
>>- you want to improve terrain / build roads when it's faster.

this is not necessary. split settler units as described at 2.) maybe
the pioneer unit should have 2 movepoints.


i really would like to see this features in freeciv, because i think this
is the most elegant method to stop ics that was suggested up to
now. together with a higher importance of luxury i guess that freeciv
could get back its "civilization part" which was lost when ics
appeared. please comment !! (especially mike jing and jussi
asp :) )

~michael





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