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 ...


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 ...


27

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

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 ...


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

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 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.


4

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 ...


4

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. ...


4

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 ...


4

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.


3

Create a separate bot only server. Create a leaderboard and celebrate the winners. Look at the data this generates. Ban users from normal severs whose behaviour profile looks like that of a bot.


3

The security implication you are worried about is a 10 year old changing the clock on their device to cheat the system. My daughter when she was 5 learned how to change the time on her iPod to get a new batch of coins in Coin Dozer. So it is a valid concern. But you have to count the cost. My goal is to reduce cheating by making it harder. To me it's ...


3

A determined modder can and will always modify any part of your game which runs on the users system. You can put obstacles in their way to make their life harder, but you can't stop them. Creating a hash of your assets can be countered by finding that hash in your executable and changing it too. When you encrypt your assets, people will find the decryption ...


3

Do not have a client talk to a database server. The client talks only to the frontend game server, and nothing else. That server then distributes client requests to the appropriate backend server. The frontend servers and (most) of all the other servers are distributed geographically. Not distributing the front-end server as in your diagram defeats almost ...


3

As a first step to securing the game you can't allow any user to run the actual game logic on their computer. If they can do that then they can also reverse engineer it and hack it easily. What you need to do is have a secure server under your control which runs all the game logic. The client program on the users computer simply sends moves to the server ...


3

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 ...


3

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 ...


3

first get the bitstring for the standard way you described then just encrypt it with some symmetric cypher and chosen key then you pack that into the password string into something the user can enter


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