18
\$\begingroup\$

I've been thinking about implementing stealth in a multiplayer game. It's a MOBA style game, so think League of Legends (LoL) and Heroes of the Storm (HotS). Multiple clients connect to a single server, which broadcasts the game state to all clients. Clients send their input data to the server, which might reject it when encountering invalid commands, thus rendering cheating impossible (well, in theory).

Now, I mention these games on purpose because both implemented stealth differently. LoL has stealth with two possible states: you're either completely visible or completely invisible. HotS on the other hand, implements stealth in such a way that you can tell by a shimmer in the air:

Heroes of the Storm invisibility

I think this is a neat mechanic, as it promotes / rewards paying attention to your surroundings. However, this being a multiplayer game made me realize that this might prove easily exploitable.

When you implement stealth in 'the LoL' way, you can simply stop sending player coordinates to the other clients. When the player's character breaks stealth, the server can broadcast the location again. However, with the HotS model, a shimmer can be seen in the air where the character is moving about. This means that the server must be sending the player's location to the other clients. Which means that players that change the texture or model or even the game code itself could render the cloak mechanic useless. Here is a thread on the HotS boards about it.

My question is whether there is some way to implement cloaking (with a 'shimmer', à la HotS), without having the issue that crafty players can modify the game (data) and 'beat the system'. Is this possible, and if not, how do other multiplayer games with this mechanic deal with this? Is only the LoL style of invisibility uncheatable?

I thought about having the server send bogus 'cloak' locations every now and then, but this also harms fair players that are just paying attention, so that won't do.

Improve this question
\$\endgroup\$
7
  • \$\begingroup\$ Related is link, but I'm not asking about bumping into others (which can be handled by the server) but rather displaying cloaked units. \$\endgroup\$
    – Underflow
    Aug 3, 2016 at 19:51
  • \$\begingroup\$ This is a bad suggestion, but you could do all graphical rendering on the server, then broadcast each players screen to their clients. They only send input, you only send output. The client is a thin shell that simply displays the video and plays the audio. \$\endgroup\$
    – user137
    Aug 4, 2016 at 8:14
  • \$\begingroup\$ Philipp got a very good idea there. I want to add that you still have to be aware of bounding boxes and their intersection with skillshots etc. If you are sending bounding boxes, a smart coder can reverse engineer what character is invisible (if there are different heroes). If you have any effects that trigger on hit, then you will have to send anything like the box or at least position and scale of the effect. Be aware that everything more abstract is more \$\endgroup\$
    – Greaka
    Aug 4, 2016 at 9:31
  • \$\begingroup\$ You can't actually implement LoL-style cloaking by ceasing to send player coordinates. Even if the characters don't get drawn, they still need to be able to interact with the map (and other players) in other ways. But implementing "detectable" stealth (footprints, shimmers, etc) removes much of the incentive to go through the trouble of modding the game anyway: you learn how to detect cloaked characters and move on. \$\endgroup\$
    – The Spooniest
    Aug 4, 2016 at 13:46
  • 2
    \$\begingroup\$ @TheSpooniest: could you explain what you mean by You can't actually implement LoL-style cloaking by ceasing to send player coordinates ? If player A is invisible and the server doesn't send the co-oordinates anymore to players B and C, the server can still handle e.g. collision between players A and B by refusing to move B's character on top of A (as if they walked into a wall). If A (still invisible) fires a skill to B, the server can simply send "skill fired from position x,y in direction d from A" to B and C. \$\endgroup\$
    – Underflow
    Aug 4, 2016 at 13:51

4 Answers 4

Reset to default
20
\$\begingroup\$

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 footprints so you can't make the footprint model more visible without covering the arena in them and making every individual print less noticeable, but if a player sees a footprint appear without a visible character they know someone is there.

You can also do stuff like having small pebbles that are knocked around, rustling grass when someone is walking through it, or ripples that appear when someone moves through water. If 'signs' only apply to certain locations or materials, this could add extra strategy that forces invisible characters to move carefully and avoid things that will give away their positions.

Improve this answer
\$\endgroup\$
6
  • \$\begingroup\$ without making it easy to exploit -> This applies to all game mechanics, not just this particular one. \$\endgroup\$
    – starikcetin
    Aug 4, 2016 at 5:56
  • 12
    \$\begingroup\$ Regarding the last paragraph: Keep in mind that when an invisible player is the only thing which causes these things to happen, then you are providing information which is useful for hacks. But you can also trigger each of them from time to time through random events or other player actions. That would generate noise which distracts the hack and has the nice side-effect to make the environment appear far more alive and dynamic. \$\endgroup\$
    – Philipp
    Aug 4, 2016 at 7:49
  • 2
    \$\begingroup\$ This is a very interesting idea, thanks! In case of the 'footprints', this might even reward stealth players to 'walk inside' their target's (old) footsteps, making sneaking up to others more realistic (i.e. coming from behind). Even if someone made the footstep textures (or what have you) more obvious, stepping in them would (perhaps) only refresh the display duration. \$\endgroup\$
    – Underflow
    Aug 4, 2016 at 11:49
  • 3
    \$\begingroup\$ Of course, in this case a client side hack could be made to show which tracks are fresh. \$\endgroup\$
    – Muhd
    Aug 4, 2016 at 21:02
  • 3
    \$\begingroup\$ A client side hack could highlight footprints that are created in regions that don't correspond to the location of a player. \$\endgroup\$
    – Edward Coffey
    Aug 5, 2016 at 0:58
30
\$\begingroup\$

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 is something cloaked at that position. But it doesn't need to know anything specific about it, like what exactly it is, how much health it has left and what it is doing right now. Depending on your game, that alone can be a game-changing information deficit for the player.

Improve this answer
\$\endgroup\$
5
  • 6
    \$\begingroup\$ With "less information" also comes "less accurate information". Choose an offset of (say) 10 feet in a single random direction that is kept on the server side and send that location instead. In random other encounters, add false shimmering characters "Did you see that? I thought I saw something there." \$\endgroup\$
    – Keeta - reinstate Monica
    Aug 4, 2016 at 17:51
  • 2
    \$\begingroup\$ @Keeta if you utilize this, you'll want to do some smoothing (i.e., not generate a fully random value each time) either with a signal filter or with some kind of Random Walk towards the direction of the entity. If it's too jittery then it's really obvious to the eye, so you'll need to balance the player's ability to be hidden during movement and be hidden when staying still. The latter will and should be more effective. \$\endgroup\$
    – Nate Diamond
    Aug 4, 2016 at 18:55
  • \$\begingroup\$ @NateDiamond Yes, exactly. That is why I state that the server creates a specific offset of the actual location. Then, as the real actor moves, the offset will cause the shimmer to move as well. By carefully watching the shimmer as it moves, you can deduce where the actual actor is, but that takes some work. If invisibility were real, and caused this shimmer in real life, I imagine this extra focus is exactly what would be needed to overcome the invisibility. \$\endgroup\$
    – Keeta - reinstate Monica
    Aug 5, 2016 at 11:26
  • \$\begingroup\$ There was an interesting modification, and the only one that actually worked, of ioquake3 to make a wallhack-proof server. The idea was to server-side check if a player A could see another player B (ie, no walls nor other separation blocking the view) before deciding if player A should receive the position info of B. This has proven to be highly effective against wallhacks, as they were rendered useless. So the bottom point is that the only way to ensure that nobody manipulates the data is to not give them any info at all. \$\endgroup\$
    – gaborous
    Aug 5, 2016 at 13:02
  • \$\begingroup\$ @gaborous that's an expensive check to do though, especially for every player at every tick. It may very well be a worthwhile expense, but is something that the developer will have to consider in the cost and abilities of the server. \$\endgroup\$
    – Nate Diamond
    Aug 5, 2016 at 16:47
1
\$\begingroup\$

Yes, any information that you send to the client, can be showm more obviously than you intended. But here is the trick:

Mitigate the impact

Sure, the client may have some information, but by thinking carefully on what information you are willing to share, and on what players can do with it you can at least mitigate the impact of client hacks.

1. What does the player observe?

  1. You see the character with characteristics on the spot: In this case the client will have all information and hacks can simply undo the cloak
  2. You see something on the spot: In this case the client has location information. It can make the location obvious but other information should still be hidden.
  3. You observe something but it is not in the spot

a. You see something but it is not on the spot (Bridge or bush moves, but its large so you don't know where to aim; footsteps only become visible with a 2 second delay): In this case the client only knows that there is something, but not where/what exactly.

b. You observe something in a different way (sound if something is in the area; closeness indication like a radar with or without direction)

The screenshot in the quesition seems to be between 1 and 2 as it probably is based on limited information, but you still see the outline which could give away some information.

2. What can the player do?

Suppose you think someone is at coordinate XY, what can you do? Here are some typical choices:

Attacking

  1. You can attack him as if he is not cloaked
  2. You can attack him with AOA attacks/traps which uncloak him or not
  3. You can actively uncloak him and only attack him afterwards
  4. You cannot attack him at all

Moving

  1. As you start to move, you notice that the engine mysteriously takes you on a detour
  2. You start walking towards your goal normally, but when you reach the hidden character you move around him or stop
  3. You don't get blocked by the hidden character

If the route selection is normally done client-side

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Thanks for your input. I was planning on letting people 'bump' into invisible characters anyway, because that is something that the server can calculate and handle. The sound idea is neat, and changing sound in a subtle way (tension, think Jaws) would be cool but wouldn't that also be easily replaced with e.g. louder sound file or even a voice file saying SOME ONE CLOSE IS STEALTHED? \$\endgroup\$
    – Underflow
    Aug 4, 2016 at 13:04
  • 1
    \$\begingroup\$ Another idea along the line of 'a': A shimmer could appear randomly appear somewhere near the cloaked player, but not at their exact location. If the server just sends the position of the shimmer, the client can't really do much reverse engineering on that. In fact, even if the cloaked player was completely visible this would still function as a mechanic. \$\endgroup\$
    – Jezzamon
    Aug 4, 2016 at 13:10
  • 1
    \$\begingroup\$ @Jezzamon yes, some sort of 'displacement' mechanic would be cool, too. However, in the cloak situation that wouldn't work: I don't want to punish players that are on the lookout for shimmering; they would need to have the 'exact' location of the shimmering to aim e.g. skillshots. \$\endgroup\$
    – Underflow
    Aug 4, 2016 at 13:28
-1
\$\begingroup\$

The ripple effect could be done through shader code. You can disable texture usage in this mode so the simple texture change is no longer a problem.

In 3D, when model comes into play, you can still just change the shader to one that simulates refraction, using just model's surface, discarding the colour. Even when model is replaced somehow, the effect remains.

Modifying pre-compiled shader would be as hard as modifying game code and I think it is one level harder than some texture lookup within game files.

Improve this answer
\$\endgroup\$
6
  • 3
    \$\begingroup\$ You missed the actual question. It wasn't about how to create such a distortion effect technically. It was about how to give the client the information where to render it without giving it useful information it can expose to the player. \$\endgroup\$
    – Philipp
    Aug 4, 2016 at 7:45
  • 1
    \$\begingroup\$ Well, I address this: Which means that players that change the texture or model or even the game code itself could render the cloak mechanic useless. And I don't see why I missed the question whether there is some way to implement cloaking (with a 'shimmer', à la HotS), without having the issue that crafty players can modify the game (data) . A: It ads cloaking with shimmer, B: it is harder to modify than simple texture change. WHERE to actually render is another side. If the position is the only thing we need to apply ripple effect around, it should be the only data sent to player. \$\endgroup\$
    – Mars
    Aug 4, 2016 at 8:26
  • 2
    \$\begingroup\$ I have developed client side hacks in the past. The notion that it is harder to modify shaders is very, very misleading. Yes it stops the most basic possible form of attack, but anyone with decent Google-fu could figure it out in an afternoon. Now pit your game against a decent hacker and see how long it takes until they have fill on client side cheatsy goodness. \$\endgroup\$
    – user39686
    Aug 4, 2016 at 13:32
  • \$\begingroup\$ Copy-paste your comment to every answer here, as anything client-side can be exploited. I know it's not that hard to modify code (there are bots, hacks, mods in AAA games), but I find it easier to lookup semi-transparent texture in game files than to look for specific instructions of the shader ripple effect. Of course if the shader files are plain text and barely zipped, then even a child could break it. I just gave an answer, which can be combined with "less data passed to player" one to provide decent level of security.I really don't know what's wrong with it, as it provides actual solution \$\endgroup\$
    – Mars
    Aug 4, 2016 at 13:48
  • \$\begingroup\$ @Thebluefish in fairness, its because of this that developers moved away from spending resources attempting to stop cheating, and instead spent resources on very convoluted, obscure and well built methods of detecting cheats and outright banning offending players from their platforms... (obviously refer to systems such as Steam's VAC). \$\endgroup\$
    – James T
    Aug 5, 2016 at 7:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .