Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unless DOTA2 is running at a ~3 tick rate (Which it's not), even taking account processing delays and action batching, a bot will always have faster reaction times than an actual player. It will also never misclick.

This problem is magnified in a shooter game, which would be unplayable with that kind of batching, but where a cheater with an aimbot is actually impossible for a legitimate player to beat.





After you click, the character will begin to turn, which can take several hundred ms. A delta of couple ms compared to the time it takes to turn is completely negligible and even an inch better positioning of a character, or having a character with items or stats that makes them turn faster (because picks are asymmetric) will make several magnitudes more of an impact.

If your game allows your sights to just teleport on people's heads and take that as the winning condition then that just sounds like bad design, there's no reason to allow infinitely fast movement and omitting strategy even from a shooter


> If your game allows your sights to just teleport on people's heads and take that as the winning condition then that just sounds like bad design, there's no reason to allow infinitely fast movement and omitting strategy even from a shooter

This is interesting, because I feel like the fundamental gameplay of an fps is players exposing themselves to each other's field of view, and then trying to click the other's head first. Skill is a measure of map knowledge (so you can try to expose yourself to a possible field of view but not where the enemy is actually looking at that moment) and speed of clicking head.

How would you design FPSs to remove this "bad game design?"


> How would you design FPSs to remove this "bad game design?"

I think we just need to accept that bots will always be better at reaction based KPIs & abusing "knowing" too much game state, we should just remove those conditions.

1) Move most of the application logic to the server, the client should be a fairly dumb terminal that knows how to render and accept inputs, and only receives the state that it needs. No more spying issues.

2) Just give everybody auto aim & immediate/auto controlled firing, etc. No more aim bot issues.

3) Improve the quality of gameplay around the types of interactions which bots are bad at. Decision making, strategy, communication, execution, adaptation.


> No more spying issues.

This isn't possible. And this explains why: https://www.youtube.com/watch?v=WFw4F2AyaP4

We can only minimize the amount of extra information given to the client, not eliminate it. And at high enough skill levels, even 1-2ms of extra information will always be actionable, even by humans (not just bots).


Sure, feel free to make an entirely different type of game that's not as vulnerable to cheating.

But some people just want to play competitive fps shooters. And currently obnoxious anticheat toolkits are the way to provide that, unfortunately.


>If your game allows your sights to just teleport on people's heads and take that as the winning condition then that just sounds like bad design, there's no reason to allow infinitely fast movement and omitting strategy even from a shooter

From the servers perspective you always kinda do that for fast movements as the client send rate usually isn't more than 60hz.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: