31–40 of 52 posts
Earlier quoted context omitted.
Javascript can be obfuscated too. What is the difference?
Well, someone went to the trouble of writing a Rust binary just to hide the game code, when they could have used standard JS obfuscation instead. This suggests to me that WASM has some properties that make reverse-engeneering harder than obfuscated JS could do alone. This would give some validity to the fears of WASM becoming the "new Flash" that were voiced when it was still in development.
Alas, we killed Flash. It's undeniable that that technology enabled a Cambrian explosion of creativity.
Then Adobe bought it and duct-taped it to the Creative Suite and switched to a subscription-based business model.
It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of chea…
Hard to resist that nagging thought, though.
It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of chea…
that does kinda feel like premature optimisation. First make a game. Second make a game that people want to play. Third make a game that people want to hack. Then maybe look at stopping them from doing that. Hard to resist that nagging thought, though.
If you build a multiplayer game then come back to "deal with cheaters" only a few months before launch (or heaven forbid, after launch) you're probably going to end up taking the easy route by using invasion ~~spyware~~ DRM solutions, which don't stop cheaters once it's broken. To contrast, designing the game around cheaters means you might actually implement sane networking design, such as nearly everything being server-authoritative, aka. "never trust the client". If your client is broken in to, the best your cheaters can do is script the game (scripting cheats are currently the only ones available for Dota2 and probably League of Legends) or see a small amount of information that's otherwise unknown (for dota 2 you can see which enemy illusions are fake, for example).
Of course this approach can be taken too far, eg. in Call of Duty: Modern Warfare (the new one) sometimes your camera positioning can lag due to packet loss; this probably stops some aimbots but things like camera orientation probably shouldn't be handled server-side.
It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of chea…
Earlier quoted context omitted.
Javascript can be obfuscated too. What is the difference?
Well, someone went to the trouble of writing a Rust binary just to hide the game code, when they could have used standard JS obfuscation instead. This suggests to me that WASM has some properties that make reverse-engeneering harder than obfuscated JS could do alone. This would give some validity to the fears of WASM becoming the "new Flash" that were voiced when it was still in development.
> So I went back to the debugger and placed some breakpoints around where the WebAssembly module is loaded, realizing that its only purpose is to deobfuscate the JavaScript that eventually makes it into that "SOURCE" pseudo-file I saw earlier. [...] > So… the WebAssembly is essentially generating JavaScript on-the-fly. Of course, all renditions of the code do the same thing, but the variable names are changing. [...]…
JavaScript has it covered pretty well. http://www.jsfuck.com/
It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of chea…
If it's a single player game, then who cares?
Earlier quoted context omitted.
I wouldn't have thought to look there. I'm sure there's many ex-flash devs who would be happy to check it out if they knew.
Any ideas on how best to reach them?
There's also a handful of forums, gamedev.net tigsource and others.
StackOverflow is a common place to search for answers, if you can find questions asked about "what can I use instead of flash" without coming across as an advertisement.