Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It
arrowPress Releases
September 22, 2019
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It


July 24, 2000 Article Start Previous Page 4 of 4
 

Who Do You Trust Baby?

In client-server games, because so much is controlled by the server, the game is only as good as the trust placed in the server and those who run it.

Rule #8: Trust in the server is everything in a client-server game.

An issue here is brought up because some client-server games can be customized by the user running the server. Access and configurability are great for many games, as they allow the player community to extend and evolve a game. But some individuals will test the server to see what can be exploited in the name of cheating. This in itself is not the problem - rather it's when honest but unaware players find their way to the server and don't know that they are not on a level playing field.

You really need to consider your audience here. A successful game will sell hundreds of thousands of copies, if not millions. You as a developer will be most in tune with the hard-core players - those that know the game inside and out. But it's easy to forget about the more casual players, who probably will be the majority of purchasers of your game once you pass a certain level of success. These are the people who don't know to check the status of the Cheats_Allowed flag before joining a server, or that game rule changes are transparently downloaded when they connect. All they probably know is the default game configuration, and when they see their ReallyBFG27K gun doing only 0.5 points of damage, they're going to cry foul. It doesn't matter that it was technically legal for the server operator to make the change, you still wind up with a user that is soured on the game and not likely to recommend it to his buddies anymore.

Naturally, people get a whole lot more unhappy with a game when they encounter modifications with malicious intent. What if a clan decided to add a tiny server mod to their FPS server that looked something like this snippet of C code:

If Player.Name->Contains("OUR_CLAN") Taken_Damage = Taken_Damage * 0.80;

Or what if the remote console was hacked to allow normal cheats to be toggled? Dishonest players in with the server could make a key-bind that resembled this:

Access_password on; set Cheats_Allowed true; Give Big_Ass_Weapon; Give Big_Ass_Ammo; Set Cheats_Allowed false; Access_Password off;

The important point here is that with user-run servers and powerfully configurable game engines, these kinds of shenanigans will happen. While we as developers can't protect our more casual users from joining any game server they wish, we can do a better job of letting them know when they are encountering something that could be different from what they expect. Quake 3: Arena set a great example when it introduced the concept of a "pure" server. It's a simple idea that casual users can quickly grasp and set their gaming expectations by.

But why stop there? If we download data that includes a new set of weapon properties, why not put a message on the screen saying, "Weapon properties modified"? If single-player cheat commands are issued in the middle of a game, maybe we should send a message to every client notifying them of that fact, so even players who aren't near the issuer can be made aware. Empower players to easily determine whether the games are fair or not.

Rule #9: Honest players would love for a game to tip them off to possible cheating. Cheaters want the opposite.

Bugs & Design Issues

Technically, this category of cheats is one that we bring upon ourselves: bugs in our games can be discovered by users and used to disrupt game play. Most bugs don't enable cheating, but a few do.

A good example is the farm-stopping bug in the unpatched version of Age of Empires. When a user had both a villager and a farm selected, he could issue the Stop command. Because the command was valid for a villager, it was allowed to go through, but listed both objects as the target of the command. The villager would stop working as expected and reset its state. The farm would also reset itself, something it never did normally, and replenish its food supply. Once this was discovered by players, it drastically changed the game for them, giving them a huge advantage over those who didn't know about it.

I encountered another bug when playing Half-Life. I would get into a firefight with another player, both of us using the same weapon, but when it came time to reload our weapons, my opponent was able to reload much more quickly than I could. Sure enough, when the next patch came out, I saw in the release notes that a bug allowing fast reloads was fixed. There's really not much we can do about these types of bugs, other than fix them with a patch.

Environmental Weaknesses

My last category of cheats is something of a catchall for exploitable problems a game may have on particular hardware or operating conditions. A good example is the "construction-cancelled" bug that was found amazingly in both Age of Empires and Starcraft at about the same time. The element needed to make it work was extreme lag in network communications, to the point of a momentary disconnection. When this happened, the game engines stopped advancing to the next game turn while they waited for communications to resume. During this time, the user interface still functioned, so the player didn't think the game had locked up. While the game was in this state, a player could issue a command to cancel construction of a building, returning its resources to the player's inventory - only the player would issue the command over and over as many times as possible. Normally, a player could only issue one Cancel command per turn, but because the game simulation was in a holding state, multiple command requests went into the queue. Because of some necessities of RTS engine design, when an object is destroyed during a turn by something such as a Cancel command, the destruction is postponed until after all the commands for that turn have been processed. The result was the command executed multiple times during one game update.

Once discovered, this had a horrible impact on online games. People deliberately caused massive lags to take advantage of the cheat. To fix it in Age of Empires, we had to update the validation checks to see if a similar request was already pending on the current turn and reject duplicates.

Another bug of this type involved the game Firestorm and its interaction with the Windows clipboard. It seems a clever user found out that if he pasted text from the clipboard into his chats and that text contained a certain character not normally used, the game would crash when it attempted to print it to the screen - on all player's machines. He then treated this knowledge as a personal nuclear bomb that he could spring on people when he found himself losing.

Yet another example taken from Age of Empires is what happens when a player's network connection is overloaded or ping-flooded by another player. When such an attack renders a game unable to communicate with its peers, the other players decide that something is wrong with that player and drop him from the game - a totally necessary capability, but one that can be exploited in a modern twist on scattering all the pieces on a game board when you are losing. This was one the major reasons we added Multiplayer Save and Restore capabilities to Age of Empires II.

Some Final Thoughts

I hope these examples got you thinking about some of the problems and issues at stake when developers address the problem of online cheating. We certainly have a lot more ground to cover, from massively multiplayer games, open source, and consoles, to enabling the online communities to better police the situation. But we're out of space and time for now.

Matt Pritchard is busy trying to be a modern renaissance man. When not working hard on his latest game, he can be found spending time with his family or collecting antique videogames. Send e-mail to [email protected].


Article Start Previous Page 4 of 4

Related Jobs

University of Exeter
University of Exeter — Exeter, England, United Kingdom
[09.20.19]

Serious Games Developer
innogames
innogames — Hamburg, Germany
[09.20.19]

PHP Developer - Tribal Wars
innogames
innogames — Hamburg, Germany
[09.20.19]

Java Software Developer - New Mobile Game
innogames
innogames — Hamburg, Germany
[09.19.19]

Unity Software Developer - Core





Loading Comments

loader image