Grifters, trolls, asshats always find their way into communities that are centrally moderated. That includes most online games and social media today. This problem isn't solved with anti cheat and government ID checks. In fact this problem was solved years ago, simply by letting each community create their own spaces with their own rules. This means some spaces are private. Others may be semi-open. And some will be fully open, and yes that will always be chaotic.

The only multi-player games I play are with friends or their friends, ie people I already trust. The only social media i use is group chats with friends. Of course, you can have more open and anonymous spaces like we have here on HN, but you need more moderation and the moderators need to feel some sense of pride/ownership to keep on working for free.

This I agree. Furthermore, you should be able to do such a community by a local network (LAN) instead of using the internet, if you wish. (Free software has this advantage, too; if it does not already do that, you could change it to work.) (Also, some tournaments might be set up in a room in a building; there, they can have dedicated computers.)

Private walled gardens would pretty much kill the competitive scene of most games.

I used to play competitive dota (the original wc3 map) back in the day and the inhouse leagues were a massive pain in the ass. Same with all the various leagues for counter strike (1.6 at the time). UX was terrible, the moderation sucked and you still had to have anti-cheat as people would cheat even in private spaces. Usually the easiest way to get up the ladder was do something dubious and be good friends with the mods so they would rule in your favor.

People use cheats even at LAN events too. So yeah for competitive multiplayer anti-cheat is pretty much required.

At top level I think most scenes are private walled gardens. With possibly some path to raise there outside franchise models.

For average players yes, central developer driven model is much easier and simpler.

Counter-argument is Smash Bros, which is basically only private games and has a competitive scene.

Smash Bros has so bad netcode that serious competitive online play does not really exist. This is why most big fighting game tournaments dropped smash during covid due to being forced to be ran online (and Nintendo is just a real pain to work with). Instead we get some previously "small" game being ran at big tournamets like Skullgirls at EVO because they have rock solid netcode so they can actually be played online at high level.

Also smash is played on consoles that prevent one from installing cheats basically the fact that the whole platform is fully locked down is the anti-cheat. Still controllers are sometimes checked at tournaments for any additions that can run macros (most adapters that allow one to use a different consoles controller can do this)

There was going to be an online Smash tournament using emulation + a mod to improve the netcode but Nintendo shut it down:

https://www.polygon.com/2020/11/19/21578200/super-smash-bros...

And it has barely limped along over the years in comparison to other developer supported FGC games.

This is more of an "exception that proves the rule" since Smash is pretty much the only competitive game with zero centralized support that has broken out of a tiny niche to compete with big names.

It's wild to me that game developers have determined it's easier to write malwate to prevent cheating than just make server side code robust enough to not validate code that could be a cheat...

There are some cheats like wallhacks, trigger bot, fake lag, backtrack, etc that aren't really possible to catch with just server side checks.

I am not sure what you mean there. Wallhacks is the ability to see through walls. The server could simply not give out the information about what behind a wall and the wallhack exploit would stop working. It would also very likely introduce pop-in and latency issue as soon the client peeks behind the wall and now need updated information from the server.

Fake lag is in a similar situation. The server could simply hold the true state of all positioning and ignore what the clients think is their position. This might work fine in a very low latency situation, but as latency increase it would make playing the game feel sluggish. It would also make aiming difficult, since the key press for fire would have to travel to the server in order for it to occur, and by then the location of players could have shifted.

Trigger bots however is mostly impossible to stop server side. Any action that is identical to human actions can only really be detected through statistics and heuristics.

>It would also very likely introduce pop-in and latency issue as soon the client peeks behind the wall and now need updated information from the server.

Which is why games that do that will still send you data about player who you are almost able to see. This will be their exact position and look direction along with what they are holding. Even limited wallhacks can give a competitive advantage.

I think you misunderstand fake lag. With fake lag you get fake packet loss / latency which causes your character to stutter making it harder to aim at you. The server isn't getting a regular stream of updates of your position.

If the movement, location and actions occurs at the server, the effect of fake lag would just harm the player doing it. It would not make the character stutter for everyone else, as from the server perspective the player would just be standing still.

Yes, the player will look like they are teleporting around, but they will still be able to kill you. No, it doesn't harm the player doing it because client side they are still moving around.

There is a misunderstanding here over how server side vs client side movement work. I will illustrate this with an example:

With Client side movement, Player A sends in even intervals their location to the server. Let say they move right for 3 unit of time, the location get updated from 0:0, 0:1, 0:2. The server then relay the information to Player B.

With Server side movement, Player A tells the server they want to move to the right. The server create a path over time, 0:0, 0:1, 0:2, ... and continuously sends this to player B.

Let now add a fake lag with client side movement. In the first case the we see Player A send locations like 0:0, 0:1, -, -, -, 0:5. The server sends this to player B. If Player B fired a gun at 0:2 at the third interval they might miss because player A is not there. The server might extrapolate an virtual path between 0:1 and 0:5, but that depend on game logic.

Lets now add a fake lag with server side movement. Player A tells the server that they want to move right. After 2 units they add a 3 unit lag, and finally sends tells the server a stop command. The server would construct the following path: 0:0 (start moving player A), 0:1, 0:2, 0:3, 0:4, 0:5 (halt moving Player A). If Player B fired a gun at 0:2 at the third interval, the server see that player A is at that location and will mark a hit.

This is why server side movement isn't vulnerable to fake lag. The server has the full game state and thus know at any point where all player are and what they are doing, and if the client lag then it simply mean that their input gets delayed. Server side movement is however vulnerable to real lag, as between any action there might be a delay and thus events might not occur at the server when players want it to occur. Server side movement is also slightly more vulnerable to ddos attacks if players can identify the IP address of other players.

Even with that implementation of server side movement it will still mess up by fake lag adding jitter.

Player A may send 0:0, 0:1, -, -, -, 0:2 0:3 0:4 0:5

The location for 0:2 that B would have been wrong via your approach. If player A's actual location at 0:2 isn't about the same B will miss his shot.

With server side movement, player A do not send coordinates. The server does the movement of players.

Imagine you are talking over the phone to someone who is driving, given them directions. That is server side movements. If you suddenly stop talking, the car doesn't just stop, nor does the traffic. All you have accomplished is that the driver is no longer getting any further instructions from you.

I wasn't talking about coordinates. Just commands attached to timestamps. If Player B shoots player B at t=5 and then Player A says they stopped moving at t=2, then Player B's shot will miss since they didn't know Player A had already stopped 3 seconds ago.

Depends on how it is implemented. If the server-side version is the truth, only the player doing it suffers. For example, player lags for a second. In that second, the server extrapolates their new position based on last velocity, heading, input, etc. Someone kills them at that extrapolated position. When the client resyncs they suddenly die.