Should I even do this?

I'm in the process of making my online game. But I just came to the realization, that I may be wasting my time on things that probably don't matter in the long run.

Okay, without getting into too much I'll make the explanation simple.
My game is online. The players never (hurt) each other (PvE) only.

So should I even really consider any backend systems (realistically speaking).
Should I even care if players decide to cheat by just giving their selves gold, if the cheats will never effect the other players?


I'm just not wanting to waste my time with unnecessary stuff, but frankly these are the choices I need to make now being early in development.

I'm just realizing, should I really even care if players 'cheat' to get big bad great gear, if in fact that 'gear' will never effect the balance towards other players (E.G. - PvP).

Keep in mind these players can help fight NPC Enemies however. But again, will never effect balance between fighting other players and such.


I'm leaning more so to ignore all backend systems together and just build my game, I mean I do have EasyAntiCheat Toolkit or whatever it's called, so that should help somewhat though.

So what would you do?

 

Always perform at least some kind of validation on the backend. Or, at least design with mind about it.

People will ruin other people experience if you let them. They will find a way, trust me.
Giving themselves gold isn't really an issue. But speedhacks, data corruption cheats, other people gear alteration cheats etc will be an issue.

Imagine one person nuking a whole server? Yeah that will happen if you let it.
Or giving everybody on the server 99999999 gold will ruin the experience as well. Or setting gold to 0.

Cheaters tend to get more creative these days.

 

Appreciate your insight mate. Will take this under consideration.

 

Totally agree with VergilUa. If it's a multiplayer game, always validate user input...

 

Just FYI: Those "easy anti-cheat" solutions won't help as people could (and often do) just modify the network messages directly. All they do is obfuscate values in ram which makes it a little harder to hack; but won't stop a determined hacker anyway.

You should definitely validate the input you receive. Imagine your server(s) crashing because someone sends malformed network packets (on accident) from a hacked client while trying to cheat.

As for the actual cheating topic: Well if you think cheating won't matter then don't invest any time in trying to make it secure.

If you later decide you want to ban cheaters it is infinitely easier to simply ban by "heuristics" than implement actual anti-cheat measures. Sure, you won't catch everyone by simply running a script like "ban everyone who earned 100million gold in a 10min timeframe", but it will do the trick of keeping leaderboards clean.

 

The other side of the coin is to not waste time creating anti cheat systems for a game that is not being played. Cheats are a huge problem in big games like CS, Dota, PUBG, etc and the game developers spend a lot of time trying to create systems to detect or prevent cheats.

But if you spend a year doing that BEFORE you release your game you might end up wasting a year because if the game ends up not being played, then it wasn't worth it.

So just release without cheat protection. And if people start playing it, then start preventing cheats.

But yeah, keep in mind that you should design your system to allow for cheat prevention later on, so you don't have to refactor the entire game.

Example:
So your client should ask the server if it is allowed to do something, instead of doing it right away and then telling the server - and the server should just answer yes (Dont bother creating logic for checking if it should be allowed to that something). But after release you should start making that logic.

 

I'd say that it is far more important to focus on a the game itself, and making it as good as it possibly can be. Cheating can be dealt with once you have a successfull game.

 

How is the game multiplayer while cheating to get gold doesn't affect other players? Multiplayer games need some competitive component to them, or there is not much point to being multiplayer at all. If there is no fighting between players, you're going to need some metric for players to compare themselves against each other. If cheating does affect that metric, then cheating does impact other players.

For example, you could have a leaderboard for most NPC kills, total kills of some top level boss monster, total gold acquired, etc. Players are going to want something like that or they won't feel there is much point to progress in your multiplayer game.

That said, don't spend too much effort on cheat prevention now because cheat prevention doesn't matter until your game gets popular. If it never becomes popular then you've wasted your time. Just avoid obvious design choices that make the game prone to cheating (trusting client simulation, etc), and don't give yourself too much extra work if/when you work on anti-cheat later.

 

Borderlands is a good example of what happens when you do co-op with trusting the client too much. Whether that is a problem for you(Borderlands made a huge amount of money) is another story.

If you want persistent gameworld state shared by other players, allowing lots of client hacks would make that pretty much a no-go. Ie. compare Diablo 2 to Diablo 3, insecure client hosted model would never work for Diablo 3 and it had to be designed to take that into account from Day 1.

I've been looking into this lately and this is what I've concluded but would be interested if I am missing some approaches:

1) Client hosted server, obviously this will never be secure, users can just inject DLLs etc.(including the host in the case that you include server checking logic). This seems to be 90% of the premade networking solutions for Unity.

2) Server hosted Unity instance acting as host: This is similar to #1 but the host is a server unity instance instead of a player. I don't like it because unity instances are heavy processes and it is not economical, this won't scale very far before you start losing money(at least in my case where a "room" is 1-4 players, that's a lot of unity instances for a cheap game with only a small number of players(VPS are not free, it has to scale and still make money). If it was economical(I'm open to argument on this) this would seem to be the easiest way to have a secure game.

3) Server hosted relay server with authoritative logic: This is a variation off #1, in this model a player is still the host but the relay server(not hosted by a player) that all traffic goes through maintains "some" state and has "some" authoritative logic to prevent cheats. This is pretty good middle ground in my opinion but takes work. The relay server is not running a unity instance, so any game logic checks need to be coded outside of Unity. I think PUN allows you to do this and any of the developer hosted relay servers like TNet, Forge, etc. but it takes work as by default they will act as option #1 and simply pass messages without any cheat detection.

4) Good old client-server authoritative model. Server maintains all the important state and updates clients as needed. Still the most secure way and the way I have chosen. Surprisingly poor selection of premade solutions in Unity for this approach. Obviously all of the state and game logic will be need to be coded by the developer on the server but I believe there is an unfilled market here for a base authoritative server that you extend with your game logic easily, SmartFox etc. fall into this category. It's not trivial since you need to simulate the entire game outside of Unity, ie. navpaths, object bounding boxes, physics, etc.

 

I'm assuming it's a game intended for financial reward, so forgive me if I'm out of order. I am also harsh when it's a business subject so bear that in mind (nobody wants sweet talk when there is money on the line).

You're talking about things like validating inputs, using anti cheat measures, etc etc - this can only mean you intend an unproven product that isn't bankrolled, to have hundreds or thousands of concurrent players. That's never going to happen, ever.

The only way it can happen now is that you have a really strong publisher and they advertise like crazy for you. "But minecraft did it" was probably the start and end of that.

Your competition (and you do compete because it's online only) has billions. So you need to be thinking more about actually getting people than worrying about anything else at all.

Just release something, see if people nibble. Grow it? Involve people at the start, and they will help you grow it into something that could have a modest slice of pie. But that's not going to happen without a great game with it.

Cheaters come after, not before success.

 

I agree, I think relay server + authoritative game logic plugins(as needed) is a good incremental approach for most room based games. It won't stop people from giving themselves gold or items most likely but you could limit/ban/remove the users who suddenly have "Uzi Machine Gun level 9000" and try to use it or are speed hacking.

One of the problems I see is I don't really like most of the relay server options out there. Most of them seem to be written in C# and I really don't want to run that on a linux VPS with Mono, or they are paid services like PUN which has other attributes I'm not a fan of.