51
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 ...
37
You don't want to send player input to the server. What you probably want to do is send an abstracted representation of what the player wants to do to the server, and then run the logic on there.
Likewise you don't necessarily want to send back everything the client needs to do. For example, you can send some kind of message saying "NPC X died", and the ...
30
The way one would deal with this would depend on the game and what would make sense for that world. For example a sci-fi game, they could "beam up" to some space storage facility for cryo-sleep. A fantasy game could have them cast a spell on them self to fade away. Or they could be sucked into a portal. Make them turn really small and a bird or robot comes ...
26
Get user authorization and tell them exactly why you want that data. You'll get judged harshly in the court of public opinion for sneaking around in a player's machine and uploading information to your private servers.
I am not a lawyer, you may want to ask a real lawyer whether clandestine information gathering is illegal in your jurisdiction.
Whether it'...
25
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 ...
21
The only similar system I know is OGame. In OGame, players are protected from other players until the have a certain amount of points (I think it is 50.000). It makes more sense to protect players based on their score instead of time, as score gives you a better aproximation on how powerful players are.
The theory is that with that many points, players are ...
21
While ideal, it is practically improbable to validate every single input against the server, both in terms of computational load and latency in input confirmation for the client.
Consequently there are usually a handful of things that aren't validated on the server in many MMOs. In some cases this includes certain classes of character movement, which is why ...
18
Simple ways to protect your game:
Duplicate your data: store some information twice and compare the copies. If they are different, something is going wrong. You don't have to do it per variable, you can also make CRC's on some big areas of memory (ex: on a struct that contains all player information).
Encrypt your data before its written to memory (and ...
15
You can't stop memory editing cheats, so design your game so that such cheats won't matter. For an online game, sensitive data like money on your own server, and don't rely on the client to have the correct amount. That way it won't matter if players change the amount of money displayed on the client, because when the player purchases stuff the game checks ...
14
Well, you got answers but your real answer is at "try yourself". The things differ from game to game.
I did couple of multiplayer games for some distributed network game design course. The most challenging was doing a realtime action game where many players involved and sending inputs like hell. When it comes to that point, everything becomes problem. As ...
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 ...
13
You wouldn't bother.
Immersion (wiki) :
The state of consciousness where an immersant's awareness of physical
self is diminished or lost by being surrounded in an engrossing total
environment.
This term is often used in the wrong way ; people think that good graphics makes a game more immersive, or that a real physics simulation will do the same....
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 ...
13
You could save all the data both locally on your player's computer, and sync it automatically to Steam Cloud, which indeed allows you to store stats/user preferences/progress/etc.. online.
Steam Cloud API :
header: ISteamRemoteStorage.h
Game settings, savegames, and other user-specific bits can
be replicated to the Steam Cloud to provide the ...
12
If you want the feature, implement it.
If you don't want the feature don't implement it.
If you're unsure if the player wants it, implement it and notify the user if the other player disconnects and give them an option to continue with the AI player.
11
Here's my two cents:
P2P:
Pros:
No need for a central server: this makes it much cheaper, and more viable for low-budget indie games.
Scales very well (up to a certain point when the average client just can't handle the bandwidth).
Very good for data distribution: Suits games where user-created content is dynamically synced (e.g. torrents).
More Stable: ...
10
The coolest solution for this that I have heard about is how Neal Stephenson envisages how it could work in his book Reamde.
Every character has a fairly intelligent auto-pilot. If your character is a fighter and you log off/loose connection, your character will spend its time training martial skills, eating, sleeping and so on. If your character is a miner,...
10
Reduce progression in your game mechanics. Avoid making players stronger in a game-mechanical sense based on how far they progressed in the game. That way an experienced player has no unfair advantage over an inexperienced player except for their game knowledge, which a new player can also acquire when they do their research.
Herd your players. When a player ...
10
One of the reasons why there are protections is that reading the game state could allow bots to know the state of the game and act accordingly.
For instance, grinding in a MMO: if the "bot" knows what mob is around, it can send commands to the game clients to select the mob, hit it until its life is 0, pick up the loot, rinse and repeat. With this, even if ...
9
Online multiplayer is becoming an increasingly important factor in my decision to purchase games. While that may just be me, it appears that people overall like to play games with other people. Social media games are a good indicator of this, though, I don't really consider those multiplayer for the most part. They do indicate that people like being able to ...
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
You could try setting up your own server running one of the open-sourced MMO codebases. PlaneShift is one such game, and WorldForge has (last time I looked) several games with simpler rulesets. Ryzom is a formerly closed-source MMO that released both their code and their assets as open source.
Setting up your own server from these codebases will probably ...
7
Some of the old DIKU muds had a system called 'rent'. Your character only saved if you went to an Inn to log out, and payed enough rent to cover the cost of keeping your gear. It might seem a bit punitive to modern players but it had the effect of making characters appear to go to inns and sleep when they were out of the game, which keeps with the fiction.
7
In order to get a server list, you will need a central matchmaking server to which all game-servers connect and announce that they are online and to which all game-clients connect to obtain the list of currently online servers.
How many servers are you going to have? For comparison, I remember that during the high-times of the original Counter Strike, the ...
6
I first thought I would simply put it in the (MySQL) database
Sounds good!
but I think it will be too much.
Then you don't know the limits yet.
Seriously, just throw everything in a database. Don't care about performance too much at this stage, if it becomes an issue you can fix it later.
Here's an abstract view of what your database could look like:
...
6
A combination of both strategies would likely yield the best results. Just keeping track of when user join/leave might not account for situations where the user is unexpectedly disconnected. A periodic poll would likely have to happen too often to get reasonably updated list of players joining and leaving.
So, update the list when a player joins or leaves ...
6
The resolution should not affect computation of simulation logic such as "where your bullet hit." Any reasonable game will divorce such simulation data from the final render resolution of the screen. That means the main thing you're talking about with respect to resolution is what the player sees.
If all other things are equal, then a lower resolution might ...
6
Many MMO's are designed with client-side hit prediction. So if there is a hit on the client, it sends that result to the server that there was a hit. In this case the server is not truly authoritative, and thus cheating is possible.
To be honest, if I were designing an MMO, I would make the server fully authoritative, with the client only sending clamped ...
Only top voted, non community-wiki answers of a minimum length are eligible
