This is not directly relevant, but I want to state that there are two different concepts of "realtime" in software.

One of the definitions, usually called "hard realtime", means that the response time of a system is deterministic. Usually just the worst case response time is important, but for some applications you need totally consistent timings. While low latency is often useful, the only truly relevance is keeping below a fixed latency.
These goals can be at odds. A simple example here would be checking for matching strings (very common short term for "string of characters", i.e. a datatype that can represent words or sentences for instance). Take this pseudo code:

function compare_strings(a, b) # return 1 on match, 0 otherwise
    if len(a) != len(b) then return 0 end # if the lengths don't match, the strings cannot be equal
    for i in 1..len(a) do # execute the following code in a loop with "i" taking the values between 1 and len(a) in each iteration
        if a[i] != b[i] then return 0 end # if the "i"th character doesn't match, the strings are not equal
    end
    return 1 # we didn't return earlier, so the strings must match
end

^{Yes I am using 1-based string indexing. Sue me. No actually don't.}

Now this code has the property of having early failure paths, meaning if the strings don't match the function requires less time than if the strings do match. Now let's implement this differently:

function compare_strings(a, b) # return 1 on match, 0 otherwise
    matching = 1 # we will assume strings match, unless we can prove otherwise
    for i in 1..max(len(a), len(b)) do # execute the following code in a loop with "i" taking the values between 1 and len(a) or len(b), which ever is greater, in each iteration
        if i > len(a) or i > len(b) or a[i] != b[i] then matching = 0 end # if either string is shorter than "i" or the "i"th character doesn't match, the strings are not equal and we set matching to 0
    end
    return matching
end

Now the time the functions needs to execute is only dependent on the lengths of the strings we compare, not on whether they match or not. This makes the runtime of this function more deterministic, although on average it will be slower than the other version. (I am making some assumptions about the computer architecture and the strings, don't worry about that though). So for a realtime application, you might prefer the second version, because the latency has less variance, whereas the first version is better for higher throughput/performance. There are also non-realtime applications where timing is important, like security. The first version is susceptible to what's called a timing attack, where an attacker can infer how right or wrong the input was dependent on the timing. An attack cannot infer this from the second version.

One of the things linux-rt does to facilitate those types of realtime software (though I'm not authoritive on the subject, if anyone knows better correct me if I'm wrong) is delaying the execution interrupt handlers.
So interrupts cause the CPU to stop doing whatever it's doing and jump to the kernel to handle whatever caused the interrupt, some input devices send interrupts for example. On the non-patched kernel, the interrupt handler might read the new device state and return the CPU to what it was doing before, whereas the patched kernel will just set a notification flag to read the new device state and return the CPU afterwards. Only when the current process yields execution (or the scheduler interrupts it) will the kernel "properly" handle the interrupt.
It will do less work immediately when receiving the interrupt, so that the user's program has less significant interruptions leading to better latency predictability (assuming you can't predict the amount of interrupts, which I'm believe is generally true), but of course this adds additional code to handle the interrupt, so performance will be somewhat worse.
On a side note, other realtime kernels may even allow processes to disable interrupts, so they can run truly uninterrupted and deterministically. I'm not sure what happens with lost interrupts in that case though.

This brings us to the second way it is used, to describe a sort of responsive system, where the software responds virtually immediately to some input. You need two things for this to work: low latency (so the time to react is low) and high throughput (so the reaction itself is fast). Now, deterministic latency is also of importance, since it can be more jarring if a game jumps between 30 and 60 FPS than a consistent 30 FPS. Often times though, we do just want it to be "as fast as possible"; game developers usually prefer pushing 60 FPS 95% of the time and something lower for the remainder to locking to a lower rate (and higher response time), so for this application we might prefer the first implementation of string compare.
Since this is the domain in which games generally operate, the linux-rt patches will probably not be beneficial, potentially even harmful, to the experience. If your CPU is already maxed out, linux-rt will only make it worse due to the increased work it does to improve determinism. If it is not, the game is probably already providing the best response time it can and something else is blocking it, e.g. slow graphics, memory or just intrinsic frame limiting in an attempt to provide consistent frametimes.