Tarkov studio claims it actually doesn't have the server capacity for everyone who bought the game for $150 to play its upcoming PvE mode, still wants players to pay extra
Tarkov studio claims it actually doesn't have the server capacity for everyone who bought the game for $150 to play its upcoming PvE mode, still wants players to pay extra
Battlestate Games continues to assert that this upcoming mode does not constitute "DLC," and is thus not part of the $150 bundle.
You're viewing a single thread.
Yeah honestly, I bought Tarkov second-hand for $8 and even then I felt like I was getting ripped off.
It's probably not news to anyone but the game has extremely lax anti-cheat controls.
As for why people would cheat in an online game, it always seems obvious from a psychological standpoint, but the cheats for Tarkov are so egregious they're like full blown developer offline DEBUG TOOLS.
I don't mean "oh no, aim assistance, and they can see you through walls" -- the cheat tools are hooking into features of the GAME ENGINE ITSELF, allowing players to see:
PlayerName, Current HP, Current Level, Full inventory contents, currently equipped weapon, position, heading, estimated value of inventory, estimated value of your account, age of account creation, and so on.They can also: Teleport, FLY, increase or decrease their run speed, jump height, and so on.
The cheaters are basically running around with admin privileges in the game, and the developers don't give a flying fuck. It's like GTA5 levels of cheating.
Why would anyone play such a game, much less pay $150 to be abused by people? You can slam your dick in a car door for a lot less.
Whats sad is that people keep wanting more client-side anticheat to fix this, when the real answer is server-side anticheat and changing the engine to stop being so leaky with that much information.
It's easy to just handwaive and say "Server side will fix it" but here's a major issue:
You have to render people in before they appear. How do you do that without the client knowing where people are?
but here’s a major issue:
You're acting like other games have never successfully ran server-side before. Hell the whole net engine doesn't need to be server-side at all. But you can run server side checks on shit at the very least. A player being 100 ft in the air is likely a cheater... A player making a shot through impenetrable terrain is likely a cheater. Tarkov is missing these basics. Forget ESPs and other bullshit.
If you should absolutely be checking for repeat issues and basics. Not trying to excuse that shit, just saying server side isn't a silver bullet.
If the trajectory and speed says either the client or another player will cross a wall soon where the player sees them THEN it could send the data to the client. You need some tolerance for ping up to maybe 200ms but that's it. Wallhacks could give you at most a flash of a couple specific people.
You need to account for every gap in the wall, nook and cranny and peephole for these sightlines. You'd have to bake so much detail into every calculation server side that it would effectively be rendering the entire map to host a single game.
There are many ways of doing this. I know the source engine uses visboxes, which are calculated once at map compile time. It takes a while to compile, but it means that clients can use the pre-compiled data to calculate parts of the map that are visible and the server can use them to determine what the player can see at a given time. I'm not sure whether it does that or not, but it would make sense to use that data.
It could be a client-side check with verification on the server. Basically transmitting which places are in view. Ray casting like the other person said. Not raytracing which is much more computationally intensive. A server side check basically so that the client can't just say they're looking around every corner at once.
But then you're adding extra latency to all visual calculations.
Your client needs to know if something is visible within the framerate of their PC.
You cannot do that fast enough.
Why not? More computationally intensive things are done to calculate lighting in a lot of modern games as I alluded to. Yes it would increase the load on your CPU but that's less of a problem nowadays with higher core counts and clock speeds and it's not like modern anticheats don't steal some CPU cycles already. I think you underestimate the power of modern computers. I'm not trying to be condescending here but it is worth remembering that gigahertz means BILLIONS of calculations per second.
We're only talking in theoreticals right now anyways, it is entirely possible that a game studio has tried this and it hasn't worked, I just don't put a lot of faith in modern game companies.
You cannot break the speed of light with computational effort.
You're saying that you want to have a round trip from client to server and back happen in-between frames.
You cannot do that. Period. You will not ever have latencies that low.
Even if you frame lock it at 60fps that means you're calculating views, sending the data up the tube, checking it on the server, responding back with all the data about the new character that should appear and then rendering the new guy within 17ms.
That is physically impossible.
That's why I already proposed tolerance for ~200ms with trajectory projections
So you're going to take all the places a character could be in the next 200ms, do Ray casting on all of them and send that data to the server to check every 17ms?
While the server also does that for 15 other players at the same time.
Do you know what algorithmic complexity is? Big O notation? If so - that's a n³ * 15m³ problem space that you're expanding out across 200ms every 17ms, where n is player locations possible in x/y/z and m is the other players locations. Physics collisions are usually the biggest drain on a computer's cycles in game and in the worst case that's n² complexity.
You're talking insanely taxing here.
You do something called raycasting to determine visibility beforehand, and don't render anything not visible.
lol raycasting isn’t optimized for server side deployment, it would increase the poly count of the mesh tenfold, which would in turn increase average ping and fps. Couple that with the client side rendering problem and I don’t know anything about development just kidding
Your suggesting the server maintain a real time render for every single player and somehow manage to get the data back to them in less than 17ms so that they don't have empty frames that suddenly become people?
Because that's a ludicrous requirement in terms of latency (ping is totally reasonable at any value under 100ms) and server capacity.
Because your solution sounds like it would cause popping constantly and be a major burden on the server, which is already the largest overhead on a released game.
Hell. I have enough trouble knowing where I am much less predicting where other people will appear.
I don't know game development but uh do you? What are you rendering when the player can't see them? I might legitimately just not get what you mean
You constantly have to render people in when they can't be seen but will soon be seen. Which also means instead of keeping track of just locations the server needs to render the scene in sufficient detail as to determine sightlines.
Usually games just do this by sending info to clients of where everyone is and letting the clients render people in when the client determines that the sightline isn't interrupted.
Some games will just not send the positions until they're within a certain range of each other, but I'm a realistic game like tark you'd need several kilometers of info in case someone scoped in.
If you don't do this correctly it leads to characters popping into existence from thin air
You could use things like ray tracing to determine if one player can be seen by another on the serverside and only send packages when they can see.
But to resource heavy to do that.
Edit: Thinking about it, you simply have to render the whole map with all players server side and based on that determine which players can see each other and based on that send the information to the clients.
You do see why that's a serious issue right? Before the Server did nothing more than maintain a list of x,y,z coordinates of player positions. Now it's rendering the entire game space and doing 3d calculations.
That's several orders of magnitude more complex and costly.
That's exactly what i said.
Still no reason to put a root kit on the customers PC.
There's no way in hell you'll ever get a game company to agree to that. You're talking 100x the expense of running a server at a minimum.
Cheating is such a hard problem.
Like, this is what leads to invasive client-side anti-cheat. Which also happens to be one of the main blockers for OS portability.
But if you make it so that the server has to constantly validate the game state, you get terrible lag.
You really have to design your game well to deter cheaters. And you have to empower server moderators to ban cheaters. This sorta implies releasing the servers so that communities can run their own instances, because these studios don't have the resources to handle moderation themselves.
the validation shouldn't cause too much lag since game needs to sync up the game states anyways, which is an operation that is inherently way more expensive than any validation anyways (since each frame of the following game states need to adhere to the game rules anyways, there's already inherently some form of validation). It's more about not trusting everything the client says the game state should be.
I mean, i'd argue that a car costs a bit more than $150, but i see your point.
Call an Uber
Cheaters are a big problem in this game. To experience the cool parts of the game without all the bulshit, there is still SPT-AKI for playing solo and also the SIT mod for PvE multiplayer coop.
I'd rather pay someone else to slam my dick in a car door for 150 clams.