adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Schedules


From: Kai Sterker
Subject: Re: [Adonthell-devel] Schedules
Date: Wed, 1 May 2002 18:46:49 +0200

On 01 May 2002 18:08:43 +0200 Alexandre Courbot wrote:

> I think that the game cycles defined in gametime should be the time
> basis of the whole game. If we start defining other time measures
> classes, we'd end, in that extreme case (that shouldn't happen, but
> that is taken care "in case of"...) with stuff that gets slowed down
> (like the map engine) and other stuff that isn't (the opponent would
> take their decisions at the same speed, while the rest of the game
> slows down). That's why I'm strongly for adopting a single time
> measure method, no matter what it is - I have nothing against
> improving/rewriting the game cycles stuff.

That of course is right. The only sensible solution is to say that a
certain number of game cycles make one in-game minute.

And we need to have minutes (and hours and days), so we can distinguish
between day and night, can have special 'events' like market day and all
sorts of things. Savegames would get a timestamp too (something like
"Day 3 - 14:45") so you can easily spot what was the most recent game.

Besides, it's alway nice to know how much time one has spent within the
gameworld :).


As far as implementation goes, I propose the following:

The gametime class keeps track of the (gametime) minutes that passed
since the start of the game. It also allows to specify how much cycles
make one minute at runtime. So we can for example slow down gametime
while the player is examining the inventory or stats or during
dialogues. We should also be able to pause the clock.

Then there would be a date class that keeps track of the total amount of
gametime spent in the game. That means it would be able to save and load
it's state (unlike the gametime class).

The date class further provides a number of utility functions to turn
the gametime minutes into hours, days and weekdays, test whether it is
day or night and maybe other stuff. Each time one of those functions is
called, it will update itself from the gametime class. That way, the
gametime class will remain independant from other stuff. Things like a
time_event or the schedule manager would make use of the date class
instead.

Does that sound okay?


Oh and another thing. Since all that stuff is closely related to the new
mapengine, I would add it to the 0.4 branch, instead of making a new
branch. There's no use in adding it to 0.3, but it will need a mapengine
to test the schedules.

Kai



reply via email to

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