New Game Testing Method - Decoded Passwords


#1

I assume here that you are familiar with the *show_password and *restore_game commands in choicescript, and the ability to restore/save games by copying out and repasting an encoded (or obfuscated) password.

After a suggestion from @Reaperoa - Implying that an deobsfucated password might be beneficial to games developers in order to test their game, I took a look and came up with a simple edit that would allow just that.

What will this do?
This will present your players (or you, if it’s a test build) with a raw, unobsfucated password that’ll look much more legible.

It’ll look something like a longer version this (taken from my game, ~ Terminal)

fname":"Fin","lname":"","alias":"Guardia n","time":true,"party":false,"attire":"n othing","alice_number":false,"alice":"Al ice","fin":"Fin",
How do I do it?
In the scene.js file:

Comment out this line:
http://gyazo.com/d428fb563a935a34069717fddc6f2afd.png?1353793324

And add this line:
http://gyazo.com/6baf90a2e54d4eff296b3eafdfc12ce2.png?1353793290

That’s all there is to it (don’t forget to undo this on public links though).

Why is this useful?
All the information about the games state at the point of save from variable values to the current scene and line number are all part of the password data. Obsfucated you have no hope in hell of changing these values, originally this was the only way to save a COG game, so it’s likely in place primarily to prevent cheating.

That same method that would allow us to “cheat” would also allow us to ‘test’.
Imagine that someone reported a bug to you, they told you it happened in ACT4.txt of your game, around halfway through it and you know that act is around 500 lines long.

They also give you some information regarding what choices they’ve made (and what values they’re variables will hold).

With an unobsfucated password it’s a two minute job to find those variables and parameters in the list, change their values and load a near identical copy of the bug reporter’s game and see the bug/problem first hand.

You can essentially change any value (or number of values) related to a saved game and immediately load that instance.

If that’s not considered useful, I don’t know what is!

How does this work?
It’s incredibly simple, there’s no genius behind this (accept maybe @Reaperoa for the idea!).
We just comment out the line of code that obfuscates the password - so the one that is provided is unobsfucated.
And on the return load, we add an extra line to reencode the password before it’s read and uncoded again.

The last one may seem a little silly but it’s a damn sight easier than changing the code to interpret the legible code!

Can’t People Use This to Cheat?
Kind of. If they fancy downloading all your files and editing your game’s scene.js file before playing it sure.
But at that point wouldn’t it be just as easy to edit the .txt files themselves and ‘cheat’ that way?

I figure most people also save via the cog/server database system now, so this really shouldn’t prove too much of a problem as a cheat-device but will do wonders for testing games.

Anyway, you’re only cheating yourself aren’t you? And due to the nature of CS games you might actually break a lot of games if you cheat without thinking.


#2

@CJW Initially, when I thought about how this was done, I thought I had to actually change the obfuscator to obfuscate every character into the same one…and you just comment one line and add another. You make hard stuff seem easy when it comes to JavaScript :slight_smile:


#3

No, no. There’s nothing smart or fantastic here, we just remove the obfuscation entirely from the save end and add it to the load end (purely so we don’t have to modify the load to ‘analyse’ the non-obsfucated version).

Someone else would have undoubtedly stumbled across this eventually, still as simple as it is, it’s incredibly useful. Just goes to show doesn’t it? ^^