guest    Login  Signup

search 

home news about media forums community download
Forums . Development Blogs . Technical Blog #4 - Pro-Mod or Anti-Cheat

Development Blogs

Design and Technical Posts from the Development Team

Currently: 8 Topics, 40 Posts

Technical Blog #4 - Pro-Mod or Anti-Cheat

jeff
Lead Developer
Jen: M
As I begin implementing the new simulation server a key question arises: Where do we draw the line between allowing as much future expansion as possible and preventing players on multiplayer servers from cheating?

It is easy to say "an ideal solution allows maximum flexibility while making it impossible for players to cheat" but in practice these two are in some areas mutually exclusive. A mod that "removes tedium" for one set of players can easily be regarded as cheating by another.

To prevent cheating, the relevant design proverb is "never trust a client". This means that whatever information a game client sends to the server, the server treats it as an attempt to cheat. Taken to the extreme, this means the client cannot do anything without the server's permission. If a player wants to perform any action, it sends a request to the server, the server analyzes the request, might act on the request immediately if valid, and then lets the client know if the player is allowed to perform that action. It is very tedious to develop, and results in unresponsive gameplay due to network latency. This would be a "server authoritative" model.

On the opposite end, there are multiplayer games that operate without any server at all. Players simply perform actions and those actions are broadcast to all other players via direct connections. This is the "peer to peer" model, and preventing cheating with this model usually requires anti-cheat software that runs on the player's computer monitoring for suspicious software and network packets. These systems tend to be rather poor at times, as sometimes cheating can only be detected after the fact - after an invalid packet has been sent to the other players.

In reality most multiplayer games use a compromise approach between these two extremes. (For this post I am ignoring a few other models such as the use of authorization tokens, as they can only be used in limited situations.) The Antilia MMO alpha was around 90% server authoritative. For example when a player wanted to teleport a request was sent to the server, the server fetched a list of places the player was allowed to teleport to, ensured their selection was on that list, and if so would tell the game client to move the player. You simply could not get the game to teleport you anywhere that was not on your character's list. Those who played the alpha might recognize the delays in performing certain action as the server checking that the player has enough energy before telling the client "yes, you can do that".

There were places where these network delays were too detracting, and a compromise was reached. Players expect movement to feel responsive, and so as soon as you press 'move forward' the character begins to move, even without the server's permission. In this case the movement was really just an illusion - the client would still make a request to move to the server, and the server would determine if the distance covered over time was acceptable. (If you ever got disconnected after a lag spike while running that was likely the server deciding you were trying to cheat and simply kicking you off.) Likewise, if a player wanted to move an item in their inventory this was considered generally safe enough that the client could move things and they would immediately appear to have moved. A few seconds later the client would get an 'inventory update' packet that would confirm this new state of things.

Even with the authoritative model, exploits can still slip in, as illustrated by a cooking exploit discovered late in the alpha tests. Because foods were themselves considered ingredients it became possible with at least one recipe to repeatedly cook a food, amplifying the food's value and effect. (This was really a bad design on my part - I should never have used a cumulative approach to determining food values.) While the Antilia alpha had plenty of glitches and bugs, it's harder to notice what sort of bugs and exploits the alpha did not have. For example, the MMO server "pushed" information to players on a calculated need-to-know basis. The client never 'polled' or 'requested' things such as friends lists or information about the objects in a zone it just entered - the server would determine when to send all needed information. This added a computational burden to the server, and also made it difficult to extend.



While designing a new user interface where players can select a server to join the question came up of whether that would include a list of 'public servers'. My immediate response to this question was to say "no" for several reasons:
  • I believe a list of servers suggested by developers sends a message to new players that "we are aware of and approve of the multiplayer experience you will have here".
  • I want the development team to focus on making new content and improving upon the game, rather than moderating a list of approved servers.
  • A public server list would have to provide IP addresses of players, which may invite hacking, DDOS attacks, etc.
  • I personally only play multiplayer games with people I know and trust, which certainly influences my designs.

An architecture that makes the game easy to mod can in places introduce opportunities for those who would cheat. It is far simpler to expand upon a system where the client simply asks for information when it needs it and the server provides that information, rather than building predictive models for everything on the server. If players use mods that employ scripting, I will not be able to control how well those scripts are written such that they can't be used to cheat. For those reasons, I think it is best to set an expectation that players will be responsible for choosing who they play with, rather than assume that all servers - in all of the potentially expandable states - provide a cheat-free experience.

I would however like to know how the community feels on these decisions. Which is more important to you - that Antilia should be easy to mod or difficult for players to cheat?
Tuesday, June 14, 2016 9:16am
Jeff Leigh - Lead Developer - Right Brain Games
Thagrahn
Jen: 19
This is a very touchy area, to much server authority also leads to lag in play, but to much freedom to MOD leads to being able to build in cheats.

Exploiting MODs to quickly obtain certain gear would be considered cheating by some, but can also be beneficial if it is intended as starter gear for all players.

Basically, any level of MOD ability can lead to simple cheats, but it is up to the community to determine how far is to far. The focus on surviving was interesting, and should be something to consider for anyone making MOD content. Discussion of MODs prior to creation could help some, but also feel limiting to people that want to create MOD content.

Scripts will be easier to cheat with than sculpts, but you also need a good balance on server authority to make sure the abilities of scripts and sculpts are valid.

((Sculpts, for those that are wondering, are 3D assets created for the game. Which can include new bodies/races, enemies, and buildings.))

I don't think there is a perfect ratio for server authority, but 75% of game play should be validated.
Tuesday, June 14, 2016 11:52am
jeff
Lead Developer
Jen: M
Quote by Thagrahn:
I don't think there is a perfect ratio for server authority, but 75% of game play should be validated.


That's about where I was thinking - keep the authority checks for things that require energy, create inventory items, etc., but drop the extensive predictive algorithms that push data on a need-to-know basis and allow the client to do more general queries. Some data will still be quarantined off to only those with "permission".

An example I ran into last night: I can see legitimate use cases for the client being able to request the position of any character on the server - something the Antilia MMO could never allow. However, characters that are currently in any sort of 'stealth' state should not reply to that request, and the information should only provided if a skill is used to 'detect' them.
Tuesday, June 14, 2016 12:07pm
Jeff Leigh - Lead Developer - Right Brain Games
Noxious Skunk

Jen: 107
I feel like it should be the servers host choice to decide whether they want to allow cheats or not. Since the game isn't going to be an MMO anymore, it really shouldn't be too much of a problem if the server host purposely uses cheating mods on a server they decided to set up to play with their friends only. If the host doesn't want to have cheats or anything on their server, they can decide that too. Players wanting to join a server always have the choice to enter a server with cheats or not, and decide if they want to partake in getting free perks or materials on a whim, since it's ultimately their decision.

In the end, I'm more on supporting the pro-mod argument, since in the end, we're paying for an experience, and what kind of experience we decide to have, whether it be cheating or not, should be our own choice. Once we pay for the game, us players should be given the reigns on how we want to play the game, especially since it can be a single player experience.
Tuesday, June 14, 2016 9:57pm
WWWWWWWW
Jen: 47
If we go the peer-to-peer route (I'm all for it!), I am a firm believer in dropping the hammer on first time offenders e.g. Overwatch.

But, what defense would there be against a repeat offender?

I don't know much about networking. Would an official server be able to enforce something like a VAC ban that steam does? Would IP bans be effective?
Tuesday, June 14, 2016 10:46pm
Spyred

Jen: 76
For reasons already stated, I'm also on the for modding side of the argument.

As long as we stick with no publicly listed servers I'm fine with that.
Tuesday, June 14, 2016 11:10pm
jeff
Lead Developer
Jen: M
Thank you all for your responses, it sounds like we are about on the same page here. The responses on Facebook have been much more on the anti-cheat side, but I think that is because of the way I summarized the question on Facebook.

I think the best multiplayer experience will be to encourage those who want to run a server to do so with a "whitelist" of players that are allowed to join their server, rather than encourage open servers or public server lists. Even big companies with large programming teams struggle with the "cat and mouse" game of making their games hack-proof. While as stated above I will keep the more basic anti-cheat measures I implemented for Antilia, I would rather we as developers focus on making the game fun and easy to expand first and foremost. As someone that will likely run a server myself, I want to decide what mods are enabled on my server and what the game rules are.

I understand that will make it more difficult for players that are new to the community to experience the multiplayer side of things, as they will now have to find a group that runs a server and ask to be added. However, that also means the same is true of hackers, cheaters, griefers, and trolls. Multiplayer may be more difficult to get into for some players, but once you are on a server I think the game will be far more enjoyable - including for the people that run the servers, who can spend less time banning players and more time enjoying the game.
Wednesday, June 15, 2016 9:44am
Jeff Leigh - Lead Developer - Right Brain Games
Page: 1

You are not currently logged in. You must first log in to post a reply.
Frequently Asked Questions Development Team

Antilia - Copyright © 2017 right brain games