77
In the end it all boils down to one axiom: Game design is hard!
And multiplayer game design is even harder. After years of development, you think you came up with a perfectly balanced game design which allows for multiple viable playing strategies. You did extensive playtesting with a dozen or so full-time inhouse testers and a hundred external spare-time ...
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
When you look at the countless other questions about preventing cheating in multiplayer games which are on this site you will easily see that there really is no technical measure to prevent client-sided cheating.
All you could do is provide less information about the cloaked entity. All the client needs to know to render the distortion effect is that there ...
30
This could be considered an animation problem. If a position correction comes back from the server due to an attempt to move into an invisible object, send back not only the correction but a flag indicating why the correction was needed. Instead of a player popping backwards, he may do a "woah" kind of reeling backwards animation, making it more believably ...
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 ...
22
Simple answer: cheat or don't be that accurate!
If you've played some shooter online, you'll most likely have experienced the so called "rubber banding" if your connection to the server is bad.
This is caused by your client correcting your position from time to time.
Basically, what happens on the two sides:
The server will track your movement and send ...
20
You can't implement a shimmer effect without making it easy to exploit... but what if you used an indirect means of showing that someone is around, a means that also applies to visible players?
For example, what if players leave footprints, and "footprint created" messages are sent from the server independent of player location? Every player leaves ...
19
It's no real hardware or software limitation. Cross-platform gameplay is possible, if implemented. Final Fantasy XIV - A Realm Reborn is a perfect example, featuring cross-play between consoles and PC.
If a game is released on multiple consoles and/or as a PC game in parallel, non-cross-platform multiplayer is most likely a design decision either due to ...
17
You're on the right track.
The gist of the client-server networking model is that a server is that it's a central point of knowledge that clients connect to. A game server typically contains
an in-memory world representation,
a list of connected players,
a game loop (with e.g. player control handler, a physics engine & AI).
You'll also need a ...
16
This system with all these triggers sounds a bit too complicated and error prone.
You could wrap the position of the player using modulo with something like playerPositionX = playerPositionX % mapWidth
This way when your player reaches playerPosition == mapWidth the playerPosition will reset back to 0.
This solution could be extended with the whole ...
16
You said it: Dota has a mixture of RPS balance and fixed, hidden character selection.
The characters that the enemy team chooses to play are hidden information, and thus you must evaluate your own choice of character against a probabilistic model of what the enemy is going to play. Because outcomes in Dota are more dependant on hero selection than in Lol, ...
14
You can use random seed. Select same 32-bit value in server and client (or server can send it to client at start). Use it as seed for random generator. You can send actual seed from server to client with game state update. If you don't want to send it you must be sure that client and server generates same number of random numbers by this random generator.
...
14
There is no reason to communicate over the network when the player selects units, because in most games just selecting a unit has no game-mechanical consequences. So this is an information which isn't relevant to the server or to the other players.
But what would be important is when the player gives a command to one or more units. When issuing a move-...
13
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: ...
13
Server-side hit detection isn't to prevent aimbots, it's to prevent cheaters who simply tell the server "I hit!" regardless of where they are aiming.
13
The canonical solution is to use portals. In your example, there is only one level, except there is a portal connecting the left and right ends.
Anything moving across that portal will have its coordinates translated to the other end of the portal, so that if something is moving left through the portal, it will reappear on the right side of the level and ...
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
There are two common patterns for use of Lerp. The one you're using is:
current = Lerp(current, target, sharpness)
(where sharpness is a constant between 0 and 1)
Note that there's a feedback loop here. The value of current is both an input and an output, so the value of current we use as input in the next frame is the output from the last frame.
This is ...
13
Player of both here. DOTA has a set amount of damage for most attributes. A Lina ultimate will always deal X amount of damage unless the enemy has a debuff on them that increases the damage they take. This means that Mage damage output from skills remains relatively the same throughout the game.
However, this is offset but each character having a "main" ...
12
Without knowing more about the exact game you're writing, and how you're writing it, it is very difficult to say generic solutions to your problem.
However, you may want to consider this decision you're taking of leaving the networking code to the end, depending on how crucial networking is for your game.
What I mean is that, if you're writing a network ...
11
As others have said, the first step is separating logic that's shared from logic that's not. While it's great to draw that line wherever it's clear, your addendum illustrates that sometimes you don't have a clean line to split the code down.
So, how do we solve cases where the client and server want to do semantically the same thing (play a sound), but take ...
11
Simply limiting the number of clicks a user can make approaches the problem from the wrong angle. At best, your players will perceive your game's input controls as unresponsive and glitchy. At worst, they will notice that you are using a cheap trick to prevent them from getting better.
If you want your game to be decided by macro-management strategy and not ...
11
How much do you believe in the open source idea? When you are not 100% committed to the free software philosophy, then there are some interesting variants:
Release the client under an open source license, but not the server. Any private servers will have to write their own server software. That software will always be behind yours feature-wise, so those who ...
10
Problem analysis
Real-time communication over a high-latency connection is obviously impossible.
You can of course attempt an illusion (as you're doing by making the remote player appear to have passed an obstacle when it's not yet known). When that illusion fails (as yours does when the remote player didn't actually pass the obstacle, but died instead) ...
10
When you want perma-death to matter as much for the victim as it matters in real-life, you also need equivalent consequences for the killer.
In just about any real-life society (present or historical), murder is the crime which receives the highest punishment that society is willing to administer. In any judical system of today, a murderer is either ...
9
It results in packet loss for UDP due to contention between the two protocols - remember that UDP is not guaranteed delivery, while TCP is. More TCP packets will get through while UDP suffers - TCP induces UDP packet loss. There has also been the (historical) idea that router infrastructure favours TCP over UDP, though I doubt that is still true by this late ...
9
So players in a competitive game either have fun or lose. Why not both? Losing doesn't have to feel bad, or rather, you can have fun without winning.
A lot of team-based games do this by de-emphasising the win/lose outcome itself, and provide lots of alternate goals (and even meta-goals). Your team may lose but maybe you topped the scores. Or you made the ...
8
Depending on the complexity of your game, verifying if an action is legal or not might require to backtrack large parts of the game. An example: Player A says Player B can't play that card right now because he has no ResourceX. PlayerB says he has plenty ResourceX. Who is right? To find out you would simulate the whole game again from start to finish to ...
8
The network layer needs to have an agreed-upon clock. They can agree upon a clock value early in the game (and resync it periodically in case of drift) so the host knows how long any particular packet took to actually arrive and when the client did the action, and vice versa.
See this article for one possible way to synchronize clocks in games. There are ...
Only top voted, non community-wiki answers of a minimum length are eligible