Official Everybody Edits Forums

Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?

You are not logged in.

#1 2018-07-12 13:29:18

1448
Formerly alkazam1448
From: Numberland
Joined: 2015-04-12
Posts: 683
Website

A better anti-cheat algorithm

This post assumes knowledge of calculus and exponentials, so if you don't know those, ~~shoo~~ you won't understand what this is about.

What you could do is use this as your velocity function: (Derivation)
739S71q.png

Graph with v = 0, k = 3 and r = 1.5

Integrating that, you get this:
Cd2Kh2E.png

Graph with C = 0, v = 0, k = 3 and r = 1.5

You could substitute the initial position of the player when a keypress event occurred as the *C* value and set *r* and *k* based on the current game mechanics. *v* can also be calculated using the first function.
Latency issues can be solved easily by sending the time difference between keypress events along with the message. This can be substituted in the function to verify the position and can be stored for the next verification.

This would mean changing the physics for both the client and the server, so I think you could do this for the rEEboot (if you're not lying about it //forums.everybodyedits.com/img/smilies/wink).

P.S. Yes, I'm not dead. And yes, this is my first forum post in a long time.

Offline

Wooted by: (4)

#2 2018-07-12 14:13:38, last edited by LukeM (2018-07-12 14:21:02)

LukeM
Member
From: England
Joined: 2016-06-03
Posts: 3,009
Website

Re: A better anti-cheat algorithm

I was thinking about this sort of thing a while ago (before I was a dev), and the main problems would be detecting when the player collides / moves into a block, and keeping things like key doors / gates in sync. The block collision would end up as a complicated function that you would have to solve to find the exact time at which this happens, and I'm not sure how easy this would be with two dimensional parametric equations, possibly with turning points etc. Keeping things like key doors / gates in sync would be hard as there is a significant delay between a player sending a message saying they've hit the key and the message being recieved by the other players, (and you couldn't simply calculate it client side as the player could have pressed an arrow key meaning that they just narrowly missed touching it).

I'll definately look into it to try to work out if it is a viable solution, as if it is it would definately be a good way of doing things as it would make hacking impossible and might even be faster to calculate, but I doubt it would be possible to keep all the clients perfectly in sync...

Offline

Wooted by:

#3 2018-07-12 14:27:01

XxAtillaxX
Member
Joined: 2015-11-28
Posts: 4,202

Re: A better anti-cheat algorithm

It'd be way too complex for a smiley face game and isn't worth dedicating a large amount of time developing when there's far more important things to focus on.


LukeM wrote:

as it would make hacking impossible

No, it wouldn't.

In the context of campaigns, you could simply replay movements.
As long as people are given free input within any digital system, they are able to manipulate it to their advantage.
It'd be a deterrent perhaps, but that's far from creating an impossibility.


signature.png
*u stinky*

Offline

Wooted by:

#4 2018-07-12 14:46:45, last edited by LukeM (2018-07-12 14:49:48)

LukeM
Member
From: England
Joined: 2016-06-03
Posts: 3,009
Website

Re: A better anti-cheat algorithm

XxAtillaxX wrote:

It'd be way too complex for a smiley face game and isn't worth dedicating a large amount of time developing when there's far more important things to focus on.

I'd say that in a platformer the physics is the most important thing to spend time on //forums.everybodyedits.com/img/smilies/tongue (If we could do this it would have a lot more benefits than just preventing hacking, it would also prevent a huge number of inconsistancies and bugs etc.)

XxAtillaxX wrote:
LukeM wrote:

as it would make hacking impossible

No, it wouldn't.

In the context of campaigns, you could simply replay movements.
As long as people are given free input within any digital system, they are able to manipulate it to their advantage.
It'd be a deterrent perhaps, but that's far from creating an impossibility.

Ok, yes, it wouldn't stop you from beating campaigns automatically, or training an AI to have a 100% win rate on boss to codes, but you know what I mean... It would make it impossible to do the bad sort of hacking, teleporting around or spamming keys from a distance or whatever.

Offline

#5 2018-07-12 16:44:53

hummerz5
Member
From: wait I'm not a secret mod huh
Joined: 2015-08-10
Posts: 5,852

Re: A better anti-cheat algorithm

per request and sound logic, moving this to Game Suggestions

Offline

Wooted by:

#6 2018-07-12 19:07:56

XxAtillaxX
Member
Joined: 2015-11-28
Posts: 4,202

Re: A better anti-cheat algorithm

LukeM wrote:

I'd say that in a platformer the physics is the most important thing to spend time on //forums.everybodyedits.com/img/smilies/tongue

I didn't make any statement disparaging the value of developing the physics engine itself. I specifically criticized the worth of allocating a non-trivial amount of time developing a sophisticated means of attempting to prevent cheating in a smiley face game, especially when the project hasn't even begun.

You know as well as I do that any such implementation would involve synchronized and coordinated server-sided physics simulations. I think it'd be a large waste of CPU time to even consider having on as a feature by default. I don't think it'd be a very cost-effective approach to an issue that is relatively minor in proportion to the general community, the majority of which don't typically cheat in-game.

I think the cheating issue was mostly derived from, or at least significantly exaggerated by, the fundamental issues in the campaign system.
I think it's significance is far lesser in regular worlds, where worlds are self-moderated and aren't needing of the baby-sitting by moderators.

I think the main problem arises when you introduce inherently non-sandbox features in a sandbox game. In essence, when you provide substantial rewards for engaging in non-sandbox features, especially when devoid of decent alternatives, you are effectively producing the supply and demand for cheating the system.

It's unfortunate especially because a large fraction of the time spent moderating these non-sandbox features could arguably be spent on far more significant pursuits, such as improving the in-game performance, improving community engagement or enhancing the game with the development of new features rather than spending the limited development time tackling the arms-race you created.


signature.png
*u stinky*

Offline

#7 2018-07-12 19:38:32, last edited by LukeM (2018-07-12 19:38:49)

LukeM
Member
From: England
Joined: 2016-06-03
Posts: 3,009
Website

Re: A better anti-cheat algorithm

XxAtillaxX wrote:

I didn't make any statement disparaging the value of developing the physics engine itself. I specifically criticized the worth of allocating a non-trivial amount of time developing a sophisticated means of attempting to prevent cheating in a smiley face game, especially when the project hasn't even begun.

You know as well as I do that any such implementation would involve synchronized and coordinated server-sided physics simulations. I think it'd be a large waste of CPU time to even consider having on as a feature by default. I don't think it'd be a very cost-effective approach to an issue that is relatively minor in proportion to the general community, the majority of which don't typically cheat in-game.

I think the cheating issue was mostly derived from, or at least significantly exaggerated by, the fundamental issues in the campaign system.
I think it's significance is far lesser in regular worlds, where worlds are self-moderated and aren't needing of the baby-sitting by moderators.

I think the main problem arises when you introduce inherently non-sandbox features in a sandbox game. In essence, when you provide substantial rewards for engaging in non-sandbox features, especially when devoid of decent alternatives, you are effectively producing the supply and demand for cheating the system.

It's unfortunate especially because a large fraction of the time spent moderating these non-sandbox features could arguably be spent on far more significant pursuits, such as improving the in-game performance, improving community engagement or enhancing the game with the development of new features rather than spending the limited development time tackling the arms-race you created.

tl;dr: This isn't just about preventing hacking to me, its also a possible improvement for game performance and a solution to a lot of inconsistancies.

I think you (at least partly) misunderstand my stance on this, I think this would be a good idea even if hacking wasn't a problem, as it allows you to avoid many problems caused by other methods of calculating physics and collision detection, for example a lot of the inconsistancies and problems caused by moving all at once in 'ticks' (EE currently moves you in 16+ steps per block to avoid some of these problems, which makes it sound to me like it might be one of the things causing it to be slow). The fact that it prevents hacking is just a side bonus imo.

As for the synchronisation and simulation, its too early to tell how CPU intensive this would be (its possible that only one calculation would need to be done per movement message to validate it, which doesn't sound like it would be too bad to me), although yes synchronisation would probably be difficult with this.

And yes, only a few people cheat, but when they do it is very bad, and often difficult to tell who is doing it without the aid of external tools (e.g. global switch toggling or whatever), so I do still think it is worth at least considering.

Offline

#8 2018-07-13 03:40:16

1448
Formerly alkazam1448
From: Numberland
Joined: 2015-04-12
Posts: 683
Website

Re: A better anti-cheat algorithm

Avoiding concurrent physics simulation is the whole point of this algorithm. You just plug in the told and velocity and stuff and you get the current position. You could limit this checking to things that include movement/position. Collision could be a problem, true. You could determine a collision point right at the keypress and edit the function to return a constant if the time is greater than a specific value. The function's variables are changed with each movement message, so it would work well imo

Offline

14481531449616714050

Board footer

Powered by FluxBB

[ Started around 1711723632.5145 - Generated in 0.086 seconds, 12 queries executed - Memory usage: 1.52 MiB (Peak: 1.68 MiB) ]