…which won’t stop a determined user. Nothing will.
They can decompile the zblorb, too, if they want.
The only way to truly keep the player from looking at how a script works is to run it on the server and call it from the browser, but that’s not possible if the game is hosted on Dropbox.
That said, a casual player is unlikely to decompile a zblorb or even know what JavaScript means so going to great lengths to hide code is usually unnecessary. It’s of course a different thing if it’s something like a competition where it’s important that cheating is made impossible.
Thank you all for the feedback.
The adventures that I write actually are for competition. Unfortunately, we do have some fairly skilled programmers in the community and they do seem to like a challenge. I’m quite sure some of them would try “breaking” the code, if for no other reason that to show that they could.
It appears that coding a algorithm in Inform7, such that it is “compiled” into the zblorb, is likely about the best one can do without going the server route. At least it means that they need to first understand how to decompile the code and even then, it doesn’t necessarily reverse compile into something very pretty and easy to understand. The real “danger” with someone decompiling the code is that the source might contain explicit strings of critical text/hints. On other platforms; to preclude doing a scan for such strings, I’ve employed realtime decoding of previously enciphered strings of key text, rather than state them explicitly within the source. Using an algorithmic-based, rather than a keyword-based, cipher usually works best and is a little less obvious.
Splitting the critical algorithms that do real-time decoding into segments scattered throughout the source might be another tactic I could employ to make “cheating” even more difficult. I suppose that obfuscation, as noted in the comments, is also another technique that could be useful.
The Z-machine already uses a strange encoding for strings, so they won’t appear if someone hex-edits the file. You can apply this protection to the JavaScript as well with something like this:
function addScript(x){ document.write("<script>"+x+"</script>"); }Then take your whole JavaScript file, escape quotes and backslashes and such, and insert it into your game file as a string. Now…
eval "addScript('[javascript file]');"Sure, but that particular code wouldn’t work: calling document.write() at that point would wipe out the page contents. Why not just ‘eval “[javascript file]”’? (Or in Vorple terms, ‘execute JavaScript command “[javascript file]”’.)
In any case I wouldn’t recommend it. It doesn’t take much effort to google for the story file’s format and find the decompiling tools in the IF archive. Unless there’s a compelling reason to use Dropbox, the best solution would be to get a free host (not very hard to find) and put the secret algorithms server-side.
Draconis and Juhana;
I’m going to have to think this one through a bit.
I know I have to eventually go the website route, but that may be more than I can handle at the moment.