3 ms·
Browsers run web workers in sandboxes and even normal debuggers built into browsers have no visibility into them; this means fiddling around at the JavaScript c
by willvarfar 13y ago
Browsers run web workers in sandboxes and even normal debuggers built into browsers have no visibility into them; this means fiddling around at the JavaScript console is blind of any state you have in them e.g. a procedurally generated world.
A determined attacker can debug the browser itself, or try and rewrite your app to not use web workers, of course... Its just a speedbump. Its still client side.
I use them - and try and work out how to debug them - for performance smoothness reasons though. They are worth more for that imo and anti cheating is very much a secondary thing.
Me getting down voted elsewhere for this opinion this week: http://www.reddit.com/r/programming/comments/1lnnvm/making_an_indie_desktop_game_part_i/cc10og6 http://www.reddit.com/r/programming/comments/1lnnvm/making_a...
- brianpgordon 13y agoYou can still use traditional debugging tools to change values (score, etc) in memory directly. http://en.wikipedia.org/wiki/Cheat_Engine http://en.wikipedia.org/wiki/Cheat_Engine
- thorum 13y agoI wonder if Firebug & other tools will eventually support debugging web workers, making this usefulness against cheating a temporary thing.
- willvarfar 13y agoYeah they soon will. Chrome is slightly ahead already. I wish I hadn't said it noe; it was on the top of my mind, was all. The much maligned web sockets are actually useful for keeping the game loop light; I even generate meshes in them.