Amen. And I'm a client developer. Clients aren't for data validation, etc. That's the server's job because the server has to store it, use it, ship it off to other things.
Clients are for displaying all that data in a way a human can understand. It has people skills, damn it!
Things like Punk Buster, et. al. are more like anti-virus software: they try to find the signatures of known chat clients.
So it's best to write you own...and rename your debugging process to "Google Chrome." He got pretty far with his auto-walker in some MMOs. He had limiters so his runs wouldn't be too fast and would go up/downhill correctly...or so he though. He forgot to multiple by -1 somewhere and the server banned him for attempting to fly of into space.
Wonder how soon there will be a market of PCI-e cheat rigs for DMA attacks...
____
[1] Yep, gamers are literally accepting rootkits that allow arbitrary remote code execution on their machines.
That's certainly risky and rather horrible, but what's the alternative? Multiplayer games are a huge business and a huge culture, and all that goes down the drain if people cheat.
Game companies have millions of people around the world competing for prestige and money. They're running game software on their own personal computers--machines that are also full of their financial records, naked pictures and personal correspondence. If your game is full of cheaters, you're done. If your game gets players hacked, you're really done.
I have no idea what the solution is, and I'm really glad it's not my job to figure it out.
If you get a competitive advantage from doing something like grinding, which computers can do better and more tirelessly than humans, and humans tend to dislike, then inevitably you will have cheating. (e.g. WoW)
If on the other hand the competitive advantage is from working out a strategy of in what order to play your cards to maximise your chances of building up your strength while attacking the opponent and yet keeping something in store for surprises the opponent may spring on you - a really complex strategic task - then that's something people enjoy doing and the computer sucks at. (Hearthstone)
People may be addicted to the first kind of games, but is that something that should be protected? It's kind of similar to people addicted to slot machines... sad, a reality we have to accept, but not something we should expend vast amounts of intelligence trying to sustain.
Of course, there are people who will do it for the money, and don't stop them, but realise that they are basically just a few steps short of people refining formulae for meth to make it more addictive - the fact there's a business case that exploits a human weakness doesn't mean it's a productive use of intelligent people's time.
One of the examples you gave, Hearthstone, actually had many bots running on the ladder for a time. Their goal was grinding, but even so, a number of them was better than a significant portion of the human playerbase. With the recent advances in artificial intelligence, computers are not that bad at this kind of task.
Overall, I don't disagree with your main point though. I have no qualms automating boring and repetitive tasks in non-competitive games. And if a competitive game has those parts, I'd probably avoid playing it. I'd rather spend my time coding than wasting it grinding because it's part of some game I otherwise enjoy. I feel it is indeed a more productive use of my time. I wouldn't go as far as judging other people who like the grind though.
E.g. turn the opponent's textures bright purple so you can see them better. Make the walls transparent. Aimbots that spoof mouse input.
The server must be authoritative or all bets are off, but you still do need client side anti-cheat countermeasures (stuff like verifying screenshots).
This stuff can't be made 100% fool proof, so competitive games where big bucks are at stake must still take place with the organizers providing the hardware and the players located in the same room.
Ultimately no matter what you do, some small percentage of your players will cheat. Every major game on the market has paid cheats which fully bypass the protections available for it. It's better if those cheats can only buy them a little than buy them a lot. It's not worth investing a lot of effort in more than basic cheat protection, it is worth investing it in handling as much as you can server side and exposing as much as you can client side as that is something cheaters can't game.
This sort of behavior becomes impossible. If they have to aim in a fairly human manner, they can still be killed by anyone walking up behind them for example. It may provide some bit of unfair advantage. But not nearly as much as is possible in many games today.
Honestly, I immediately smell naivete BS when someone says "the solution is simple"...
If a company wants to attract competitive gamers, then they have to develop games you can't cheat in during competitions. Right now, the most reliable way of doing so is server side, with all the challenges that entails. Otherwise, they have to install what essentially amounts to rootkits - which isn't exactly what most gamers want to encourage.
(Alternatively, run game in VM? I guess performance would suffer too much with that approach?)
I lost interest in game RE a long time ago, but http://www.unknowncheats.me/ seems to be its successor, though from a cursory glance I see there are a lot more cheats and less technical information.
GD we miss you.
Made gaming IRC channels utter chaos for weeks.
I used that to bot on WOW back in the day, this tool was fabulous and can be adapted to probably any game. Knowledge of C++ is required to create an extension, after that you can code your bot in C# or Lavishcript (their own script language, quite powerful).
It's true that you can't trust clients not to lie. However, in some situations, it's the correct decision to accept a constrained number of lies if that brings you benefits.
Like so many other absolute statements in software, in reality it's a trade off, and you need to consider the business context to make the right decision.
Right now I'm working on an app where we trust the client. We know that a hacker can compromise a client and send any kind of bogus data, we're just completely OK with it from business perspective.
I mean why not just do it the right way?
What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.
They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back"
If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done.
The idea of trust only comes into play if there is a consequence to that trust being broken.
When somebody says "Never trust the client" inevitably somebody will find a use case that sounds like trust even though it's not what they're saying here and use that as justification.
The lack of nuance is how things like "never use stored procedures" gain traction when they shouldn't.
No, just google "wallhack".
the server sends to the client: account A has $100, account B has $200, make your transaction.
1. trusted client
client says: i've done my transaction, now account A has $50 and account B has $250.
the server updates the database accordingly.
client says: i want to do a transaction from account A to account B with 50$.
the server decreases account A by 50$ and increases account B by $50 and updates the database accordingly.
client says: i've done my transaction, now account A has $52 and account B has $252.
the server updates the database accordingly.
they try to do server checks to prevent this, but due to network timing problems they can't check the exact values, only calculate if this is maybe approximately right.
so a players maximum running speed is, say, 6m/s. they could do periodical checks (every second) if the player moved more than 6m since the last second. but what if the player falls down a building or is thrown by an explosion further than that? it'd register as cheating, even though it's completely legal to jump off a building. so they have to increase the checks for distance/s by 3 to allow those situation (i.e. 18m/s). a cheater with a modified client can now continually run three times as fast as any other player without getting flagged as a cheater.
why do they do this? because it's
a) easier to implement (the client has to do all the computations anyway - doing them a second time on the server and then sending back to the client isn't an easy problem - you have to interpolate) and
b) cheaper (less work = less man hours, less complicated work = cheaper programmers* and less server power needed)
* i'm completely sure the devs would have been 100% able to do it right, but it would have taken them longer, thus costing more.
so, how to fix it? there's only one way: rewrite the model. but this is expensive and the titles have already been sold, so why bother investing another couple hundred thousand bucks? even the disgruntled gamers will buy the next ubi soft title if it's shiny enough. i mean, few people will buy the game now that multiplayer is infected with cheaters but they already exploited enough of the market and long time players are probably less likely to buy the next title if they're still playing an old one. maybe.
Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you.
The server should always be the source of truth. It should always enforce all the consistency rules. Database schemas can be a critical tool here as well.
Don't blindly slap whatever the client sends into a no-SQL database, then vomit it back out for queries.