How to prevent manipulation by console commands?

[Zampano]

Hi again,

I can't really find much about it, but isn't it right that everyone can manipulate variables and call functions of my game via console and therefore cheat very easily? Is there a general way to avoid that ? Because that would be horrible

[rich]

You can obfuscate the code to make it a lot harder to casually mess with vars, but it doesn't prevent it outright - nothing can.

[Zampano]

But doesn't that essentially mean it's impossible to create a competitive game that isn't incredibly easy to cheat in?

[icp]

You could also wrap your whole game inside an anonymous function.

[Nesh108]

@Zampano, why would that make you say that? If the game is fully on the client side then yeah but again, how could a game like that be competitive? If not, then design your architecture to absolutely never trust the input from the client and simplify it. See the client interface as just a way for them to send you commands, no major logic running there. 

[Zampano]

@Nesh108

Maybe I'm just too nooby right now, but if I got a player variable and that player has a health variable, I can just go to the console and do player.health = 100. Maybe I'm making some major mistakes here?

[Nesh108]

@Zampano, no major mistake. If the cheating player does that, the interface will indeed show 100HP, even if he has 1HP only.

Now, if they get hit once more, they would die, regardless of what they locally have set. That's because the server is what tells the player whether he is dead or not.

[rich]

For multiplayer games, the clients are 'dumb' and the server is the source of authority on all player vars, etc.

The client should never tell the server "Hey, I've got 100HP", the server should do and know everything.

[Zampano]

Sounds good, but how do I handle it then in the code?
I've got a test file on my server and it doesn't seem to behave like that:

http://media.pixelect.de/SE/t_020617/

You can boost the player by clicking. The player has a certain boost capacity and will fall down if it's used up and have a cooldown. Now if you type player.boost_max = 999999999999 to the console, you can stay in the air like forever...

[jpdev]

Zampano, all the tips from rich and nesh108 only cover multiplayer games where there is server that manages everything.

What this means is that the Javascript Part (the Phaser Game) that is running in the browser has to connect to a program running on a server and act only as the client. (Such a connection could be made via websocket or continues http request etc.) The server controls the game and only tells the clients what to display and the clients tell the server what the player wants to do. This is much more work than a normal web single player game.

There is no way to stop players in single player client side javascript games from cheating.

[rich]

There are lots (and lots) of books and tutorials covering this subject. Time to get Googling and have a read imho.

The Phaser aspect is irrelevant at the moment, what you need right now is to get the basics down and understand how and what the client and server should be asking of each other.

[Zampano]

Okay, I get it... Thank you for clearing that up, guys

I'll have a look around. Any specific recommendations for a single-player type game?

[Zampano]

I was able to get a quick overview about the topic and I can work with that. However, due to the concept of my game, an online singleplayer game, it's hard to find specific info on certain aspects. Maybe you've got some more clues for me to go on?

- How would I handle the clients? Would it be better to have the clients handled in one game instance, like in multiplayer games or would I want to set them up in their own instances? Especially with larger numbers of players, I can not really tell, since everything I'm reading seems to handle realtime multiplayer stuff.

- I would need to handle all physics and collisions on the server, right? That would mean I can't rely on the Phaser physics and would need to write my own physics since it doesn't seem to be convenient to have phaser run on the server end, right?

[rich]

Either you're making a multiplayer game, or a single-player game, which is it?

If it's a single player game, then why do you care if someone cheats? They're only ruining it for themselves.

[Zampano]

It's a single-player game with highscores and events and such.

[rich]

I think you're over-complicating it for yourself, but again there are quite a few resources of how to (try to) prevent highscore table hacking and the like.

Personally, I'd just build it and worry about it if it becomes an actual issue.

[Zampano]

Still, would it in any way be feasible or realistic to have the server do all of the (quite simple) physics or would that be plain impractical as soon as there is a bigger number of players at the same time?

I'm thankful for the advice but at this point I can't really decide if it is worth pursuing further without such information.

[samme]

Client–server games are a lot more complicated, but it's possible and people do it. Just remember that the hardest part of making a game is finishing it.

[Skeptron]

If you want to back up your client game by server-side verification, it will at the very least double your development time. At the very least. Like @rich said, if your game is client-side only don't bother.

[pixelburp]

There's no way to completely block the JS code from the User on the client-side, however there are a few ways to made it harder for them:

• Uglify the JS as much as possible, so inspecting the code is (close to) meaningless. IIRC you can even uglify the 'top level' so namespaces are obscured. Someone could still use a 'beautifier' to reformat it all, but with no human-readable var names, comments, etc. it'd be an exercise in patience just to work out how your game works. Honestly if you're publishing a game this is the very least  you should do to 'protect' the code.
• None / little of your code should be publicly accessible from the console anyway. If possible, declare your new Phaser.Game() as a private instance somewhere, that makes it harder for a curious User to inspect the game's current state from the console. 
  
  IMO it's good practise anyway to make sure you don't extend the window/document object, so it's a good habit to get into. @Zampano just quickly looking at your game, you've declared 'player' as a global variable within Game.js - this is why it's available in the console.
  
  Maybe you should think about wrapping your .js files with anonymous functions so that all the code within is 'private'. That causes its own problems however, as you still need to expose things like your 'x_player' class globally (or through something like NodeJS imports), so the main Game code can access it later.