4 ms·
It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happe
by redka 7y ago
It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of cheaters spoiling it for everyone is super slim. I wonder if it ever makes sense to think in those categories or am I just paranoid.
- marcus_holmes 7y agothat does kinda feel like premature optimisation. First make a game. Second make a game that people want to play. Third make a game that people want to hack. Then maybe look at stopping them from doing that. Hard to resist that nagging thought, though.
- judge2020 7y agoKnowing and designing around the unavoidable wave of cheaters is extremely important when building online games. If you build a multiplayer game then come back to "deal with cheaters" only a few months before launch (or heaven forbid, after launch) you're probably going to end up taking the easy route by using invasion ~~spyware~~ DRM solutions, which don't stop cheaters once it's broken. To contrast, designing the game around cheaters means you might actually implement sane networking design, such as nearly everything being server-authoritative, aka. "never trust the client". If your client is broken in to, the best your cheaters can do is script the game (scripting cheats are currently the only ones available for Dota2 and probably League of Legends) or see a small amount of information that's otherwise unknown (for dota 2 you can see which enemy illusions are fake, for example). Of course this approach can be taken too far, eg. in Call of Duty: Modern Warfare (the new one) sometimes your camera positioning can lag due to packet loss; this probably stops some aimbots but things like camera orientation probably shouldn't be handled server-side.
- bostonvaulter2 7y agoOn the other hand people don't like playing a multiplayer game when other people are badly hacking.
- ghusbands 7y agoAnd, as with premature optimisation, mantras don't communicate any of the subtleties around the fact that many concerns can influence your code at the same time.
- saurik 7y agoWhy do you say "for the browser"? Unless you are working on a system with a ludicrous amount of effective DRM (which I hope we all hate for other reasons, and which means we are only really talking about consoles: the closest casual gaming platform you are going to get to "locked down system owned by the manufacturer" is an iPhone, and in practice they don't go quite far enough), players are always going to be able to modify your code: you can't prevent a user "cheating" (which I put in quotes, as I feel like you need to really question whether the environment you set up where that matters isn't somehow itself broken; maybe you are already doing that by "source-like networking", but I don't know the terminology context).
- p1necone 7y agoThe only way to stop players from cheating in a multiplayer game is to make the server the authoritative source for any information you want to stop players from messing with. If it's a single player game, then who cares?
- redka 7y agoThe games are multiplayer and the server is authoritative. That doesn't mean the games can't be played with cheats, eg. wall-hack, auto-aim, etc.
- p1necone 7y agoYeah, you need to have another (more invasive/fragile) solution for things that involve scripting input like auto-aim. Wallhacks can be prevented by not sending location data for units that players shouldn't be able to see though.