Today the biggest problem in any FPS game, or rather any genre is probably multiplayer cheating hacks. Imagine how easy it would be to make a hack for a java fps compared to a native, exe fps, because the class files basically hold the sourcecode when the hacker has a decompiler (many freely available already). Even when obfuscated, we just know there will be decompilers able to decompile obfuscated classes soon. I am just wondering what some of you plan on doing or is Sun planning anything? I know there’s many topics on this all over the place, but there needs to be a sure method that will work if we want java desktop gaming to come through. Hacks for games ruin the success of the game completely, when certain players have an unfair advantage over other players, its no fun for the other players so they will either download the hack for themselves or quit playing. Thanks for reading my oh-so-long-unorganized paragraph!! 
It’s really got nothing to do with Java. It’s pure and simple client/server design. A server should consider a client to be insecure, no matter what it may claim, and its protocol should reflect this. This means that certain kinds of games are inherently insecure by their very nature. It might be fractionally easier to tweak a Java game but even free minnows like Soldat have been hacked to death.
Consider the classic example of the FPS Aimbot. There is very, very little you can do to detect an aimbot. I regularly get kicked and banned from Soldat servers (if you see Super Elvis on selfkill, beware :P) for “cheating” but that’s because the server incorrectly determines that I’m using an aimbot (I suspect). And this is a shareware game written in C.
The basic premises of the c/s protocol are something along the lines of:
-
send to the client only that information which they are allowed to use in any way they can. If this means they can see through walls, it’s because you’re sending them too much information.
-
if you are concerned that the essence of the game is to use the default client rather than some arbitrary changed client then you’re going to have to use complex heuristics to determine whether the client is bona-fide. Anyone with >90% accuracy for 30 minutes is certainly using an aimbot… or are they? Is it not perhaps that they’re using the Barret and they’ve only fired 10 shots? etc.
Cas
[quote]Today the biggest problem in any FPS game, or rather any genre is probably multiplayer cheating hacks.
[/quote]
Not even close, I’m afraid… There are easily ten other problems that are much bigger. Perhaps “in the eyes of games-players” multiplayer cheat hacks are the biggest, but not for developers…
C and C++ are the same. Just find a really good C++ programmer - or any Asian software pirate who regularly cracks complex anti-piracy schemes in a matter of hours - and they’ll confirm this :).
Sigh. I keep saying this, but … They’ve been available for YEARS!
First, go and read the history of Diablo2:
http://www.counter-hack.net/content.php?page=article_blizzard
Second, go and look up some market data on how many millions of dollars profit Diablo2 made for Blizzard - even though it’s got no subscription model etc. (I don’t have a handy URL, google should find something for you though).
Doesn’t seem to have stopped people playing Quake, either…
When it comes to MMOG’s, it’s almost trivial to prevent this kind of cheating, and they’re the only ones where you pay a monthly fee, hence the ones where you would expect developers to care most.
Yeah java.reflection reads your code as an open book. So dont assume that your client is “your” client.
But what princec says is true, if he can see through a wall he has too much info.
But you have to keep some info on client for performance reasons (network and CPU). That will allow the player to see more than he is supposed too. I guess you have to decide if it realy matters, or rather WHAT matters.
[quote]I guess you have to decide if it realy matters, or rather WHAT matters.
[/quote]
If you can wait until the 2005 GDC, I’m just in the middle of writing a Gem on precisely this: “Secure by Design (for games)”. For obvious reasons I’m afraid it won’t ever be online, you’ll just have to wait and buy Game Programming Gems 5.
…or you could wait for my own book, which looks likely to be published in time for the 2005 ECTS (maybe earlier if I manage to write really fast :)), and which will have a whole section on security (in java game servers).
[quote]javagaming community gets a huge discount right ? ;D
[/quote]
No, but…good idea. I don’t get any say in the matter (that’s the publisher’s job), but I’m guessing that if Sun/GTG wanted to co-operate they’d be keen on a joint promotion that gave Sun-sourced purchases a discount.
Horay, I’ll be looking for your book in the near future. Thanks all for your input and it proves a valid point that if the hacked client can see through walls, the client has to much info, but also a valid point that it might be a performance issue without storing some stuff on client like that, for instance, if you wanted a player to be able to hear another player on the other side of the wall reloading in some spots, you would have to sacrifice. And yeah Blah^3 by saying hacks are the biggest problems in todays multiplayer games I meant in the eyes of the players, as “The customer always comes first.” Once again thanks all, keep any input coming if you have any.