Earlier quoted context omitted.
I find it really weird that in inherently "networked" games (where there is a concept of a shared deterministic game-session physics-frame counter), the PC playing the game has to be the same PC rendering the game. You can recreate exactly the same view each player has from that player's outgoing network traffic! Thus, some alternatives to rendering on the user's own GPU come to mind: 1. instead of those HDMI-path re…
Lots of games used to offer "demo record" modes that did this - saving the data layer rather than the video. Or a "spectator mode". However, rendering it requires the exact same version of the game (including all mods) and typically there's no facility for high-fanout "spectator mode".
It feels like (most) studios are really dropping the ball on this one. Event-sourcing through "rules engines" isn't that hard; you can have a client that "remembers how to be" every past version of the client, network-sync/replay-sync wise. You just need to go into the game architecture phase knowing you're building a networked game.
As a free bonus, when you build a game engine this way, you can also "audit" ladder/tournament matches by (asynchronously!) running through the game physics on the server after the match, before letting the match determination influence each player's ranking. (And doing your cheat-detection post-match really eases the requirements on the client sync protocol!)
It's harder with mods, unless your mods are also cleanly separable into "presenter-level" and "rules engine" parts. Not that I've seen this particular innovation before, but if the "rules engine" parts of mods are all in some common bytecode, the particular "house rules" required to run a replay could be embedded in the replay itself, along with package URLs for fat clients (and renderer instances) to pull down the presenter bits as well.