A few of my old Wc3 maps used custom save/load systems for online play. The problem is, security wasn't exactly the best. Even with a near-impossible to crack save/load system, someone would eventually figure out the coding and before long, everyone would be creating their own heroes.
In SC2, the coding might be a little harder for someone to crack or figure out, but that doesn't change the fact that a conventional string based save/load system is still a pain to code, especially when you want to include exact experience/individual stats.
So now we have banks. I'm unsure exactly whether or not they'll save to the PC when playing online (as Wc3 cache files would not save when playing on b.net), but they are extremely unprotected. Anyone can open them right up and edit anything to their liking.
So in this lies the problem. How can you create a save/load system that can save several different multiple digit variables and still prevent users from manipulating their characters to their liking? It might be possible to put fail-safe triggers in when loading a hero so that unless it passes a set of checks (such as having a certain unit below the minimum level to actually obtain that unit.. etc) it won't load correctly, but that can only go so far.
So does ANYONE have any idea as to how we can create a more fool-proof save/load system for b.net play? There MUST be SOME improvement over Wc3 in this area.
Problem is, its basically like doing BOTH versions of the save/load system though. You still have to configure an entire string-based system and THEN save it to a file instead of having them write it out.
Could it work? Absolutely, but you still have to go through all of the trouble. Are we even sure that bank files can be saved while online yet?
Encrypting a string isn't really fun. You have to sort all of the values you want to save out into substrings, and then change each digit to a different letter/number and scramble them throughout the final string. When loading you have to pick out each digit for each integer, convert them back to the actual digit, and then set hero stats/values accordingly.
Its not really difficult, but the coding can take hours for each the save and the load for a properly encrypted string.
I remember an old Wc3 system that converted the values to hexadecimal and then to binary before flopping around the digits. This would be EXCELLENT if someone could code it, but alas I don't see that happening anytime soon.
Seems save/load encryption isn't going to get any easier.
Using Banks while playing on Battle.net, umm.. well.. I think I'm going to ask some people for a test in a few hours.
Anyways, you seem to forget that there are existing and working encryption algorithms and that we are able to use Galaxy, which is at least C-alike.
I'm quite sure, that an implementation wouldn't be too hard.
I actually wanted to create a library but didn't have enough time... :x Maybe I'll find some this week.
Then the community has another goal to work towards. With the sheer scale of the project I'm undertaking, I don't have loads of time to try and pioneer all of my own workings. Thankfully thats one of the benefits of Blizzard having such huge mapmaking communities among their games. So many people able to work towards so many goals simultaneously.
It can wait until someone is able to successfully code a working encryption algorithm and others learn to adapt. I'm not extremely adept in coding C, so I've got a bit to go before I can start doing the more complicated workings in Galaxy. Until then, I've never had a problem figuring things out in GUI, and the current editor makes the GUI much capable than ever before.
Edit: I was also worried about banks during b.net play. Caches didn't work, but nobody has been able to test Banks up to this point. Blizzard hasn't really specified anything either.
Correct me if I'm wrong, but I heard that "banks" will be stored over Battle.NET, on Blizzard's own servers, linked to your account. Then you wouldn't have to worry about encryption at all.
Quote from ElementOfWater:
Correct me if I'm wrong, but I heard that "banks" will be stored over Battle.NET, on Blizzard's own servers, linked to your account. Then you wouldn't have to worry about encryption at all.
Where did you hear that? At least during normal playing the banks are stored on your own system..
Anyway encryption is a MUST HAVE. Even an easy and quick encryption can already be safe enough to be completely secure (unless the NSA wants to hack your code..)
The problem is that Blizzard has to find a way to lock maps so that no others can open it and view the map script. Because, no matter how good the encryption, if you can see the source code then you can circumvent any encryption without much hassle.
Banks aren't very large. Even if you store virtually all of the information you could ever need for a map/hero, I couldn't see it going above 5kb, 10 at the absolute maximum (and you'd need to store a LOT of info for 10kb.)
With just 1kb, you can store Level, Experience, abilities, levels of abilities, type of unit, name of b.net account, location of hero, all items, and lets just say 10 other variables for quests.
So lets take the 'average' 1kb (I honestly expect the average bank for a hero save to be 500b). Multiply that by 10 million (to keep track of say.. 1 million custom mappers each having 10 banks for hero saves.
1kb x 10 million = 10Gb. You can get a 10Gb thumb drive at Walmart for $16. Even at 100Gb, or even 1TB (that would be 1 billiion 1kb bank files... which would never happen), Blizzard wouldn't break a sweat storing banks online. I've got a 4Tb Raid drive on my PS3 that cost me a whopping $300... less than pocket change for Blizzard.
However, I highly doubt they would ever do such a thing. It would make saving/loading a nightmare if you couldn't easily access at least the name of the file.
Edit: Btw, Blizzard has stated that the publish function will have a built-in map protection feature that would make it near impossible for others to rummage through your map scripts. This would easily deter those who want to view the script for their own benefit. Hopefully this means better and more balanced customs on b.net
Thats fairly easily avoided though. If a map has hundreds of incoming banks per second, they can just blacklist the IP address they are coming from (which will be the game host).
Technically someone could make a map that purposely bombards the servers with banks, and Blizzard knows that. Just another reason I doubt they will host banks on their servers.
One word. Encryption. (Basically you would want to save everything as an
encrypted string.)
How would encryption solve this aside from severely obfuscating the string or data bank? The key you use to encrypt the data is either embedded in your map or generated off of some user-accessible data available every time a given player loads the map. The player just needs to find the algorithm and key in order to reverse it.
Certainly raises the bar for cracking load/save systems, but nothing foolproof.
Thats fairly easily avoided though. If a map has hundreds of incoming
banks per second, they can just blacklist the IP address they are coming
from (which will be the game host).
Technically someone could make a map that purposely bombards the servers
with banks, and Blizzard knows that. Just another reason I doubt they
will host banks on their servers.
If they end up storing the banks server side, I bet it's only saved when you exit the map (and cached in memory/on disk in the meantime)
How would encryption solve this aside from severely obfuscating the string or data bank? The key you use to encrypt the data is either embedded in your map or generated off of some user-accessible data available every time a given player loads the map. The player just needs to find the algorithm and key in order to reverse it.
Nothing will ever be fully foolproof... but encryption makes it more foolproof. And since one wants to have as less fools as possible, encryption seems to be the best way.
Thats fairly easily avoided though. If a map has hundreds of incoming banks per second, they can just blacklist the IP address they are coming from (which will be the game host).
Poor player knowing nothing about the map and not being able to use any other saving map in an effective way. :P
I tried to save several 10000s of data entries in a bank and it works fine. Within a second I've stored 8 Megabyte of data in that bank!
Now that's a *little* bit more than 1 kb.
And honestly I can already think of (non-abusive) ideas to store 20-50 kb of data in a bank.. You could even have the players have biographies :D
And it's not really the storage that'd be the problem for Blizzard, but the additional traffic. Files would be sent/received all the time which would probably impact battlenet latency.
And on blizzcon (or whereever) they said there'd be a way to store information on the players' computers. They didn't mention plans to store this data online.
I highly doubt we'll be able to store them on Blizzard servers.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
A few of my old Wc3 maps used custom save/load systems for online play. The problem is, security wasn't exactly the best. Even with a near-impossible to crack save/load system, someone would eventually figure out the coding and before long, everyone would be creating their own heroes.
In SC2, the coding might be a little harder for someone to crack or figure out, but that doesn't change the fact that a conventional string based save/load system is still a pain to code, especially when you want to include exact experience/individual stats.
So now we have banks. I'm unsure exactly whether or not they'll save to the PC when playing online (as Wc3 cache files would not save when playing on b.net), but they are extremely unprotected. Anyone can open them right up and edit anything to their liking.
So in this lies the problem. How can you create a save/load system that can save several different multiple digit variables and still prevent users from manipulating their characters to their liking? It might be possible to put fail-safe triggers in when loading a hero so that unless it passes a set of checks (such as having a certain unit below the minimum level to actually obtain that unit.. etc) it won't load correctly, but that can only go so far.
So does ANYONE have any idea as to how we can create a more fool-proof save/load system for b.net play? There MUST be SOME improvement over Wc3 in this area.
One word. Encryption. (Basically you would want to save everything as an encrypted string.)
Problem is, its basically like doing BOTH versions of the save/load system though. You still have to configure an entire string-based system and THEN save it to a file instead of having them write it out.
Could it work? Absolutely, but you still have to go through all of the trouble. Are we even sure that bank files can be saved while online yet?
Encrypting a string isn't really fun. You have to sort all of the values you want to save out into substrings, and then change each digit to a different letter/number and scramble them throughout the final string. When loading you have to pick out each digit for each integer, convert them back to the actual digit, and then set hero stats/values accordingly.
Its not really difficult, but the coding can take hours for each the save and the load for a properly encrypted string.
I remember an old Wc3 system that converted the values to hexadecimal and then to binary before flopping around the digits. This would be EXCELLENT if someone could code it, but alas I don't see that happening anytime soon.
Seems save/load encryption isn't going to get any easier.
Using Banks while playing on Battle.net, umm.. well.. I think I'm going to ask some people for a test in a few hours.
Anyways, you seem to forget that there are existing and working encryption algorithms and that we are able to use Galaxy, which is at least C-alike. I'm quite sure, that an implementation wouldn't be too hard.
I actually wanted to create a library but didn't have enough time... :x Maybe I'll find some this week.
Then the community has another goal to work towards. With the sheer scale of the project I'm undertaking, I don't have loads of time to try and pioneer all of my own workings. Thankfully thats one of the benefits of Blizzard having such huge mapmaking communities among their games. So many people able to work towards so many goals simultaneously.
It can wait until someone is able to successfully code a working encryption algorithm and others learn to adapt. I'm not extremely adept in coding C, so I've got a bit to go before I can start doing the more complicated workings in Galaxy. Until then, I've never had a problem figuring things out in GUI, and the current editor makes the GUI much capable than ever before.
Edit: I was also worried about banks during b.net play. Caches didn't work, but nobody has been able to test Banks up to this point. Blizzard hasn't really specified anything either.
Correct me if I'm wrong, but I heard that "banks" will be stored over Battle.NET, on Blizzard's own servers, linked to your account. Then you wouldn't have to worry about encryption at all.
Blizzard would never do that.(I suppose) The amount of data which could be stored would have quite an impact on the servers. The traffic too.
E: Adding a bank testmap..
It only depends on if they want to do it or not. If they do, they will put enough data servers to handle it :)
Sure.. but.. well.. sounds too expensive to me :P
Banks aren't very large. Even if you store virtually all of the information you could ever need for a map/hero, I couldn't see it going above 5kb, 10 at the absolute maximum (and you'd need to store a LOT of info for 10kb.)
With just 1kb, you can store Level, Experience, abilities, levels of abilities, type of unit, name of b.net account, location of hero, all items, and lets just say 10 other variables for quests.
So lets take the 'average' 1kb (I honestly expect the average bank for a hero save to be 500b). Multiply that by 10 million (to keep track of say.. 1 million custom mappers each having 10 banks for hero saves.
1kb x 10 million = 10Gb. You can get a 10Gb thumb drive at Walmart for $16. Even at 100Gb, or even 1TB (that would be 1 billiion 1kb bank files... which would never happen), Blizzard wouldn't break a sweat storing banks online. I've got a 4Tb Raid drive on my PS3 that cost me a whopping $300... less than pocket change for Blizzard.
However, I highly doubt they would ever do such a thing. It would make saving/loading a nightmare if you couldn't easily access at least the name of the file.
Edit: Btw, Blizzard has stated that the publish function will have a built-in map protection feature that would make it near impossible for others to rummage through your map scripts. This would easily deter those who want to view the script for their own benefit. Hopefully this means better and more balanced customs on b.net
Actually what they would avoid is an (accidentally or deliberately) broken map that saves a new bank 100 times per second, left running for days.
Thats fairly easily avoided though. If a map has hundreds of incoming banks per second, they can just blacklist the IP address they are coming from (which will be the game host).
Technically someone could make a map that purposely bombards the servers with banks, and Blizzard knows that. Just another reason I doubt they will host banks on their servers.
How would encryption solve this aside from severely obfuscating the string or data bank? The key you use to encrypt the data is either embedded in your map or generated off of some user-accessible data available every time a given player loads the map. The player just needs to find the algorithm and key in order to reverse it.
Certainly raises the bar for cracking load/save systems, but nothing foolproof.
If they end up storing the banks server side, I bet it's only saved when you exit the map (and cached in memory/on disk in the meantime)
Nothing will ever be fully foolproof... but encryption makes it more foolproof. And since one wants to have as less fools as possible, encryption seems to be the best way.
Poor player knowing nothing about the map and not being able to use any other saving map in an effective way. :P