Complete.Org: Mailing Lists: Archives: freeciv-data: August 2002:
[freeciv-data] Re: [Freeciv-Dev] new generalized calendars
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: Freeciv-Dev <freeciv-dev@xxxxxxxxxxx>, freeciv-data@xxxxxxxxxxx
Subject: [freeciv-data] Re: [Freeciv-Dev] new generalized calendars
From: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 25 Aug 2002 20:47:26 -0500
Reply-to: freeciv-data@xxxxxxxxxxx

On Mon, Aug 26, 2002 at 02:05:16AM +0200, Raimar Falke wrote:
> > 
> > game.date = 1941,12,7,0,0,0
> > 
> > for labeling savegames, which is what I suppose you want, I sould have
> > to say:
> > 
> > "civgame-%d.%d.%d.%d.%d.%d.sav.gz", cal.cdate[0], cal.cdate[1], ...
> > 
> > alternately, we could add a "calendar_unit?.savelabel" boolean field
> > that specifies if the unit is needed as part of the above. That way, the
> > default calendar would save games as they do now.
> 
> You need a numeric/short version in the gamelog and the scorelog.

use the format above.

> > I'm not so sure. Give an example where this is not the case.
> 
> The freeciv default calendar. You can't tell the turn of the year
> without the knowledge about the spaceshipparts.

"turn of the year"? I don't know what that means. If you mean I can't do
a reverse mapping, well, no unless we keep track of the turn that a
change of timeframe happened.

> And this knowledge isn't in old savegames.

this doesn't matter. all old savegames are "freeciv calendar" ruleset
games, so game.year will be used to fill cal.cdate[0] and all will be
well.

> You still don't got it. The difference between your and my model is
> that I have another layer of indirection (game.calendar). This layer
> is unnecessary if all (by modpack authors or similar) requested
> calendars can be implemented with one (your) calendar. You cheated
> because with the ability to extend the calendar (builtin) you can
> model any calendar. You must agree that other calendars/whatever is
> necessary if we remove this ability from your model.

there may be some smattering of truth here, but this is really orthogonal 
to what needs to be discussed.

> > I suspect that the major features of civ should be integrated:
> > o the building of (the first of) a certain unitype.
> > o the building of (the first of) a certain improvement.
> > o discovery of a tech.
> 
> > 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...
> 
> 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
>  - building of a unittype is possible for all players
>  - first player builds the unittype
>  - all players built the unittype
>  - all players have an existing unit of this type
>  - and so on
> 
> Where do you draw the line?

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

> But the time in the game is measured in the current calendar of this
> age. Or isn't it. Well this is a philosophical question.

I see your meaning. It actually would be kind of neat to associate a set
of [calendar_unit?] definitions with a particular timeframe, so you
could start out in lunar units, move to Julian units, move to Gregorian 
units, and then move to Stardate units. It'd be awfully flexible, but
then again, really, what's the point?

> I agree that you have to prodive an "espace" mechanism.

eh? "escape"?

-mike


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