| 11-29-2011, 06:27 PM | #1 |
Ok first we need alphanumeric base, standard one is this: ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 But I don't like it because it has 36 digits, I prefer binary, so lets remove 4 symbols: ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 => ABCDEFGHJKLMNPQRSTUVWXYZ23456789 The reason I removed those: 1 is easy to mix with I 0 is easy to mix with O This way there will be no mistyping problems. Ok so we now have a nice 5-bit code (32 = 2^5) If there are maximum of 32 permanent items in game we can now save 6 slot hero inventory with 6 codes, for example: 2G7-JJ8 Two more codes for hero level and one for parity check and we are done. We have a save/load code in most easiest to remember 3x3 format. C97-BB6-4AS =================================================== Ok so my question is this: Why I often see idiotic stuff in ORPG games like these: 3H0OY-HNJIW-YUI1H-7SJEV-PWL5J-IOP4S ??? |
| 11-29-2011, 08:27 PM | #2 | |
Oh, if Nestharus sees this there'll be trouble. Quote:
|
| 11-29-2011, 09:46 PM | #3 | |
Quote:
Nestharus is just using a lot of mathematics to do a simple thing: reduce code size for unused inventory slots. For example if hero has items only in 2 slots than 4 slots have code value zero: C97-B40-000 so he can just display the short version to the player: C97-B4 It is just most basic compression really. |
| 11-30-2011, 04:00 AM | #4 |
Well, if people are going for compression, then yes it can be very small. However, often people want to save other things, like experience, abilities, and other random data. (like position and whatnot) Of course, the logical argument would be that half of those savings aren't needed, but obviously people will do it anyway. xD The reason why Nes has to use so much math and conversions is because he is trying to systemize something that is often more map-specific. In doing so, he has to make sure there is a proper balance in security, speed, and compression, which is annoying when one is trying to keep the API friendly enough. :P ... but that is a bit off-topic. Overall, the reason why some people make such long codes is usually because: 1) Illogical reductions (ex: compressing object id's instead of using catalogues) 2) Storage of extra data (ex: position/hero name) 3) Security (ex: adding a player's name into the code) |
| 11-30-2011, 04:19 AM | #5 |
I have always felt that save/load codes should be shorter. I thought that it couldn't be helped though, since I remember Vexorian making a save/load system that gave items different sets of data that could be recorded. For security measures, of course. |
| 11-30-2011, 07:27 AM | #6 | |
Quote:
Code is simply colored with user name (XOR-ed, Modulo multiplied, or something else) And hero position does not need to be precise. For example (-3451.7 , 7343.8) could be rounded to multiples of 64 (3456, 7296) without anyone noticing. This saves 12 bits! Almost 3 letters. |
| 11-30-2011, 09:32 AM | #7 | |
Quote:
The trick however is to make it reasonably difficult for users to reverse-engineer your password generation algorithm. As long as individual items directly correspond with individual characters, the code is not too difficult to crack by saving a bunch of similar heroes and comparing the results. To make sure that the code is completely different for even small changes in input parameters, you need to do at least some sort of Nestharus-grade mathemagics. You may think that a 9-character code is short enough, but you are storing hardly any data in it. As has been already pointed out, you're missing experience, position, abilities and quest status, you are limited to only 32 different storable items in only 6 slots and can't store item charges. Sure, for some maps what you store is enough, but for others there's all these things I listed and more and your approach would end up generating the same 30 character code you object to in your first post. |
| 11-30-2011, 12:26 PM | #8 | |
Cracking save/load codes is a breeze. Viewing a rather readable (more readable than Nestharus' code for sure) version of the war3map.j is very easy, even if the names had previously been shortened - and that allows you to generate your "own" code without any fuss. I am all against those codes, but that's just me. Quote:
|
| 11-30-2011, 01:27 PM | #9 | |
Quote:
Didn't know about this, could be very useful for debugging, link please. |
| 11-30-2011, 01:36 PM | #10 |
Here. You could also just colourise your code before you print it out. Then you can use upper/lower case without worrying about Il1 mix ups. |
| 11-30-2011, 01:45 PM | #11 |
Tnx for link. It really is not worth it to use lowercase letters. It is just one more bit of information per symbol. It is easier to add one or even two more symbols to your code than to have people type upper and lower case. The whole point is to make a code that can be easily remembered. |
| 11-30-2011, 09:26 PM | #12 |
Okay, so the point is to make a code that can be easily remembered. Well, there's no point in many of the arguments above, then. We need long strings of code, because we were talking about maps that need to store lots of data. Namely RPG-like maps. If we have a map like Elimination Tournament where the only thing someone would need to keep track of is their score with their name attached to it (plus maybe a few extra things for security), then of course the save code will be small. There's not as much data that needs to be saved. But everyone knows these two points, already. This discussion doesn't seem to be getting anywhere. |
| 12-01-2011, 07:05 AM | #13 |
May I just add that storing lot of data is not an excuse to have long codes when data is as much correlated like in rpg games. For example if you need to save heroes STR/AGI/INT you don't have to store values like 513/345/678 because heroes stats depends heavily on hero level. In fact if there are no tomes in the game the level and hero type is all you need to determine str/agi/int And if there are you just store deltas from expected values for a hero of that level: +12/-7/+5 Same can be done with items, in fact most RPG games have level requirement for items, so more optimizations. A little math can go a long way... |
| 12-02-2011, 08:02 PM | #14 |
You're right; that's how I would code the save/load codes in my map, too. Since a hero's stats is (mostly) dependent on the hero's level, all you'd need to save is the level of the hero and any added stats that they've grabbed. Thinking of ways to minimize or making save/load codes as short as possible is a better way to phrase it. It's a big difference than saying "codes get long and tedious, make them short". |
