1.1 Name: Time Explained
1.2 Author: Brian Jones brianj@otterspace.com
1.3 Purpose: describe the concept of real time and VR time within the NMC2 environment
1.4 Creation: April 25, 2004
1.5 CVS $Id: time_explained.html,v 1.1 2004/06/24 21:22:47 brianj Exp $
1.6 Change history
1.1 series of email messages between almost the entire project team
1.2 See the Core Concepts document for definition of terms used.
1.3 Log of events on April 25, 2004 on Nameless MUCK
Time is used throughout the system for a variety of purposes. In this document, there are two ways of regarding time that we are concerned with.
The first involves times in the real world that players perceive. This could be a decision of having the MU use GMT or ensuring the MU knows its own time-zone offset from GMT. This is crucial in scheduling things to happen at a specific time in the real world. If the scheduling is between players, we're treating this as "outside the scope of the MU". If the scheduling relates to something the core must trigger, than it's included in this document.
The other time is the time that should be perceived in the VR context by characters. This is the realm of seasons on distant planets, or space-craft that keep a 20 hour cycle, etc. Here, the MU is the only source of timing information and the notion of elapsed time may not match real time in any manner.
Players deal with vagaries of the real world. They have time-zones, which may or may not have daylight savings time. They have the same basic calendar in most places, but not all.
Java happens to have a huge array of existing code to deal with these issues, but most of it is outside our scope anyway.
The places that the MU needs to worry about real time are:
We could certainly provide an easy means for players to specify their time zone relative to GMT in a way that Java understands, so that we can show "clock time" in the right zone for the players. That doesn't force people who post messages in places like emails or websites (or even in the game) from carefully noting what time-zone the times they are posting in relation to are in.
So, for all intents and purposes, trying to help players co-ordinate the times of their events is probably not terribly useful.
However, the system should allow the management to specify times precisely to any zone, so the core must provide detailed time support.
In the VR world time may flow at different rates in different places. It may or may not correspond to real-world times, dates, seasons, or even day/night cycles.
Time in the VR world is whatever the characters are intended to experience.
To allow a VR context (an area that is considered "within a single VR rule-set") to have a consistent time-keeping mechanism, there needs to be a VR Timekeeping object that can be accessed by the characters and their automation.
This would have whatever logic the creator specifies to answer questions like "Is it light or dark out?" "What's the season?" "What's the day?" etc.
The object can have other distinctions added into it if desired, perhaps, "What's the position of the moons?" or something.
Thus, all temporal management of an IC context can be put into one place.
If a VR space is large enough that the area has multiple internal time-zones, then multiple time objects can be used. They can either be stand-alone objects in their own right (such as a science-fiction universe might have such that each planet got its own notion of time) or they could be subordinate to an existing Timekeeping object and just provide some form of offset (such as time-zones on a planet in science-fiction).
There needs to be standard permissions established to allow easy management of the Timekeeper objects.
When something should happen in a finite amount of time from now (and possibly recurring) then we don't use the Timekeeper, but rather use the system Timer.
This allows us to request that an event we provide be sent to a target object we provide either in N time-units or every N time-units.
Don't set things for absolute times if you only need durations! Durations are much cheaper.
Timekeeping may be a nuisance in the real world, but we'll expose the Java classes to at least give our scripting programmers the means to be as accurate in their real-world time as they need.
We ensure that time in VR spaces makes sense, so that supporting things like NMC1's "@timedesc" will still be feasible.
And we setup the Timer to handle shooting events when a time period elapses, thus reducing the number of programs that need to do loops that have "sleep" within them.