[freeciv-data] Re: [Freeciv-Dev] Re: new generalized calendars

[Davide Pagnin <nightmare@xxxxxxxxxx>]

On Mon, 2002-08-26 at 03:47, Mike Kaufman wrote:
...
> > > I suspect that the major features of civ should be integrated:
> > > o the building of (the first of) a certain unitype.

I vote for this to be in.

> > > o the building of (the first of) a certain improvement.

I vote for this to be in.

> > > o discovery of a tech.

I vote for this to be in.

> > 
> > > o I suspect that Per might like something like the death of a certain
> > >   unittype (like a Sauron unit), but I think that might be going a bit
> > >   far...

Destruction of a unique unit_type, is useful, so I'll vote to be in.

> > 
> > And exactly this is the problem: where do you draw the line? You may
> > also want certain modifications like:
> >  - building of a unittype is possible

I like this too.

> >  - building of a unittype is possible for all players

Not necessary.

> >  - first player builds the unittype
> >  - all players built the unittype

Not necessary.

> >  - all players have an existing unit of this type

Not necessary.

> >  - and so on
> > 
> > Where do you draw the line?

(Obviously we need an agreement, and we can decide only by voting, if we
are a democracy[are we??])
> 
> Yes, this is exactly the problem, and I would like the people on 
> freeciv-data's opinion about this. After all, what we're _really_
> talking about here is only ONE change (aside from ignoring the spaceship
> and tech doubling rules) in the mechanics of the game and that is that
> with the change of timeframe, we get a possible change in the end game
> date. Since everything else [should] be determined by turn number,
> changing how "time flows" really only materially could change the number
> of turns left in the game.
> 
> Example: if we were to only throw out the spaceship and tech doubling
> rules, AC would have its calendar. Nothing else is necessary. The only
> thing generic calendars change is making the representation of a turn 
> look pretty. (not to say this is completely unimportant)
> 
> So which of the above features should be implemented, keeping in mind
> that we only thing they might change (depending on how you write the
> ruleset) in the number of turns until the end of the game?
> 
> Raimar appears to want none as well as getting rid of the patches
> tech_req and tech_trigger. I have no strong argument against this. As a
> pro: the code's already in the patch, it's not large and it'll probably
> be useful to somebody. However, the code is certainly not as elegant as
> it would be without. Do any of the modpack writers (or anyone else) see 
> a clear need for such a feature?

I'm not a modpach writer, but I think that tech_req and tech_trigger (as
concept) have to be maintained.

The flexibility we can get from this, can be useful, and I hope that we
will agree that some tech have changed the time flow perception if seen
by an historic point of view (someone has proposed computers, but we can
say also steam engine, flight, electricity, internet, any thing involved
with transportation and spreading of information).
Thus if we consider this from a 'game' perspective, the only way to
allow to do more thing during the same amount of time, is the
possibility to split into pieces what a turn can be considered.
(This cope well with civ style calendar, 50 year/turn, than 20, than 10,
and so on).
And I say, that it is more 'realistic' that those leap are linked to
discovery of a tech instead of historic timeline.

The question is also 'where put the line', and I answer to this that a
compromise is the best point, we can agree on what to code (and if the
code is already present, way we have to waste it?) and what to not code
(for the moment), if an extension is wanted/requested from a modpack
writer, we can easily add.
(This resemble Raimar - hardcoded way, and perhaps it is so, but I
disagree with him on where to 'put the line' and on the possibility to
change the calendar via a ruleset).

> 
> I would support writing code for my first two above (1st of a certain 
> unittype and 1st of a certain improvement (the 3rd is already in the
> patch)) The reason for doing so is analogous to the the tech code.
> Again, opinions on usefulness?

I agree with you, and that those points deserve implementation.

> 
> I don't like Raimars strawman ideas, either because they're covered
> already by by the 3 I've suggested, or they're far too esoteric.
> However, I have no strong opinion. 

I think that having the knowledge to build (unit or improvement) is
worth to be coded, I volunteer to make the code if this is required.

I hope that Per will contribute the 'unique' unit death part of the
code.

        Ciao, Davide