Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: non-smallpox idea

[Freeciv-Dev] Re: non-smallpox idea

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jacky Mallett <warlock@xxxxxxxxxxxxx>
Cc: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: non-smallpox idea
From: Reinier Post <rp@xxxxxxxxxx>
Date: Sun, 25 Nov 2001 16:27:50 +0100

On Sat, Nov 24, 2001 at 07:10:13PM -0500, Jacky Mallett wrote:

> My opinion is that whatever solution we come up with should be easy
> to understand, and its consquences easy to predict. I fear i'm with the
> game playability camp, rather than any attempts at 'realism'. Nor am
> i in the small-pox is evil camp either, quite the contrary - but i do
> think the game would be enhanced if there were several overall winning
> strategies, rather than just one or two as at present.

This is my opinion exactly, but I am not that pessimistic: you only have
to tweak the default command line settings a little to make alternative
strategies viable, and then there are the rulesets which very few players
seem to experiment with.  Of course economic growth is always a major
success factor  but that is just afact of life.

> My suspicion is most players don't understand the corruption impacts
> at all for any other government than despotism, and up until recently
> at least, it was just one of those general mysteries how certain
> players got republic so much faster than others.

Huts are a nice feature here, but most games are played without them.
> In terms of actual impact on the game, i don't personally think the
> present time to republic is unreasonable, but the level of variation
> due solely to lucky initial conditions is.

I don't think so.  It's nice to be lucky once ina while - that's
why I like huts - and you can always start another game ...

> If you do understand despotic
> science then for smallpoxers at least, this is typically in the range
> 2700bc to 2000bc with the former requiring a lot of luck in your initial
> position. A 2500bc republic is quite frequently achievable though,
> which gives a 10 round variation, before the random change
> factor gets thrown in. In and of itself, this is enough to decide games
> between two well-matched players; whatever strategy they're playing.

Yes, but I think the luck factor is acceptable.  Settings that minimize
it (such as generator 2 or 3) tend to produce very predictable games.
It's boring to know in advance who you will be losing to, and in which way.
(Speaking from ample experience.)

> Fixing science to the number of cities, and allowing only the capital
> to have full science, would bring this variation down a lot.

But it is already the case that only the capital has full science.
The only problem is the fact that everything below 1 gets rounded up to 1.

> > Well what i like about it is the word "proportional", but what I don't
> > like is the introduction of a new factor.  I'm sure it would already
> > help to make the existing factors, such as distance, more proportional,
> > as that is where the problem seems to be.
> I'd agree with you about the introduction of a new factor, if i thought
> that all that many players really understood what was going on with
> corruption in any case.

But that is because its effects are not proportional.
Tooltips and hyperlinks in the interface would also help, of course.

> In game play, people will sometimes micromanage
> trade for a little while in republic if they want to get one of the
> critical early advances, but by the time you get up to steam engine
> individual city differences tend to get averaged out enough that the
> difference isn't useful.

That's OK - by that time you don't want to micromanage as much.

> I can't think of any other solution that is this simple, and that evens
> things up between the two.

Rounding in a different way?

BTW I took a look at the common/city.c:city_corruption() and it is
far more complicated than I realized.  Thresholds and if-cases all
over the place.

> ...jacky


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