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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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:
Insulting or threatening behaviour,
Circumventing copy protection,
Distributing pirated software,
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)
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
I would like to know if people could modify an HTML 5 game's code
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 ...
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 ...
You cannot prevent it (in situations which are equivalent to running arbitrary native code supplied by others).
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.
Another interesting question where I can cite that awesome quote I've found on the internet a few years ago regarding the creation of multiplayer games:
The client is in the hands of the enemy.
Whereas the enemy is the player trying to cheat or "hack".
Overall, there's no 100% perfect way to avoid hacking, cheating or botting.
One of the easiest way to ...
You can do this by making the secret starting state verifiable and guesses difficult:
Have all players generate a new private/public key pair, send the public keys
Let them shuffle their own decks
Choose and/or exchange salts (see below)
Generate signatures for the information you want to check:
Either a player's full deck if that can become known after ...
No browser supports an unlimited amount of storage space (or anywhere close to your 800MB) for arbitrary web apps out of the box, and most are limited to 5MB to 10MB.
The easiest way to explicitly cache data is to use the Application Cache (manifest). You can also use LocalStorage if you want to programmatically download levels in advance rather than ...
I don't neccessarily disagree with the soft-science answers but there are technical things you can do to detect botters and some things that just make life harder for them.
Grade accounts by how much you suspect they're using a bot. This will feed into several other techniques and protect legitimate users from your wrath.
Rotating the session cookie key. ...
This question has actually been asked several times, and the answer is always the same thing; you're not going to like it. It's impossible to keep things like this a secret. You can however, take measures to make it more difficult for your passwords to be discovered. Essentially, you could convert it to a byte array and then perform some kind of hashing ...
I'm not a gamer, but my first thought was that if multiple people use the same account, any analytics collected about the user would be difficult or impossible to interpret. Not sure if games collect analytics, but figured I'd throw it out there.
You can invent your own algorithm, as simple or fancy as you like. It'll be horribly broken, but it will have to suffice. You're asking for good ways to secure save-state passwords. There are none. At best, you can try to frustrate the player until he gives up.
The reason these methods don't work is that they fundamentally try to do something out of their ...
In a little game I'm making using Unity, one of my build targets is the Web Player. I had the situation where I wanted to remember the configuration of the last launched ship, and allow the player to save various configurations by name.
As you say, standard file I/O isn't supported. However, Unity provides the Player Prefs class for storing data in both ...