Preventing cheating in network games written in Java

That’s why the idea is from countering cracking, and in this case applied to cheaters.

You only get nerfed if your cheat, that’s not an honest player! You probably don’t even want him to buy your game.

I wouldn’t be so dismissive of my suggestions, either. I’m being deadly serious. Consider gameplay that is not cheatable by design, and technology that is likewise not cheatable. Failing that, truly attempt to grasp what I’ve said about heuristics and voting systems. It is a serious solution.

Cas :slight_smile:

Sorry - I wasn’t clear. I was just refering to cracking. If this can be pulled of against cheaters it might be a good idea, but I am afraid this could really be difficult and cumbersome to implement.

I’d say apply the rule of diminishing returns: if there’s some easy protection you can put in that costs you little time and effort, while demotivating some script-kiddies, then do it.

But don’t sacrifice your game/marriage/life coding away just to stop the 1% of cheaters.

That (like others have said here) are what patches and updates are for, if your game takes off.

Well, I never expected this to be even possible, but looks like there are people out there working on the video streaming approach to games: http://www.techcrunch.com/2009/06/16/videos-otoy-in-action-you-have-to-see-this/

They claim it works quite well, I imagine the server load is incredible, though…

streaming video work with anything including game as the first video… but they seems to forget the most important… that will maybe never be removed wich is network latency and then game will be unplayable (especially when you look around)

Thats what I was talking about.

[quote] Btw, if you had to name three (or more) of your other biggest problem, what would they be? It’s interesting.
[/quote]
Biggest problems in hacking?
Well since we still a beta we do still have a few bugs people abuse. But we fix them once we know about it. Not really much other then the macroing as I said.
We did have some problems outside the game, like abusing our payment system. But that’s also fixed now.
We make sure everything is server side. But of course this doesn’t work for all games.

Isn’t part of that what ms does with xbox live, they don’t ban you immediately, they simply keep gathering info and ban in bulk. This keeps ppl on thier toes and makes it hard(er) to figure out which method was detected.

But it only makes it harder for cheat-creators to debug their stuff and keep ppl guessing if they got caught or not.

Damn straight, Cas.

You never noticed how ‘aiming’ is removed from most MMORPG’s, or rather focus on strategy and tactics not on realtime/dexterity/skills

‘Cheating’ will always be possible with FPS. And the industry knows this too, if there is any price involved you always need to show up in person. As long as you make your (aim)bot external enough and humanlike enough you can’t tell the difference.

You don’t prevent cheating, stop saying you can, you make it iether:

  • harder to do so.
  • part of your game.
  • diminish it’s effect/rewards.

Whether you should make it harder to cheat I don’t know, for ‘low’ stakes games it might be useful but is it worth the effort? For ‘high’ stakes games it might be usefull too, but you have to make use of the stakes, and target the ones that impact other players the most. Like public, widely distributed cheats.

There’s plenty of information available and they aren’t probably as secretive about it as ppl might claim; There’s a difference between actually trying to cover something up and simply not pointing it out.

They also don’t really care about (some) false positives. which makes the game a lot easier.

ps. the latency problem goes away by time

That’s sarcastic, right?

I’m not defending the rude OP’s response, but … this approach was known/shown to be “very stupid, only relevant for lazy, stupid, or foolish people” as of approximately 10 years ago. (hint: Diablo1)

If you wish to make money or fame out of game development, then … Dont Do This.

It’s been shown time and again that this leads to large numbers of reviews stating your game “sucks”; indeed, it’s led to some interesting lines of speculation about “how often - on average - are reviewers running pirate copies?”.

Report cheating, react to it, but don’t auto-cripple the game. Generally speaking there’s a fine line, but it’s acceptable to e.g. tell the cheater on their screen that they succeeded, while not reporting that info to anyone else.

WRONG!

(I’ll leave it to you to work out how to achieve this. Hint: it’s quite easy, and requries re-reading Cas’s post and thinking about what he’s saying.

Now, you’re right there - but then, this shouldn’t even be an issue. Are you sure this is an issue, or did you just imagine it might be an issue, and you’ve started worrying pre-emptively?

Yeah yeah. Boo boo.

As I already said twice now, this is rather poor against pirating yet a nice way to grief your cheaters.

Let me explain it even simpler: you don’t nerf your ‘pirating reviewers’ because they don’t tend to … cheat!

How hard can it be to grasp!

I don’t much care if pirates review my games. Especially if they say good things about them, and doubly especially if they link back to my site. Worth a free copy any time! Which is why I always give out free copies to reviewers.

Cas :slight_smile:

First off, thanks all for the replies. This thread is heading for greatness. :slight_smile: And thanks to those helping out trying to get people to stay on topic - how to prevent cheating in network Java games (and nothing else).

Good stuff, especially the replay saving. That would serve as a sure way to remove all cheating in some games (except, like you said, if someone bothered to write a bot that plays as a human).

Haha, that was a great thought. Instead of being betters cheaters would get worse, and even if the “cheat makers” later found out how to fix the anti-cheat there would already be flawed cheat-tools in circulation. However, as some people has pointed out in the thread, this strategy comes with a risk of the game getting a bad reputation of being broken if there are many cheaters that open their mouths on forums etc, and if you counter that by saying that only cheaters will get a broken game you alert the cheat-makers of what to look out for. Still a fun way of implementing anti-cheating though.

Good idea, drawing things that non-cheaters will not see is one way of preventing people from using the cheat.

I see, best of luck with your MMO. I’m assuming it’s this one: http://www.pokemonworldonline.net/

Making it harder to make cheats is always a good thing. And it’s always nice to keep in mind that ye, latency problem will get smaller with time - if something has pretty good latency now it will probably have great latency in the future. But one should remember that not all network parts in the world will get faster at the same pace (hehe), and the faster ones may always rely on the slower ones.

In what way? Who are you quoting that says it is for foolish people? Elaborate please. :slight_smile:

[quote=“blahblahblahh,post:35,topic:33704”]
At you first statement: You guys seem to be very tight on this forum, aggressivly defending one another. How nice. I’m still not sure in what way I was wrong though, but I might indeed have failed to interpret what princec said, maybe he (or you) can repeat what he said in a simpler wording (with focus of countering your quotation of me)? Saying exactly how to achive it would also save other people time (for example a guest that reads this thread a year from now scanning for advice - maybe he can’t understand how to do it either and just need quick advice?).

At your second statement: I’m pretty sure this is an issue, say you have a 2D world and someone fires a bullet just outside of your view, to the right. This bullet passes inside view in the top right corner of your screen and then disappears at the top. Then the bullet hits a box outside of view which falls down, gets in view and then crushes your player. Should the server just say “make this bullet” and let the client simulate the physics, or should it say “create a bullet” when it gets into view, then “remove the bullet” when it gets outside of view, and then “create a box” when the box comes falling into view? Or should the server tell the client to simply draw a bullet/box for each frame that it is visible (no physics calculation needed at all from the client).

Offtopic:

I have this vague idea you’re refering to me and blahblahblah. :wink:

You might easily get the wrong impression here. It’s not typical to this forum to be like this. I know I can be blunt at times, but the way blahblahblahh was responding to me and others was so arrogant and demeaning, that I couldn’t resist myself, and counter it.

Anyway, I’ll try to stay ontopic.

Any trick that raises the bar, is good, as long as you can afford the additional time you consequencely have to put in. Encrypting variables surely is one of them, as you can do a drop-in replacement in minutes - it simply raises the bar.
If you already have a product/game, and you already have users/players, it’s all about seeking the balance between adding positive things and reducing negative things. You should always do whatever yields the greatest effect for your users, even if that means focusing on new content, and accept the occasional cheater, which you manually IP-ban once or twice and move on.

So… what is the product/game you’re making anyway?

[quote=“M2009,post:38,topic:33704”]
I’m not sure I can explain it any more clearly, and the achievement is of course the devil of the detail. But here goes:

A technical solution to cheating is to have a secure third party which is the sole arbiter of the rules of the game. Right away this does away with 99% of the useful cheats you might have thought about. The typical situation is that the servers are hosted by yourself, and no-one else. The clients don’t even have to obey what the server says - the server contains the state of the game, and the clients only have powers to influence that state via the interface the server provides. You can’t speedhack, for example, because the server says how far you can move.

Secondly, to design a game where, given all the information that the client can possibly obtain, it does not matter how the client uses that information. Specifically, games that involve “aiming” and “reflexes” are prone to clientside hacking to do the aiming for you. To counter this you could have autoaiming on the server anyway, negating any advantage (which is what all the MMOGs do). And failing that, you resort to heuristics.

Heuristics is the science of making an educated guess based on the available information. What you need to do is collect information about the players’ performance on your server, and then set a threshold beyond which it is probably the case that a player is cheating. A player that gets 100% accurate hits with the railgun every time when the rest of the players only manage 50% is probably cheating. And if not cheating then probably making the other players have a crap time. But automatically kicking players is unwise and unfair. Flag them as possibly cheating, and get all the players to vote. Check Soldat out for an example of this. Soldat uses all kinds of mixes of clientside prediction and arbitration and is famous for clientside hackery, so heuristics and voting play an important part in its gameplay. It even makes the game more fun.

Cas :slight_smile:

[quote=“M2009,post:38,topic:33704”]
heh, it’s not that bad. blah^3 is just a bit grumpy from being raised back from the ‘death’ and all. That and he’s an opinionated person, which is a good thing.

[quote=“M2009,post:38,topic:33704”]
be careful to separate the physics(game logic) from the rendering(also involves physics) but only has to be good enough. you only send as little information to render it ‘right’ which could well be jit before it comes into view. and handle/send if the player gets hit or not separately on the server, its a method to save bandwidh not cpu cycles. There are some papers avail on this, with respect to relevance here: it’s in the best interest of the client to render/calculate it right. You(the client) can render it any way you want but the server veto’s if you get hit. Beyond that it’s useful for the player to get the right information(for dodging if projectile is slow, for localising the enemy if the projectile is fast(sound, visual feedback of impact). So messing with it becomes a handy-cap not an advantage. I suppose you could draw tracers to help but thats about it.

the problems are probably more in the direction of the server having to determine if a player can see stuff and the cpu it takes.

[quote=“Riven,post:39,topic:33704”]
Actually I’m just learning right now, trying to make simple “move and shoot” games in 2D so I get the hang of rendering game graphics and syncing across network. Learning ways of how to prevent cheaters is also a good thing to learn I thought, so I made this thread. Also trying to learn how I can use ProGuard, have a thread up about it but it’s not really moving forward. Here’s a link to that thread in case any of you who reads here are an expert. :wink: http://www.java-gaming.org/index.php/topic,20582.0.html I have completed a small test game using TCP to communicate over the net, right now I’m trying to get the hang of how to make a game that communicates with UDP and that is turning out to be a challange. Might start a new thread about it soon.

[quote=“princec,post:40,topic:33704”]
Ah now, I get what you mean, thanks for clearing that up. That was a good addition to this thread. Speaking of Soldat, that is my favorite game believe it or not. I have high hopes of making my own game similar to that one. The anti-cheating in Soldat is however not good at all, and the network protocol is even worse. And most people are unable to discover cheats like reducing reload time by 50% so they won’t vote yes on a kick, to notice that in the heat of battle you need to have played the game for months if not years. And you’d be surprised to learn how many that are just too dumb to vote people out, many times I’ve seen people NOT getting voted out even though they teleport to each player as soon as they spawn and knife them to death instantly. In later versions Soldat has made use of BattlEye, which finally made it so hard to cheat that not that many people does it anylonger, but in the olden days there was probably at least one cheater on any server at any given time. Well, almost. They still haven’t fixed their network protocol however, a lot of times you hit someone without it doing any good, sometimes (more often than rarely actually) you can even make them bounce away from the impact but it still does no damage - thats the biggest problem with the game today I’d wager.

[quote=“Mr_Light,post:41,topic:33704”]
Maybe I wrote it badly, or misunderstand what you wrote now, but in what order things are drawn wasn’t part of the post I made (the one you quoted). But your post made my think about exactly how things should be drawn for the user, if I just have a separate thread that draws the game (like all teachers have told me to have so far) one object might be painted one frame ahead while the previous was painted one frame behind the current object. Hm, I guess making sure not to paint the game while the game logic is being updated would be a good idea, even though it probably isn’t noticeable in most cases. On thread can draw the frame while the other manages the networking part of the game loop. Off-topic but a important thought. :slight_smile:

Well then, I guess this thread is going towards its end (for now). Thanks for all the tips people! If you stumble over some more good anti-cheat methods (that works in Java) remember to post them here in the future.

Soldat’s my favourite game too - if you’ve ever been pwned by Spas-Tard!, that’s me :slight_smile:

Soldat’s main network code failing is that in a concession to dealing with some aspects of lag, it appears to allow the client code to arbitrate what’s happened, specifically, the way players move, not so much the bullets, I think. So things can explode on the client and send a player flying, but the server doesn’t register the explosion at that location and so the player takes no damage, yet the client tells it that one of the players has accelerated massively. It’s this that’s behind the speedhacks, I think - the server allows clients to make decisions about movement. Mostly in the name of smooth gameplay - there’s almost no warping in Soldat, ever, which is nice. But the server does do hit arbitration, hence the famous “Soldat heart attack”, where you suddenly and unexpectedly croak when a bullet not visible on your screen for whatever reason kills you.

Cas :slight_smile:

(Screw what I said about staying on-topic in this thread!) :smiley: Ah, how nice meeting someone else that fancy Soldat as their favorite game, that’s the first time that ever happened to me.

I just wish the guy that does Soldat now (since MM stopped working on it) would focus a little bit more on the network part of the game instead of stuff like a in-lobby IRC client-tab that nobody uses and exploading heads from 50% of all sniper headshots. There’s lots to do, first of all there’s the eat bug (aka “hit”) where due to package loss your bullet never reaches the server so to speak (I have read Soldat uses UDP, he probably does nothing about lost packets). But the weirdest thing is still when you hit someone with a M79 grenade and they fly away by it (meaning it hit on their screen), but the guy doesn’t die. So the server recieved the projectile and passes it to the other guy’s client, where it hits, but it doesn’t hit on the server. Then the guy reports to the server that he has recieved force and is being pushed in a direction, and the server accepts it even though he apparently is out-of-sync. Adding to that (which has been in Soldat forever) I think the network code somehow got worse in Soldat 1.5, so I stick with 1.4.2 still. I wonder if Soldat is beyond help concerning the network code. I really think they should have added something new and fresh in the latest version of Soldat, one new gun or even a new hat to wear would have been completely awesome. Instead we get exploading heads as the biggest new feature, something that I think happens way too often for it to be remotely cool (they should have made it so that it only occurred if the player was “overkilled” with a headshot, given at least negative 75 hp). Over one year between versions and we get exploading heads. =P I know there was that voice taunt thing too but I don’t care about it, the voices wasn’t that good and I always play with the game sound off and my music on.

But even with negative stuff taken into account Soldat’s still a fun game. :slight_smile: