So many intriguing ways to do this...
Well first of all, with 60 variables, even if each variable has only two possible values, there are over one quintillion possible combinations.
So you'll have to split up the system into multiple password entries. I'm guessing you were planning this? Giving the player, say, 10 passwords means that each password will deal with 64 possibilities (still assuming each variable has only 2 possible values), a lot more manageable. This also means that you could assign longer strings of letters/numbers for each password, making them less guessable (instead of spitting out a sequence of 60 individual values, which the player could easily start guessing at). Have each of the 64 possibilities correspond to a unique password. For example, a Death Count of 12 for Password A will always correspond to 1243 (or whatever). You could even make this correspondence the same for each of the 10 passwords and drastically reduce the number of triggers.
One possibility, one which requires a lot more triggers but makes it a lot less guessable, is to have multiple password "sets". In this idea, in addition to the regular 10 passwords, you give the player an initial "keycode". The player has no idea that this keycode tells the triggers which "set" to use when interpreting the password. Let's say you had 2 sets (enough to throw the player off even more) and passwords A - J. Under Set 1, if the player enters 1111 for Password A, this may mean the player starts off with a zealot, 100 minerals, a forge, a drone, an overlord, and a ghost (for example, and assuming each variable has only 2 possible values). Under Set 2, entering the same password might mean the player starts off with a marine, 200 minerals, a forge, a drone, a dropship, and a ghost. Of course, having just two sets will require twice the number of triggers.
An easier way of doing this, which would require fewer triggers, would be to have a trigger that adds a random number to the death count that holds each of the 10 passwords (when generating the passwords); and a corresponding trigger which subtracts the same amount (when the player enters the passwords). Which number gets added/subtracted depends on which "set" is used -- indicated by the initial "keycode", a special code at the beginning of the password given to the player. Again, the other 10 passwords may each contain very specific information, but the player will have no idea that the first password is actually an anti-guessing mechanism.
Let's take an example:
Password given to player: 1212 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234
The player enters this password. The triggers first deal with the first chunk. They read, 1212. Okay. That corresponds to a death count value of 15 (for example). Since it's the first thing we received, we know it's telling us which numbers to subtract. Let's look up possibility 15 (the possibility randomly assigned when the password was generated). Possibility 15 tells us to subtract 9 from each of the passwords' death counts.
Okay. First the triggers translate the remaining 10 passwords into the corresponding Possibility Death Counts. Then 9 is subtracted from each, giving the ACTUAL Possibility Death Counts. This is then acted upon (giving the player whatever units or whatever the variables intend).
What's great about this method is that having a four-digit "keycode" would give you tons of possibilities for numbers to add/subtract, and unless the player was extremely dedicated, they'd never figure it out. They'd have to memorize entire passwords to take advantage of it. You could even have a meta-keycode, which tells the trigger system which way to interpret the keycode. The more keycodes you have, the more randomization is possible. It's a lot easier to set up triggers for multiple ways to randomize than for multiple ways to interpret.
Another very simple way to randomize is to mix up the order of the 10 passwords. Give the player a keycode before the 10 passwords. This keycode remembers how the passwords are mixed up, so when the player enters that keycode, the trigger system will rearrange itself to ask for the passwords in the proper order.
You could even have a meta-order keycode. A keycode that randomizes which way to interpret the next keycode. Again, the more meta-information there is, the harder it is to crack.
The problem with having so many variables is the length of the passwords. This is especially a problem with telling the player the password they've been assigned, since a Display Text Message will always show the same thing, you can't put multiple messages on one line. If you can arrange the password system so each password it gives out on each line is longer, great, but that requires a lot more triggers. On the other hand, more randomization will require more lines of text, since each separate password element requires its own Display Text Message action. Shorter lines of text, sure, but still more.
Also, all my numbers and estimates assume that each variable has only 2 possible values. Triggerwise, bigger amounts of possible values become easier to deal with if you have MORE password elements -- giving the player 60 separate password letters to remember will take a LOT less triggers than giving him, say, 10 separate passwords to remember... but it will also be a lot easier to crack/guess at, and probably piss the player off, making him sit there writing down 60 digits, trying not to lose track of which line he's copying...
Alright, I hope all this was clear. If it wasn't, let me know and I'll say it a lot simpler. Just wanted to get the gist of it down.
Post has been edited 4 time(s), last time on Mar 31 2008, 12:04 pm by razorsnail.
None.