Is Time an object of the World?

Started by
8 comments, last by MdLeadG 20 years, 4 months ago
This confuses me. If I have something like this:

class World
{ // the world - singleton

protected:
	std::list< worldobject > liveobjects;
	std::list< worldobject > limboobjects;
};
Would time be encapsulated into a worldobject timeflow, for all other objects to interpret? Or be an exclusive world member that acts as a surrogate for all objects? Or should time be contained within gamelogic, so neither the objects nor the world are in control of their own time perception?

	void	TimePerceptionMultiplier( float multiplier );
	void	TimeStop( void );
	void	TimeStep( void );
	void	TimeJump( float interval );		};
Or should there be a ITime interface that gamelogic, world, and worldobjects bolt-on for time perception? Any advice would be appreciated. Edit: widescreen formatting issues [edited by - mdleadg on November 29, 2003 3:03:15 PM]
Advertisement
If you were to make a physics manager class, the time (as well as other physics-related procedures) should be encapsulated there.
Increment the time variable each frame by measuring how much time has passed between last and current frame.
Also, you can use the delta (frame time difference) to drive all other physics as well as to count the current fps!

-Nik

EDIT:
A few games use multiple physics timers, a recent example of which being the new Prince of Persia. It features an own timespace for the main character, as well as the "world time".

[edited by - Nik02 on November 29, 2003 3:07:32 PM]

Niko Suni

See that''s what I was getting at. Bullet Time has been done before, and of course Prince of Persia, but wouldn''t encapsulating time into everything that perceives it be a more realistic model? I wouldn''t think this would have any *huge* advantages, as multiple space-times while very interesting to discuss and a viable life commitment, the majority of the time would probably have awkward gameplay issues and such. But modeling different type of physics, besides light, sound, aeronautics, etc. I think is very cool.
For example you could have this:
class PhysicsModel {};class World{protected:     PhysicsModel physics;}; 

implying multiple space-times, or this:
class PhysicsModel {};class GameLogic{protected:     PhysicsModel physics;}; 

which has only 1 space-time.
In reality, what we call "time" is just energy moving around.
The time flow perceived by an individual is just a delayed sensation of the effects of this energy flow.

Therefore, in reality, time doesn't change it's speed by observer; this is in contrast to the aforementioned games, which obviously needn't/won't follow real physics.

It is perfecly correct to store one "world time" and, for bending the rules (time stop, rewind etc.), define additional timespaces as needed.

-Nik

EDIT:
I would put the physics engine into the game logic, and add an own time routine for "time manipulator" characters.

[edited by - Nik02 on November 29, 2003 3:46:53 PM]

Niko Suni

You''re right - I believe time is nothing more than a particular view. I think of space-time as a big chunk of stuff, and depending *where* you are, determines both where and when. ''Where'' being fully realised with the addition of a fourth dimension.
Thinking that, I can''t believe that world->physics->time->rewind() would bend the rules at all. world->physics->position( x,y,z,t ) would be how I would time travel.
It's just that in our known reality, it is not possible to directly modify the energy flow known as time in it's primitive level.
As for a game character: I think you should treat the time as an ordinary dimension, taking frame of reference from the universal time; translate the character along that dimension as necessary if the said character does have the ability to affect time flow.

-Nik

EDIT: clarification

[edited by - Nik02 on November 29, 2003 6:17:35 PM]

Niko Suni

Time is relative. The way I do things (and I think the Unreal Engine does also) is pass float deltaTime (in real world seconds) to all my update functions (or you could make it a readonly global of some world management singleton). If some object wants to move in slow motion it simply multiplies the real world time change by a time modification factor.

Simple and effective

-SniperBoB-
Remember that the player can''t be moved in the REAL flow of time outside you''re game, so the only option is either ONE time flow for the whole game, or two: one player, one the rest of the game. The player one is treated normally (always moving forward), but the rest of the game can bend.

quote:Original post by SnprBoB86
Time is relative. The way I do things (and I think the Unreal Engine does also) is pass float deltaTime (in real world seconds) to all my update functions (or you could make it a readonly global of some world management singleton). If some object wants to move in slow motion it simply multiplies the real world time change by a time modification factor.

Simple and effective

-SniperBoB-


This is simpler way of saying the same thing I said in my previous post
Global delta is the per-frame world translation in time axis.

-Nik

Niko Suni

This topic is closed to new replies.

Advertisement