Slashdot Mirror
Enlisting Game Hackers Instead of Fighting Them
CVG recently spoke with Christofer Sundberg, co-founder of Avalanche Studios, the company behind Just Cause and its sequel. Sundberg expressed his disdain for both DRM and poor cross-platform ports, and talked about how he sees the hacker community as more of an ally than publishers do. Quoting:
"'... 50 percent of the people that work for me come from a hacker background - that's true.' When asked whether approaching leading hackers and asking them to put their programming skills to good use was a wise idea, Sundberg added: 'Oh yeah. I absolutely think that's a fair approach, to think about how these people can fit on the right side of the law. It's one way, at least. Perhaps the truest pirates are too much down the road of anarchy to ever work with you in a proper way; these are the guys who see us as evil! But in Sweden the [hacking] scene was huge... As a studio, we've found that there's definitely a lot of talent [in that community].'"
"The DRM does not stop piracy," he said, "it just punishes the people who have actually paid for the game. It's completely useless."
Agreed. So that must be why Just Cause 2 doesn't use any DRM.
Oh, wait, it does. And it punishes people who have actually paid for the game.
So at least his customers agree with that statement.
That being said, Just Cause 2 is a lot of fun. Unfortunately, the Square Enix taint is already there, and you get half a game out of the box with the rest being released as an endless stream of DLC.
And now that they're published by Square Enix, I wonder how long until we hear about Just Cause 2 2?
At least Square Enix has a fairly simple form of DRM that they employ. The just make games no one in their right mind plays.
I know, it's really tough to generalize like that but I ask this question because of an experience I am having right now and it's the very burning question I seek perspectives on.
My programming background is more formal. When I plan a project, I plan the UI, the data structures, the program code and of course, the intended functionality. Only after that do I start coding.
When I started in programming, I was a kid -- I just wanted to write code and see what I could make it do but I eventually outgrew the idea. But the more I did that, the more I realized I didn't know what I was doing and the more complex my programs became, the more lost in them I became. Those problems led to my needing to become better educated and more systematic in my approach to coding.
I have a co-worker who is absolutely enamored with hacking and cracking. He is by all definitions a script kiddie. He has managed to generate some simple apps which are useful, but when I look at the code, I am ... well, there is no kind way to put it -- it looks like a teenage boy's bedroom. And while he is coding his current project, he is routinely banging his head on the keyboard trying to figure out why he is getting segfaults and the like until he gets himself through that step of that module of code.... (I presume there is going through steps and modules) I have watched him kill himself over not knowing when to use an ampersand to pass a pointer or what have you. That's when it hit me -- he still has no grasp of C coding fundamentals -- it is not a part of his inherent thought processes when his is "thinking code into an editor" which is what a good programmer should be able to do.
As I said, I have seen his source code in PHP projects... not good. I have seen where he left output generated by program unclean and incomplete. Now I see he simply doesn't think in code at all --- he spits out commands and then tries to get them to work. All he does it hacking and cracking... he actually uses metasploit and meterpreter scripts in administrating PCs on the network.
And it goes without saying that none of this is documented particularly well if at all.
So the question is one I believe I already know the answer to -- are hackers/crackers better programmers? I think no. But what does anyone here think? I am pretty sure some will take the opposing view point and I suspect they will be the same people who once asserted that validating your input is a waste of processing and code execution time.
And we might not always tell you what you want to hear.
Back in The Day, I wrote a borg client ("Rogerborg") for Netrek which used a man-in-the-middle attack (and a bit of library overriding) to spoof the RSA authentication scheme used to detect blessed client binaries - Netrek was decades ahead of its time with regard to security.
It was a great learning experience, and convinced me that trusting the client is futile; there are always more people out there trying to crack it than you have developers to protect it. I kind assumed that in the 18 or so years since then that lesson would have been learned, but even to this day, we still see game after game released that try to play whack-a-hack on the client side.
Please take it from me: you can't win that fight. And that counts double if you have to pay developers to effectively fight against the enthusiasm of your playerbase. The more successful your game, the more potential crackers you have.
Saying "Yeah, put some checks in the binary, or ship it with Punkbuster and we'll fix it later."? That's a great strategy if you're planning for failure.
Secure the servers, come up a network protocol that designs out the ability for cracked clients to profit, and you're done. If your game doesn't lend itself to that design - like a twitch FPS where an aimbot can get an auto-kill - then bad news: You. Are. Screwed. Just try to make your costs back before your client gets raped and your game collapses under the weight of the bots.
If you were blocking sigs, you wouldn't have to read this.