I might misunderstand you now, but what do you mean with "streaming bits from local servers" etc? My point was that the only way a kill cam can work in a BR is to collect data and then let the client of the viewer of the kill cam reconstructs the sequence locally based on that data. Its not possible from a technical standpoint to actually have a kill cam that records clips retroactively. So it should have nothing to do with streaming limitations etc, since its just a couple of mbs of data that reconstructs the sequence.
And the problem is that it seems to be impossible for any replay or kill cam technologies to reconstruct 100% copies of what really happened, especially when it comes to crosshair position since that would require like 100-150 data points on exact x,y,z position every second. Less than this and the reconstruction would need to interpolate the position for the missing ones and suddenly, the replay isnt accurate anymore. So all Im saying is that a kill cam would probably just increase false cheater accusations.
Why do you assume I'm not a programmer? I'm not a game developer by any means, but I do full stack web development and have friends who do game development.
Regardless, this is still technology that would cost a lot for next to nothing in return. This isn't a "just capture my display" replay, this would have to be a full match replay.
On top of that, you'd need some sort of middle ground between the client and the server. You've got to remember the server does a lot of trying to predict players movements, so when it comes to replays, a lot of it would probably be server movements instead of actual player movements; while identical, you'd never get the full picture.
And again, storage space for something like that would outweigh the small benefits we'd get from that. Apex is a huge game with a lot going on at once, they're already pushing the limits of the engine as it is.
I pulled this of in CS LAN party game comps. So why cannot they?
They would not need to keep it all. They would only need to keep the few records that get reported. And not any longer than is needed for a review.
Think of it as a flag system. If a player get flagged many times during X number of games, they keep the recording for review. Just 1 or very few flags get ignore and data removed.
"so when it comes to replays, a lot of it would probably be server movements instead of actual player movements; while identical, you'd never get the full picture."
This has been a problem with any kind of kill cams used. But in the proven systems like in CS, people know this and the PRO's only care about the things that proove aimbot and wallhack, and other blatant cheats (speed hack etc).
"would outweigh the small benefits we'd get from that"
NOT AT ALL. Let me remind you that this is a competitive games that wants to be a huge part of E-sports. Fairness and trust is EVERYTHING in that regard!
To record kill cam with perfect replay is very possible. We did that many years ago in CS in LAN party competitions. So why not online? Earlier the real limitation was that most gamers worldwide and most servers did not have the capacity (line and processing power). But todays internet speeds and the server power (and way they take advantage of Virtual servers), this is possible for sure. But they could improve the tehcnology and code further to capture longer replays than what we did back in the day.
To some of you saying it's possible to have a "perfect replay"...
Yes and no, you can have 1:1 replays within reason by upping the tickrate of the servers.... or having a client side replay being recorded for the suspected player, which is never EVER going to be secure.
Someone else on here mentioned low tickrate (or specifically low amount of data points) and he is perfectly right about this..
Running 20 tick servers means you are essentially recording 20tick demos/replays as a result, even if you do client side replays on your end you are seeing opponents being sent at 20tick (and you have interpolation/antilag delay on top of this).. interpolation is used (and would be used for demos as well) to smooth this out or everyone would be stuttering across the screen.
Others have mentioned cs on here as well, which pretty much means they are talking about HLTV (or local demos as mentioned above).. both are subject to the server tickrate as the clients are sending roughly 20tick anyway.
And even if you were using something like HLTV (which is basically a proxy server, simulating a client) you are going to end up with the exact same problems, on top of being massive resource hogs (unless you are limiting the proxy tickrate to counter this as you are ignoring PVS i.e the players you can see and sending all positions at all times which is intensive as hell... and in the end ultimately defeats the point).
The only way you are going to effectively (or as effectively as you can) combat cheats is to go the way of valorant with a very invasive kernel level anticheat... which opens up a whole other discussion about trust and security.
@pitchsomfanFun fact, I've seen a bunch of people report cheaters in Valorant. I only played the game once for about an hour. Most players seemed legit, a few.. eh not so much.
Just because the anti-cheat is on a kernel level, doesn't mean a cheat can't act like an innocent app and get through it.
I have to use a special browser for school, that's suppose to "lockdown" the system and forces applications closed. It only bothers to make me close Discord, Xbox Toolbar (where Windows has access to Xbox stuff), and sometimes my calendar and email app. It's suppose to force my browser to close as well, but I've been using Opera. Which, it doesn't ask me to close.
The whole point of this browser is to prevent cheating in tests. If something like this can't detect a special kind of browser, what makes you think a kernel level anti-cheat won't make the same mistake?
Community ManagerCommunity Manager
