50

If people want to bot, I don't think you can really stop them. You can of course implement many measures that make botting more or less of a pain. But you can only do so much before your codebase turns into a gigantic mess that's hell to maintain, error prone, and annoys legitimate users. Meanwhile the botters will always find a way to defeat your ...


47

The short answer is you can't do it. Anything that runs client side, especially from source, can be modified to defeat your tactics trivially. If you put in place a client side checker to look for abrupt changes, a user can just disable the checker. The good news is that, generally, there is very little cheating on single-player games. The only major ...


42

Specifically regarding the last bit of your question: No, it is never forgivable to have an insecure authentication system. Users are rarely enlightened when it comes to computer security. Users use the same password for your little game as they do for their Google account, Facebook account, bank account, and so on. Even if you can claim that it's their ...


31

From both a legal & security standpoint, the single biggest factor I'm aware of is accountability. If you cannot determine who is responsible for the account, you cannot reasonably hold anyone accountable for actions related to the account. For instance, money laundering is easier if you cannot trace account ownership. Forbidding shared accounts won't ...


26

In addition to all the other answers: Prohibiting this has also the benefit of balancing the game from the point of view of players that won't be sharing their account. Assuming that account sharing is allowed, a player who wanted to have an account only for himself could think: Ah, even if I dedicate my whole time to this game, and even if I play in ...


24

Basically, you have three requirements: it should not be easy to use the same key for multiple client instances, it should not be easy to generate new valid keys, and it should not be easy to steal the key of a legitimate client. The first part should be pretty straightforward: just don't let two players log into the same server with the same key at the ...


24

The best and only effective defense against bots is to design your game in a way that players don't feel the need to automatize in the first place. When your players automatize simple tasks which do not actually require skill, it is a sign that your user interface is lacking and they are substituting an UI feature they are missing. Does your game include ...


23

Don't make your game so vulnerable to johnny-on-the-spot effort First, make sure that players who only play your game for twenty minutes or an hour a day in a single sitting aren't at a huge disadvantage to players who leave it open at work and play 16 hours a day. This may require a change in your game mechanics - for instance a move allotment that fills up ...


19

Besides the legalese mentioned in other answers, there are also simple business reasons. Some games like World of Warcraft charge people by account. If you let two people share an account, you lose 50% of your revenue. Other games like League of Legends charge people for being allowed to use ingame content. That content is bound to each account. If you ...


18

Don't just send an integer score to the server. Send a collection of game stats that can be used to verify the score was realistic. Or you can implement some pre-shared key for calculating the score. You could send incremental scores and stats throughout the game and ensure that the increase is reasonable. However, I wouldn't worry too much about it. The ...


16

There's no 100% savety, but you could start with a rather simple approach: You'll need some way to verify generated keys, for example included checksums. Of course, this must not be too easy to figure out. Optional (but recommended) there'd be a server side database verifying the keys with a database of all given out keys so you can't generate keys, even if ...


14

I already answered a question like that here, and I'm sorry to tell but: I wouldn't bother to make some server side simple checking, but I don't want to go the Diablo 3 path keeping all my game state changes on the server side. Is the baddest thing you could have say here. If you wanna do an "anti-cheat" engine, you'll have to do that. You can add ...


14

I once found a very neat quote on the net that's very, very true for any online game: The client is in the hands of the enemy. As such, you can't really avoid people doing nasty things to your game client. Due to this, don't trust the client at all, i.e. everything important should at least be verified server side (better: calculated there). If this is ...


14

Attack vector 1: The netcode As already pointed out by Mario, one important factor when designing the network protocol of a client/server application is to not blindly trust the client. You can't control the software which runs on the client machine. You can't even tell that it's your software and not something the user programmed themself. The same ...


13

That's interesting problem, but I think you are asking the wrong question here. Let me start from detecting hacked client approach: If your client is executed on user's side, he can do whatever he wants with your code (until it's too complicated for him, but there will always be someone smarter in the line). Everything you can do like hard-coding encryption ...


13

You can't stop them. But you can make their lifes miserable, as they have to spend lots of time writing their bots, and updating them. You have to use whatever you have to verify if user is valid. Check for request headers, and reject requests with invalid values. Either set custom headeror check for existing like user-agent. Sure it's easy to overcome, but ...


10

As Byte56 said: "never trust the client", but: Never trusting the client comes at a price: Having all games being played on the server will increase your infrastructure cost a lot. Assuming most of the players won't cheat and the top highscore will settle after a little time and stop changing a lot there is a middle way. Record the games (on the ...


10

It is absolutely standard that if you have an account for a service, then you are responsible for what is done with that account. In game terms, some of the things which can be done with an account might include: Cheating, Playing disruptively, Insulting or threatening behaviour, Circumventing copy protection, Distributing pirated software, Distributing ...


8

You might think it's hard, but the way you came up with is the way to do it: send not the points, but e.g. all the moves of the game, and then the server recomputes the game and calculates the gained points (this is just one of a million reasons why developing multiplayer online games is harder than developing single-player games)


8

In general, distinguishing between bots and humans fully automatically is hard, some form of human-assisted decision process works best. What I would do: define some heuristics that hint the user is probably a bot - doing a lot of actions, doing stuff 24/7, ... Then if these heuristics get over a certain threshold, do an invasive check. You can manually ...


8

Embrace the botter. You've built a restful API, perfect for a coder to experiment with automation of your game. Design your gameplay so that the bot doesn't gain an advantage over a human player due to being automated - eliminate the advantages of speed of execution etc that a machine has; design your game so the bot provides the same revenue as a human ...


7

Yes. You definitely should. Use Let's Encrypt to get a free SSL certificate (or as many as you want or need). SSL is always good to have: without it, man-in-the-middle attacks will be launched, by the NSA if no-one else. Most multiplayer games (e.g. Minecraft) just use raw packets. There's little reason to encrypt packets after one is authenticated as only ...


6

In addition to all the other answers, there is another reason: Ensuring leaderboard integrity by prohibiting account sharing and multi-account usage. A famous example is the rhythm game osu!, which states as its first rule: Due to the game's ranking system ("performance points") absence of this rule would destroy the leaderboards, as a top player could ...


6

In addition to the many fine answers, there is another reason. Game companies don't want to arbitrate your personal squabbles. If you share your account with someone, you allow them to delete your characters, sell your items, or simply change your password and lock you out. Many people would trust some people with their account now, and would regret this ...


5

I though about server asking client about its md5 however it's so easy to cheat. MMOs include a version checking system to help make sure that legitimate (non-cheating) users are using a compatible version, and to help them upgrade to a compatible version if they are not, in short its to make updating easier for the player rather than for any form of cheat ...


5

I would like to know if people could modify an HTML 5 game's code Yes. Like all web technologies, the client has full access to the local code; they can browse the source, modify it and send unexpected data to the server, or sniff what the server is sending to the client, but not displayed. to harm either the server Yes. This is not specific to ...


5

I can see a single aspect why they would ask you not to do it: money. If you share your account credentials with someone you trust, but end up losing all your stuff because that someone ended up not being trustworthy, you might ask the help-desk to recover the items for you. They would have to pay an employee to trace back where your stuff is. This would ...


5

You cannot prevent it (in situations which are equivalent to running arbitrary native code supplied by others). You can: curate the mods screen submissions with a scanner restrict your API as much as possible select a language that is safety oriented sandbox foreign code All of these increase safety to varying degrees. But none of them are a guarantee.


Only top voted, non community-wiki answers of a minimum length are eligible