4 ms·

Saving the replay costs data though. It’s not only the reviewing.

IshKebab 7y ago
Not much data. You don't need to save actual videos, the server already has all the data so there's no network cost, and you don't need to store the data for very long. Developer cost to implement the feature would far outstrip the cloud costs.
deleted 7y ago
[deleted]
oliwarner 7y ago
Yes, I cover cost in the head comment. It does slightly come down to what sort of multiplayer experience you want. Budget in the temporary archiving of ranking multiplayer games. Sell it as a feature. It'll keep the whole thing ticking over a lot longer. The review cost is nothing. Really. Communities love to self-police so giving them the tools to do it completely, or to a point where they can identify flagrant cheaters for paid mods to verify... It's the Stack Overflow model. It works.
deadbunny 7y ago
We are talking a couple of hundred kB here. They store more in analytics.
- oliwarner 7y ago
  For CSGO it's about 80MB/hour at 32Hz (apparently the current OW rate). Many servers run at 128Hz. Logging a rolling week's activity at that higher rate requires 53GB but you could dramatically reduce the burden by only keeping things with in-game reports and then deleting recordings after the last issue was dealt with. My point is it's not nothing, but it's nothing by modern standards if you've got more than two brain cells to rub together.
  - hutzlibu 7y ago
    Then something is wrong with the logging. If you only record player input: mouse movement, clicks and keystrokes, it should be much lower.
    - oneplane 7y ago
      Except that the data logged isn't just "mouse moved x,y to x,y" but more like 'hid frame was X'. And empty hid frames are still hid frames.
    - untoreh 7y ago
      you can inspect it yourself, I assume the format is the demo record which has been available in source games since decades
    - oliwarner 7y ago
      Should it? What sort of density do you expect? 32 ticks a second, say 16 players. At least 512 state/event points to log per second, plus running game state/events. As I said, it's not nothing, but it's not bad.
    - clarry 7y ago
      It's probably recording what amounts to a demo record, which basically contains everything you would need to reconstruct the player's point of view as if you were spectating them. This means the record must contain everything the server sends to that player (other players' locations, sounds, map state changes, chat, etc.). Technically you could record only the players' inputs but to play back such a recording, you would then have to deterministically reconstruct the entire match from all players' inputs. That's a bit more complicated than just replaying the local part of the simulation that your client already does with what data the server sends to players during normal course of gameplay. oliwarner's numbers amount to about 45 bytes per frame per player, which is not unreasonable.
  - clarry 7y ago
    At that rate there's also going to be plenty of redundant information, so I think this data would compress quite well.

Not much data. You don't need to save actual videos, the server already has all the data so there's no network cost, and you don't need to store the data for very long. Developer cost to implement the feature would far outstrip the cloud costs.

deleted 7y ago

[deleted]

oliwarner 7y ago

Yes, I cover cost in the head comment. It does slightly come down to what sort of multiplayer experience you want. Budget in the temporary archiving of ranking multiplayer games. Sell it as a feature. It'll keep the whole thing ticking over a lot longer. The review cost is nothing. Really. Communities love to self-police so giving them the tools to do it completely, or to a point where they can identify flagrant cheaters for paid mods to verify... It's the Stack Overflow model. It works.

deadbunny 7y ago

We are talking a couple of hundred kB here. They store more in analytics.

oliwarner 7y ago
For CSGO it's about 80MB/hour at 32Hz (apparently the current OW rate). Many servers run at 128Hz. Logging a rolling week's activity at that higher rate requires 53GB but you could dramatically reduce the burden by only keeping things with in-game reports and then deleting recordings after the last issue was dealt with. My point is it's not nothing, but it's nothing by modern standards if you've got more than two brain cells to rub together.
- hutzlibu 7y ago
  Then something is wrong with the logging. If you only record player input: mouse movement, clicks and keystrokes, it should be much lower.
  - oneplane 7y ago
    Except that the data logged isn't just "mouse moved x,y to x,y" but more like 'hid frame was X'. And empty hid frames are still hid frames.
  - untoreh 7y ago
    you can inspect it yourself, I assume the format is the demo record which has been available in source games since decades
  - oliwarner 7y ago
    Should it? What sort of density do you expect? 32 ticks a second, say 16 players. At least 512 state/event points to log per second, plus running game state/events. As I said, it's not nothing, but it's not bad.
  - clarry 7y ago
    It's probably recording what amounts to a demo record, which basically contains everything you would need to reconstruct the player's point of view as if you were spectating them. This means the record must contain everything the server sends to that player (other players' locations, sounds, map state changes, chat, etc.). Technically you could record only the players' inputs but to play back such a recording, you would then have to deterministically reconstruct the entire match from all players' inputs. That's a bit more complicated than just replaying the local part of the simulation that your client already does with what data the server sends to players during normal course of gameplay. oliwarner's numbers amount to about 45 bytes per frame per player, which is not unreasonable.
- clarry 7y ago
  At that rate there's also going to be plenty of redundant information, so I think this data would compress quite well.