Of cheaters and hackers

I spent last year pretty much by playing the SWGemu and sysadmining this cursed server. Both of them combined reminded me my previous attempt to run my Counter Strike 1.6 Cheat vs Cheat server. At first, it was just normal server for me and my classmates, which we later advertised on our towns teletext page. This attracted a few players but most importantly, cheaters. We struggled a lot trying to make the HLGuard and Cheating-Death work properly or just making it not break our server.

Then we tried the "warriors" method and when cheaters appeared, we turned our cheats on, to make them go away. This worked moderately well. Sometimes we caught ourselves playing many consecutive games of both sides cheating and having a ton of fun while at it. Soon we rebranded the server to be for cheaters only. In its half year run of 2006 it welcomed around 100 players and taught me 3 lessons just before inevitably shutting down.

1. It ain't no fun to cheat

Cheating by definition is the act of doing something to gain an unfair advantage over another player. It doesn't matter whether you install it or type it into a pre-built console. You do it to violate game rules in a dishonest way. Hacking, on the other hand, gains you a deserved advantage because you need to make an effort to make your code better than the other hackers'. The hacker culture doesn't promote unfair behaviour. Every neat hack is transparently promoted and shared among others. Enhancement of hacks is encouraged; enhancement of cheats usually isn't. They are often distribued in binaries which makes every player use the same tools, so in cheat vs cheat game nobody has any advantage. Such a game quickly becomes just update of a game mechanics.

2. Listen to your community

The majority of hackers are videogame players, but not the other way around. This was especially true for the Counter Strike 1.6 community. As much as we tried to encourage players into hacking the game, people were not into it. The majority of the audience had been burned by cheaters who ruined their games, and so they subsequently shunned new players who showed any sympathy for hack vs hack. I got into some niche CS hacking user group where I tried to ask for guidance for my server, but I ended up joining theirs, which didn't last long either because of the lesson 3.

3. Close source games aren't worth it

When Steam eventually steamrolled the independent server world, the cheater problem got somewhat under control. I waited closely for Valve's embracement of hack vs hack, either by rolling out independent servers for it or open-sourcing the game. None of it happened. Maybe the small community wouldn't cover the server upkeep for the former, but the reason for not pursuing the latter is quite obvious.

Opening the source code doesn't make your program open source. This might be a stretch, but it's something Eric S. Raymond summed up in his Case of the Quake Cheats[*]. If you don't plan for the program's code to be open from the get-go, you better not open it while it's not abandonware. Still, two releases later, Valve refuses to give the code to the community, even though they had more than enough time to either rebuild the game engine or fix it enough so the legacy parts wouldn't affect the current version.

When you can't see the game's source code, you'll have a hard time hacking it. The process might quickly change from hacking to cracking, which isn't fun and might get you in trouble too. One should know when to stop tilting at windmills and move on. I am thinking of making an HvH server for Quake, which made the same mistakes as CS, except for the last one. If I do so, the documentation will be the backbone of the project, as my main goal would be to encourage making your own hacks.

Who knows... Maybe this time around, with a better-fitting game, it could work well.