Can games be considered real-time systems?

Question

I've been reading up on real-time systems and how they work etc. I was looking at the wikipedia article as well that said a game of Chess with a timer per move can be considered a real-time system because the program MUST compute a move in that time. What about other games? As we know, games generally try and run at 25+ FPS, could it be considered a soft real-time system since if it falls under 25 (I'm using 25 as a pre-defined threshold btw) it's not the end of the world, just a hit to the performance that we wanted?

Also - games have events they must handle as well. The user uses the keyboard/mouse and the system must answer those events accordingly within (again) a pre-defined time, before the game is considered to have "failed".

Oh, and I'm talking single-player for now to keep things simple.

It sounds like games fit the soft real-time system criteria, but I'd like to know if I'm missing anything... thanks.

Answer 1

From Wikipedia,

A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. The classical conception is that in a hard real-time or immediate real-time system, the completion of an operation after its deadline is considered useless - ultimately, this may cause a critical failure of the complete system. A soft real-time system on the other hand will tolerate such lateness, and may respond with decreased service quality (e.g., omitting frames while displaying a video).

Thus, I'd say that these FPS games are definitely examples of soft real-time systems. It's ok if some frames are dropped. That said, Wikipedia also points out that a chess engine which fails to give a move in the timeframe allocated is considered a critical failure, and hence, it's a hard real time system.

Another thought is about AI in FPS-es. One could probably consider the AI as a "failed system" if it doesn't manage to return results in enough time and consequently ends up freezing.

Answer 2

Wikipedia says (and this is what I was taught in college):

A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline.

In general, most games are soft real-time, because while the frame rate target (such as 30 fps) defines a deadline, the occasional failure to meet this deadline does not render the underlying computation useless. Failures reduce the usefulness of the computation because they degrade the quality of the game experience.

As you mentioned, a chess engine is an example of a real-time system. However, this is often a hard real-time application, because exceeding the time control results in an automatic loss and the result of the computation is useless.

Answer 3

You could call them that, but I think that would be stretching the definition of "real-time." As understood in the industry, "real-time" usually implies that events will be serviced within a maximum time, where that time is usually a matter of milliseconds, sometimes even microseconds. By comparison, a chess program proceeds at glacial speeds (at least as far as the interaction is concerned). None of the special programming constraints required to meet hard real-time constraints apply to programming "slowly" interactive games like this.

"Interactive" would be an applicable word. As for video games, "FPS" has actually come to be a term used to classify such programs, which are characterized by a loop repeatedly updating the graphics and calculating the game mechanics.

Answer 4

Yes, but with lots of emphasis on soft real-time.

Being real time is not really much about being fast -- it's simply that getting a result "soon enough" is part of the definition of that result being correct.

Answer 5

Actually I don't think games are truly real-time systems. In fact most are pretty scheduling-invariant at times, particularly during loading times.

When you sit and stare at your loading bar, the system is bogged down with cache misses and is generally I/O bound. And everyone finds this perfectly acceptable.

While actually running, sure, you could consider the game real-time. But if the game becomes I/O bound due to loading a new texture on the fly, again people find this acceptable if it happens rarely enough. Same for turn-based games when you're waiting for the computer's turn.

Things get even messier when you think about multiplayer games. Especially MMO's which run "in the past" to mask lag issues. All that's doing is masking how non-real-time the game truly is.

edit: my definition of a real-time system is a system that uses every cpu cycle for meaningful work. If the system is being scheduled out due to being I/O bound for example, that's not really a real-time system.

Answer 6

Prince of Persia running on my x386 seemed real-time to me without noticeable delays. However, if conditions were not ideal, performance would certainly have deteriorated with visible lags and surely the game did not have any performance guarantees for such cases.

For a game to be truly real-time, it cannot be just a game. It has to assume control of the hardware, the OS, available resources, and define conditions under which these guarantees are valid. I don't think there are any games that go to that stretch.

Though I would partially agree on the soft real-time definition. Don't think any games publish any performance SLA's, but do their best to be real-time in most cases - it's in their best interests. That said, and definitions apart, most gaming consoles - XBox, PS[x], Wii, etc. are highly optimized for a real-time experience and deliver on that. There might be very few instances where it drops on performance like when the room temperature gets close to boiling point, but that would apply to most so-called real-time systems. A specific set of conditions must be met for them to perform optimally in real-time, or things will degrade.

Answer 7

"Real time" is a fuzzy category. It is more accurate to talk about real-time systems on a scale of "hardness". Characteristics that make a real-time system harder are:

• Bounded latency (deadlines)
• Bounded jitter (i.e. variation in response time)
• Consequences of failure to meet deadlines, and the ability of the system to "fail safe" if deadlines are missed or the system fails completely.
• Shortness of deadlines. Real-time systems generally have to respond in under a second, and most within 100 mSec.

Hence while the chess game technically speaking meets the definition of "real time", in practice it is so soft that the term doesn't really apply. At the other extreme would be the "fly by wire" avionics in a fighter jet, where failure to meet the timing requirements can cause the aircraft to crash.

Answer 8

I would describe games as hard real-time systems. Take a shooter - if you don't shoot the enemy before he shoots you, being able to shoot him is worthless, and you lose. You could make similar analogies for many other game types. Any game where the player plays it in real-time could be described this way.

Perhaps their implementation isn't hard real-time, but playing them sure is.

Answer 9

While I think we like to believe our systems are (soft) real time, one thing that I'm left wondering about is the simulation fidelity aspect of the work.

In order to fit everything into 16.6ms, we'll often do lower fidelity work in places where it presumably doesn't change the outcome, but it does yield a result (as measured by "the images flashing on the screen") that are subtly different than they would be were we to take fewer shortcuts. Obvious top-level shortcuts are antialiasing and depth of field, more subtle and less apparent to the observer are changes to "lo-fi" the enemies' intelligences if we've got a lot of them on screen. E.g. some of the first games I worked on, we didn't have time to update everyone's "view of the world," so we round robined the enemies, and we also interleaved the player character with the enemies. So if there were five enemies present, it would take ten frames to update everyone (as the player was updated every other frame). This didn't make the animations choppy or anything, though, as we still ran the proper animations, but the enemies' decisionmaking would possibly be based on old or otherwise now-invalid data.

As it turns out, this had the interesting effect that enemies would do things as if it took them some time to process what was going on. E.g. they'd keep shooting the player even if he was dead, or they might take some time before they noticed their compatriots had all been slain, triggering their scared run-away state some time after the instant they would have decided to flee had we run the "full" sim every update.

So- is doing low-rez calculations to fit into your time an acceptable tradeoff for the real-time moniker?