I've been looking into this a good bit lately, but I haven't been able to come up with anything. I have, however, found a few leads and observations that other people might be able to do something with.
First off, and I'll admit finding this was pretty lucky, is that this code appears to have something to do with base 64 encoding (see
http://www.cotse.com/CIE/RFC/2065/56.htm). Basically, you take the ASCII values (65 = A, 66 = B, 97 = a, 98 =b, etc) of the letters in your message and convert them to eight-digit binary strings. Then you string all these binary strings into one long string and divide it into sets of 6 digits. You convert these sets of 6 into regular numbers and then change those numbers into uppercase and lowercase letters,
pluses, and
slashes according to the table at the provided link. Since Lun's code has both pluses and slashes, I think this is probably a valid method of approach to decoding.
The problem is that when you put this into a decoder (such as
http://makcoder.sourceforge.net/demo/base64.php), it doesn't yield any sort of intelligible result.
Since base 64 uses sets of 8 bytes and converts them into sets of 6 bytes, = signs are appended to the end of encoded strings to even out anything that doesn't evenly divide. There's also always a single = sign at the end just because. I hypothesize that the = sign in Lun's code correlates to the = sign that occurs after base 64 encoded stuff.
There are two similarities between the long and short codes. The first is that they both have four characters that appear after the equals sign. My guess is that this is some sort of key (that's probably encrypted itself). The second similarity is that each code has the same eight initial characters. Base 64 encoding seems to work best in sets of eight; this may have something to do with it.
Moving into the realm of pure hypothesis, I'd guess that the A = 0, B = 1 chart in the above link is not the chart that Lun uses. Perhaps he starts at something else, like L = 0 or f = 0. I'd also hypothesize that the four characters at the end may have something to do with some sort of modification on the key code, and that this modification is applied after every eight characters.
If the four letters were a regular key of some sort that directly translates to the encryption process, then there's almost no way that the first eight characters of each version would be the same. That's why I think it's some sort of modification that is applied after every 8 letters.
And I just noticed that the first 9 letters are the same, so maybe the differences between the versions can be attributed to the fact that they're different versions. But if that were true, then the last four letters would have to be something like "Lun" since they're separated from the rest of the message. They're both different, though, so that can't be right. And the last four letters have to serve SOME purpose.
I'd bet that the key is hidden somewhere else in the game's code... but anyway, that's about as far as I can go. Hopefully someone else will have a stroke of genius that I couldn't come up with.