I often refer back to internal design documents and bug databases while writing these "what's new" blog posts, but it rarely makes sense to quote directly from them. In this case, though, the existing text seems clear enough that I shall simply plagiarize it.
It all started when I filed this bug:
The RealTime members of the GameTime class are confusing and not really useful for anything. Since developers are always better off using the *GameTime members, maybe we should remove *RealTime entirely to avoid confusion?
Because this alters an API that we already shipped, it had to go through a formal DCR ("Design Change Request") process, to make sure the implications were properly understood, and to give the stakeholders a chance to approve or veto the change. Here is the more detailed text I wrote up to explain the DCR:
The GameTime class currently exposes four properties:
- TimeSpan ElapsedGameTime;
- TimeSpan TotalGameTime;
- TimeSpan ElapsedRealTime;
- TimeSpan TotalRealTime;
This DCR proposes removing the two *RealTime properties, and also changing the two GameTime constructors to remove the associated *RealTime parameters.
These properties were intended to provide a more direct connection to wall clock time, bypassing the smarter logic used to compute the *GameTime values. However, experience has shown that:
- This data is rarely useful. Most often, people who think they need it would really be better off just setting their game to variable timestep mode, in which case *GameTime and *RealTime collapse and become the same thing.
- For the (vanishingly rare) handful of cases where people really do need this data, they can get it just as easily from any of the other .NET timer APIs (Stopwatch, Environment.TickCount, DateTime.Now, etc). There is no need for us to provide an alternative way of accessing that same data.
- Putting this data in our GameTime class is confusing for our customers. We frequently see people not knowing which version of the data to pick, erroneously guessing they want the *RealTime values, and then running into trouble because this does not actually do what they want.
- The ElapsedRealTime value is especially confusing, as it is not at all well defined what this means (or should mean) during a Draw method. Since RealTime does not have the same tick concept as GameTime, what should this value be relative to? Our current implementation arbitrarily picks one definition, but this is not really useful for anything.
Dev cost: 2 hours.
The DCR was approved, so ElapsedRealTime and TotalRealTime are gone from Game Studio 4.0.