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

If you were to compare a list of all the systems that could be affected by the addition of multiplayer with a list of all the systems that need to be in the game, the lists are likely to be the same. For example, adding multiplayer to a single player game can/will affect: Enemy AI (now the enemies have multiple enemies!) Rendering/animation (if you had a ...


12

In addition to Byte56's answer, there are a couple more things to consider: How are you going to communicate between the clients about player movement? Unlike most other player actions, which tend to be isolated events and likely somewhat infrequent, movement is continuous. There is a limit to the rate at which you can (and want to, for that matter) send ...


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

This is one of those "it depends" questions. Does your game have a lot of physics objects that would be hard to replicate? How much would high latency bother your game? What kind of libraries are you using? And on top of that, does the design of your game allow for multiplayer? Shoving co-op into a single player corridor shooter where you have your ...


11

In such cases, you may be better off letting the client be slightly authoritative. For such precise controls you're extremely unlikely to get good behavior even with really advanced correction and prediction. The client needs to extend from just sending "I jumped" messages to sending "I jumped from X,Y at time T" messages. The server then checks that the ...


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

As suggested by the top link in my Google search, you could calculate the individual changes in a players Elo rating (your R values), and then sum them up to provide the total change to apply to each player's rating. i.e. If you have 4 players (A,B,C,D), calculate the change to A's rating (R-sub-a-sub-new) from their scores against B, C, and D, and then ...


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


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