Preventing cheating in network games written in Java

[zammbi]

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...

Thats what I was talking about.

Btw, if you had to name three (or more) of your other biggest problem, what would they be? It's interesting.

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.

[Mr_Light]

Not so easy to hurt my feelings.


Anyway, ontopic: I read an article on Gamasutra.com about anti-cracking - I know that's totally different than cheating, but the strategy they used was amazing.

Most hackers/cheaters will hack stuff, and if it works, they'll release it. Nothing easier than programming a game to crash on a failed SHA1 hash of some resource - or even the binaries. Well. That's where you get to nerf your game instead. In the article, they had this arcade game that required collecting gems in a 3D world. You'd spend hours exploring, and to finish the level, you needed 'super gems' hidden around the level.

When certain hashes failed, one or two 'super gems' disappeared from the game.

The hackers had no way to figure this out in a timely manner. They thought they got the game running, and released the crack on internet. Needless to say quite some 'casual leechers' got fed up with the impossible gameplay, visited some forums, and found out what was happening. Seriously: they bought the game instead.


So what can we learn? It is actually quite easy to figure out whether a wallhack is active. I mean, you have access to the framebuffer. You can use OpenGL Occlusion Queries if you're really lazy. And if you determine somebody is cheating, don't crash the game, don't show them a warning. No! Instead nerf their game. Make them randomly die, once every 10 minutes. Occasionally do not render an enemy. Give them half the healthpoints of a healthpack, slightly darken their screen, reduce the framerate at totally random moments, preferably when it hurts them most.

The possibilities are endless. Besides that, it is fun to code.

Just be very subtile, so they won't track it down to they own cheating.

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.

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

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.

(most poker sites don't bother, FWIW, as they have other heuristics anyways that are very good at catching bots, though for obvious reasons they aren't very forthcoming with the specifics).

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

[blahblahblahh]

I wonder what you thought of encrypting variables, as this raises the bar quite a bit against the 'find this value in RAM and modify it' attack - the fact that AoE AoK 2 used it, which can't be ignored, might change your mind, and accept this little bit of information from a clueless

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)

Games published by our own members! Check 'em out!

[blahblahblahh]

Anyway, ontopic: I read an article on Gamasutra.com about anti-cracking - I know that's totally different than cheating, but the strategy they used was amazing.

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.

[blahblahblahh]

I've thought about that, but it doesn't work for things that should be barely visible (like if someone is 50% transparent).

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.

Also it will only work for servers that constantly pushes the location of stuff to everybody, not if the server want to save bandwidth by only telling the clients stuff like "spawn a bullet at X/Y with this direction and this speed".

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?

[Riven]

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.

Yeah yeah. Boo boo.

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

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.

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!

[princec]

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

[M2009]

First off, thanks all for the replies. This thread is heading for greatness. 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).

[...] And the thing poker bots need more than anything else is information about the game, so I could see why you would not want to have an array of integers tracking card types sitting around in memory for any bot to easily take a peek at. [...] Add in a few tricks like slightly altering the rotations/sizes/graphics of the cards, etc., [...] you will get a few people figuring out what the score submission URL is. If you "encrypt" the scores before you send them through and validate them with some sort of checksum and then ban IPs that send invalid checksums that will take care of almost all cheating there [...] Add a sanity check (it should take at least T seconds to get P points, where P is a decent amount above what you'd expect the best player to possibly get) and you'll stop almost all of it. Storing game replays and saving them to the server can take care of pretty much all of the rest if you've got the energy to implement it, and it also lets you play things back to the user [...] in an MMO things go slow enough that you can afford to have literally everything except graphics done on the server [...] There's not going to be any easy way to prevent someone from messing with the graphical output [...] I don't think there's any way to do this from within Java, you really have to make it platform specific.

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).

[...] I read an article on Gamasutra.com about anti-cracking - I know that's totally different than cheating, but the strategy they used was amazing. [...] Nothing easier than programming a game to crash on a failed SHA1 hash of some resource - or even the binaries. Well. That's where you get to nerf your game instead. [...] They thought they got the game running, and released the crack on internet. Needless to say quite some 'casual leechers' got fed up with the impossible gameplay, visited some forums, and found out what was happening. Seriously: they bought the game instead. So what can we learn? It is actually quite easy to figure out whether a wallhack is active. I mean, you have access to the framebuffer. You can use OpenGL Occlusion Queries if you're really lazy. And if you determine somebody is cheating, don't crash the game, don't show them a warning. No! Instead nerf their game. Make them randomly die, once every 10 minutes. Occasionally do not render an enemy. Give them half the healthpoints of a healthpack, slightly darken their screen, reduce the framerate at totally random moments, preferably when it hurts them most. The possibilities are endless. Besides that, it is fun to code. Just be very subtile, so they won't track it down to they own cheating.

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.

[...] Of course if you're writing an online pc game rather than a single player console game you've got the advantage of being able to patch easily and often. [...] it's much, much easier to write a simple counter to a well-known cheat than it is to try and build in all sorts of elaborate tricks that cover every eventuality. And because you're countering a specific hack you can get creative - like draing false players behind walls to confuse players using wall hacks.

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

[...] 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.

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

[...] 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. [...] the latency problem goes away by time

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.

(Concerning encrypting variables.) [...] 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)

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

"M2009: I've thought about that, but it doesn't work for things that should be barely visible (like if someone is 50% transparent)."

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.

"M2009: Also it will only work for servers that constantly pushes the location of stuff to everybody, not if the server want to save bandwidth by only telling the clients stuff like 'spawn a bullet at X/Y with this direction and this speed'."

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?

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).

[Riven]

At you first statement: You guys seem to be very tight on this forum, aggressivly defending one another. How nice.

Offtopic:

I have this vague idea you're refering to me and blahblahblah.

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?

[princec]

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?).

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

Games published by our own members! Check 'em out!

[Mr_Light]

At you first statement: You guys seem to be very tight on this forum, aggressivly defending one another. How nice.

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.

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).

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.

[M2009]

So... what is the product/game you're making anyway?

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. http://www.java-gaming.org/topics/why-doesn-t-the-proguard-output-work/20582/view.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.

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

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.

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.

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.

--

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.

[princec]

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.

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

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

[M2009]

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

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

(Screw what I said about staying on-topic in this thread!) 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.

[princec]

MM myspace update:
"Soldat: I'm rewriting the network code. This time using enet with the Q3 net model in mind from scratch. Raknet had too much useless features. 3 minutes ago"
Yay!

Cas

[M2009]

Oh sweet, had missed that. Didn't know he had myspace, only ever read his blog at http://mm.soldat.pl (and not so often).

Definitely about time he rewrote the net code for Soldat, though I could have sworn he said he wouldn't work on Soldat any more. Are you sure he isn't just rewriting the net code for his Link-Dead game? Found this: http://mm.soldat.pl/?p=368 It doesn't say exactly which game he is rewriting the network code for.

[Nate]

Soldat is cool. I made a map for it a long time ago:
http://n4te.com/dev/games/soldat/Crusade.zip

Streaming gaming is amazing! Good luck to them getting the sound to work.

[ManaSink]

Things that uh... my doppelganger has done in the past....
1)  hexedit save game files
2)  decompile source code
3)  Sniff / spoof network traffic
4)  Run code on a hacked VM

Things that slowed "him" down
A)  No save games to poke at, everything on the server
B)  network protocol had a rolling checksum, preventing external packet injection
C)  network protocol was stingy exposing state
D)  Kill-cam or game replay exposed dirty tricks
E)  Penalty for getting caught was my account banned
F)  Obfuscated client-side code
G)  Important stuff (to hit %, damage inflicted) is arbitrated at the server or another client
H)  Code was completely inaccessible (PS3, DS)
I)  A legitimate mod framework existed
J)  Hacked /file/game/protocol didn't yield any advantage


Some people will cheat at *anything* if they think there is an upside, and they can get away with it.  For the record, I think this includes DiabloII, monopoly, hide and seek, jury duty, and dating more than one individual at a time.