Nice, someone knows about that Viral Bank Injector. Lol.
Anyway, there are SO many applications to a server-side bank.
First thing out of my head would be metrics. Metrics to measure our game's performance. If you allow the game to grab server date + time, this would make metrics even more useful.
Second, banning, (but don't tell that to Blizzard.)
Third, small tweaks in the game, such as changing the announcements or changing a unit's movement speed.
Fourth, in some ways, games can become an MMO.
If the server-side bank can save and load during a game, two or more lobbies can communicate with themselves. Simplest thing to imagine is an in-game global chatbox where people would log-in when they play the game.
If it can't, it will still be useful for mechanics such as faction progression, wherein if a faction keeps on winning, the game can take note of it.
Oh, and fifth, how could I forget? Leaderboards.
Rollback Post to RevisionRollBack
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
Second, banning, (but don't tell that to Blizzard.)
I hope they add some sort of clause allowing people to have their map removed if they use it for that case.
Quote:
Third, small tweaks in the game, such as changing the announcements or changing a unit's movement speed.
Wrong sort of bank? That would need a bank attached to the map and not to the players unless you really hate Blizzard and want to virally spread the data making hundreds of copies.
Quote:
If the server-side bank can save and load during a game, two or more lobbies can communicate with themselves. Simplest thing to imagine is an in-game global chatbox where people would log-in when they play the game.
Wrong sort of bank? That would need a bank attached to the map and not to the players. Due to the nature of the problem coherency between sessions would be a huge problem and so chances of seeing this sort of bank are as good as 0 (and even if we got it, chances are mappers will mess up badly using it).
Anyway my suggestions for the implementation of server side banks.
Each publisher gets a unique bank for each player (only created on demand to save server space).
Functionality exists to read banks for players from other publishers in a read-only way (so you can import progress from other publishers).
Functionality exists to read banks from different regions provided that both publisher and player accounts are known (publisher is constant, player can always look his other region account ID up).
The bank is limited in size to a couple of kilobytes (4-128 depending on how generous Blizzard is). This is for Blizzard's sake so that trolls cannot waste excessive server resources.
A user can at any time (maybe only outside of sessions) instruct the server to reset their bank for a certain publisher on that specific region. When a bank is reset it will be restored completely to default state in a way that the map cannot tell if the user has played before or not. This is an important feature in case a bug corrupts a player's server bank so that he can continue playing the map even if all progress is lost.
A user can at any time (maybe only outside of sessions) instruct the server to make a backup or to restore from backup a bank for a specific publisher. A limited number of such backups can exist (3-12) at any given time but they can be deleted, overwritten or copied as much as the user wants. This is to prevent progress loss in case of a bug.
To improve data packing, natives are added that allow for bulk data storage. Specifically the ability to write out ints into some form of named int list structure in the bank and recall them in an appropriate manner. The data is tored in binary form as opposed to textually allow for 33% more storage per byte over plain textual storage. Additionally the XML approach used by standard banks should be replaced with some form of binary storage solution to greatly reduce wrapper overheads (which can be as much as 95% of the bank size for some ignorant storage implementations currently).
Maps found abusing the server side banks of other players to deny or interfere with a specific player's ability to play are subject to removal. Players who feel like they were a victim of such an offence can report the map for it which may result in either all player banks for that publisher being reset or the map being removed.
I assumed by server-side banks they meant banks per-map, with the map being able to read any banks attached to it - even if the player or however they do it isn't playing the map at the time.
I guess that's a bit of an assumption.
If it's just a server-side version of the current bank system, who cares? But the above would be amazing. Where does it say what they were considering?
Most people want per player server side banks to prevent cheating. It is the same reason your Diablo III character is stored on the BattleNet 2.0 server as opposed to on your hard disk like the Xbox360/1 and PS3/4 versions. The result is Diablo III PC has 0 known instances of "hacked" stuff where as the consoles are plagued with cheated, impossible gear. If you read any of the previous threads here and at the official forums carefully it was made clear this is what they wanted.
Server banks on the publisher side for map would have very limited usability and suffer from the problems I mentioned earlier. Specifically the synchronization between possibly dozens of active sessions becomes a multi-threaded problem which I doubt most map authors have sufficient knowledge to comprehend let alone solve in a way that works. Even still this would not stop people cheating since ultimately users are the people running the game not the server.
All that is needed to defraud server banks is that the client play alone (or with a friend who also wants to defraud, or multiple friends etc) and then they modify the game process to create their fraudulent bank. The SC2 server will still say all clients are in sync so the game will still progress and since it is the clients uploading the bank to the server to store it will all make sense. If these were per-client banks then eventually the player will be banned for cheating so his fraudulent bank no longer maters. However if this was per map bank even if the player was banned you now have a corrupted server bank to deal with, your map is ruined.
Unlike Diablo III where BattleNet 2.0 computes all the game state and you only see the results, in SC2 BattleNet 2.0 simply acts as a coordination server with the clients all computing the results in parallel. Per player server banks could stream the results back from the player who it is intended for. However per publisher banks would have to rely on either a majority or a victim to stream the results for which might not be the actual results.
This is what I do not like about people making suggestions like this. They have not thought it through at all.
I see the point about cheating.
Personally though, I don't care about "cheating" at the moment - I want a way to track pick / win rates and such for multiplayer versus balancing.
I disagree that they'd have very little usability, though a lot of the usability could be kinda accomplished with Map Updates - but using banks would allow for a more "organic" process that can progress without the map owner's interference.
Wouldn't that defrauding rely on the defrauding players running a modified copy of the map that accesses the same bank? Not sure how they can corrupt the bank by just playing the map otherwise. Wintrading and other malevolent behavior that takes place within the "rules" of the map would be a problem for all types of banks.
Server-side map-attached banks don't need to replace the current local banks, I was thinking of them more as a server-side place for the "map" to store data. Synchronization wouldn't be an issue for this if timestamps are attached to any saved data, with each sync comparing and taking only the most recent if there is a conflict. I'd assume the bank would only update before/after games though, I can see dynamic updating during a match leading to a ton of problems.
Currently the only way I can think of to do this would be to attach game info to every player's bank with a timestamp, then run a trigger every match pulling all these, saving all unique timestamps into an array or whatever then saving it over the previous data in each player's bank. Essentially seeding all pick/winrate information between all players - but this relies on me playing the game with someone well-connected to the network to load the info into my bank for reading, and risks missing out on data if the network is disconnected at points.
To prevent this from becoming too much of a fight between map-based and player-based banks as well as to encourage a few more suggestions for different applications of sever-side banks, I just want to throw in some more information from the source that Joecab's post (see my comment above) is referring to, a conversation between mapmakers and developers of Blizzard: http://frozenerdz.com/episode-37-2-live-at-blizzcon-blizzard-arcade-qa/
In the script to this conversation you can find these parts:
Quote from ~ 11:10:
Something which we should really focus on more, try and figure out is loadnet’s map, and server-side bank saves. So we’re starting to look at that, trying to figure out what that means to do those featured sets. The more we have conversations and get into it, the more it’s clear that we need to understand better exactly how you guys will use those features, what do you want from them?
Quote from ~12:20:
M1: I guess I could give an example of that. So the server-side bank saves. We could make it that the way bank saves work, it just sends it to the server, and the player can begin from anywhere. And that would be fine for some kinds of popular deeds. Ending [inaudible, 0:10:10.8] seems to be kind of portable. But that wouldn’t stop people from hacking. They could still edit the bank to be [poison? 0:10:17.6] and not to the server. So if you want server-side banks because it’s about preventing hacking, that’s kind of a different feature that you’re looking for. A different way, a different format. But I think that feature. So again it’s a conversation we need to have, and I understand exactly what you guys want to get out of that feature set.
So apparently they don't plan to just throw in some new feature but rather want to hear from us what we would use it for and design it specifically for those needs. If map-based banks would be what we are in need of then I guess they won't stick solely to per-player banks. But to decide that we would actually have to list those needs first in order to convince them.
This is especially important for the sake of hack proof banks, as they apparently are/were thinking to make the server-based banks editable, which would negate them for this specific need. On the other hand that could open other fields of usage which is another reason why they think conversation with the mapmakers is so important for this.
(The script has some errors in it so I'd suggest you to listen closely to the given sections rather than reading through it)
As mentioned earlier, conventional banks would not be suitable for inter-map communication and data exchange. This is due to the problems of concurrency if you have 2 sessions of the same map going on. Player banks stored on the server do not suffer from this since only 1 instance of an account can be playing online at any given time and he can be in at most 1 session at any given time.
That said publishers could have an alternative way to collect and push data.
Pushing data to a map could come in the form of a server based "read only" bank. The author can modify this locally (text editor or in SC2E) and push it out to the server like he does updates. The bank downloads during session starts and is frozen at that state for the entire session (changes pushed mid-session will not alter the session). The bank is also cached for load times in future (only re-downloads if it is missing or has changed). Since this bank is read only and pulled from the server it is impossible for hackers to modify it.
Pushing and pulling live data data could come in the form of various atomic counter interfaces. For example generic wins, global kills, universally dealt damage would be prime candidates for this as they are incremented quantities which are common between sessions. The interface works by applying a delta to them (eg WorldCounterAdd/Subtract) which when called would update a named counter atomically. You can then get the value of the counter which will return some consistent value. Such statistics should be sent in batches every few minutes or longer. There should also be an action to wait until all counter modifications complete (since they might not execute instantly due to net traffic) which should be used when recording stats at the end of game so that people do not end the session before all statistics are gathered. Transaction wrapper natives could be useful to allow several modifications to be sent as a single unit which either succeeds or fails to prevent inconsistent statistics being logged. These cross section counters can be set, cleared and viewed from the SC2E by the publisher. Each publisher would be limited to a certain number of such counters (such as 128) and they may be subject to reset if his maps are not played for extended periods.
Cross session communication should have its own interface. Messages can be broadcast by an action and received messages arrive by triggering a message event. Messages are not persistent and no log of transferred messages is made. Messages also have no guarantee that all active sessions will receive them, with the servers making a best effort attempt to track down active sessions only. Messages themselves are limited in complexity having an integer for author specified type and a payload. The payload could be anything from an array of integers to a string or even a single integer depending on requirements. The payload size should be small 1 kb max to prevent excessive traffic generation. Authors can also send artificial messages using the editor to all active sessions of their map allowing the generation of messages not possible by the maps. This would allow global announcements, cross session communication and even some cross session interaction.
Finally for session bridging there should be a special purpose interface. The partner interface is similar to the message based interface in mechanics excepts guarantees receipt of the messages with lower latency and to consistent sessions (however you still cannot determine when they received the message). The restriction is at most 1-2 other sessions can be linked at any time by this. Partnering sessions occurs by members of two different sessions calling the "get partner" native, which could block for a long time, and then the server matching them up. A partnership cannot be cancelled once made and remains active until one of the sessions partaking in it ends. Partnerships are intended for closer inter-session interaction as they can form flows between servers.
In order to execute most of the above, each server should select a "victim" from each session who's responsibility is to manage the communication (his results are used). If he leaves the session and the session is still active then another victim should be selected so communication continues. There might need to be come physical cap on how often related calls can be made to avoid excessive net traffic.
The server side bank for author solves the problem of quick, transparent revisions as well as notifications.
The atomic counters solves the problem of gathering global statistics. It can also be used for things like leaderboards to a limited extent or holding global records (such as fastest time, most points etc).
The messages and partnership would allow cross-session cooperation. Although loosely synchronized so real time is not possible it should be sufficient for several new game types. For example a tower wars could be made where each session is their own team and sending spawns goes via message to another session etc. Another example could be a hero defense teaming up with a base storm where by both sessions lose if the hero defense session fails and both win if the base storm mission succeeds.
First - prevent players from modifying their banks in those maps that are muliple-sessions progress dependent (rpgs and such).
If players couldn't modify their bank following things would be possible:
-Item trading in rpg's without the dangers of players giving away items and then pasting their previous bank back.
-Item trading in rpg's without players hacking their banks and flooding games with eng-game OP gear.
(A few years ago I went on a playing frenzy for a certain arpg map in b-net. I've seen community around it rise and expand. But everything changed when the fire nation attacked But then the bank hackers came and spoiled map for majority of pubs. Bank resets and whatever anti-hacking measurements mapmaker implemented didn't help. The collapse of what was a pretty healthy playerbase shook off whatever desire I had to make an item-based map right there. You can argue that it's players fault for spoiling themselves with cheats, and it might be so, but when pubs fall - everyone suffers.)
And second thing is - global leaderboards without assholes spamming top scores with impossible goals. Some maps have this feature without the trolls, but I wouldn't count on all playerbases to be as classy. Imagine something like impossible scenarios with global scores to beat without the doubt that you're competing against hacked result.
But I don't really have a say in this, haven't made a map in three years now, if they listen to someone they listen to active ppl who actually produce stuff I imagine.
If players couldn't modify their bank following things would be possible:
-Item trading in rpg's without the dangers of players giving away items and then pasting their previous bank back.
-Item trading in rpg's without players hacking their banks and flooding games with eng-game OP gear.
And if players couldn't modify their bank following things would be possible:
Total loss of progress due to a map error.
Total loss of progress due to BattleNet error (not logging the change since obviously something server related would have to be used).
Inability to play map at all due to bank entering invalid state.
Inability to start multiple chains of progress (many characters).
Quote:
And second thing is - global leaderboards without assholes spamming top scores with impossible goals. Some maps have this feature without the trolls, but I wouldn't count on all playerbases to be as classy. Imagine something like impossible scenarios with global scores to beat without the doubt that you're competing against hacked result.
Or you get the opposite where by a hacked result poisons the now hard to fix banks making the problem worse. The best way to implement these sort of metric logging is via special atomic server calls and the metrics themselves can be modified and corrected by the publisher in case of hacking.
First - prevent players from modifying their banks in those maps that are muliple-sessions progress dependent (rpgs and such).
If players couldn't modify their bank following things would be possible:
-Item trading in rpg's without the dangers of players giving away items and then pasting their previous bank back.
-Item trading in rpg's without players hacking their banks and flooding games with eng-game OP gear.
(A few years ago I went on a playing frenzy for a certain arpg map in b-net. I've seen community around it rise and expand. But everything changed when the fire nation attacked But then the bank hackers came and spoiled map for majority of pubs. Bank resets and whatever anti-hacking measurements mapmaker implemented didn't help. The collapse of what was a pretty healthy playerbase shook off whatever desire I had to make an item-based map right there. You can argue that it's players fault for spoiling themselves with cheats, and it might be so, but when pubs fall - everyone suffers.)
And second thing is - global leaderboards without assholes spamming top scores with impossible goals. Some maps have this feature without the trolls, but I wouldn't count on all playerbases to be as classy. Imagine something like impossible scenarios with global scores to beat without the doubt that you're competing against hacked result.
But I don't really have a say in this, haven't made a map in three years now, if they listen to someone they listen to active ppl who actually produce stuff I imagine.
Aw bummer, I forgot how unreliable b-net can be at times (like the never-ending page loads and getting permanently stuck on "entering lobby" thingy, nevermind sudden disconnects and crashes). Also I didn't take into account how sometimes sh*t happens and everything corrupts due to mapmakers mistake.
Yeah, a clean-slate bank reset button is a must. Also need to export data for backups, but that defeats the whole point of anti-cheating.. So it's exactly as you said - user must be able to instruct b-net to make/load several backups. That's alot of extra space per player (relatively).
Man, not everything is as simple as one wishes it to be, thanks for educating me on the issues, can't believe I didn't even think about the possible problems beforehand, what a poo-head.
One major argument in favour of server side banks is the fact that players would be able to keep their progress even when switching computers. All battle.net progress is linked to the battle.net account, however, currently bank files are an exception to that rule, causing confusion and anger.
Especially games like RPGs, which are really dependent on progress logging mechanisms, suffer from this problem. Players can get pretty pissed losing characters they worked on for weeks. And now try to explain a non technical person how to transfer his/her bank file to the new computer... Its a nightmare. I know because I already had to do this.
Quote:
Total loss of progress due to a map error.
The same would happen with client side banks, as most people do not keep backups and are not even aware how exactly their progress gets saved.
Quote:
Total loss of progress due to BattleNet error (not logging the change since obviously something server related would have to be used).
I dont really think this is a strong argument agains server side storage, as the same would apply to pretty much everything that battle.net stores in databases (Ladder Rank etc.)
Quote:
Inability to play map at all due to bank entering invalid state.
Again, same for client side banks. Most people wouldnt even know how to delete an existing bank.
Quote:
Inability to start multiple chains of progress (many characters).
Invalid, as this is strictly a problem of the chosen data structure. Each character could get its own bank section, mutliple banks are not necessarily required and there is always a way around them.
There must be a way to wipe a server side bank, however, I dont really think its an issue that it can no longer be performed "manually". I think 99% of all players dont know how to approach that anyways. I also think server side banks require their own, seperate API, so the modder can decide which technology he wants to use (Maybe even mix both).
I would like to see server-side map banks, and client-side player banks (like we have now), that would be the best approach.
On your sever-side map banks, you could host a leaderboard and items your players are trying to trade, along with the encryption alphabet, and public keys (if you want to do RSA). We'd need the ability to wipe this bank clean if necessary, but if the bank tools stay the same it'd be possible to do it. It'd also be nice if it could be stamped with a time and date stamp that maps could reference.
On your client-side banks, you could store private keys (if necessary), their characters, and any personal info you want them to store there.
The same would happen with client side banks, as most people do not keep backups and are not even aware how exactly their progress gets saved.
Except in that case the client can always find blame in himself for not making a backup. If you play SC2 maps seriously you know to backup important banks from time to time to prevent loss. If you could not make a backup because you were not allowed to then all blame goes to someone else.
Quote:
I dont really think this is a strong argument agains server side storage, as the same would apply to pretty much everything that battle.net stores in databases (Ladder Rank etc.)
Except those are built into the game to be robust. I am pretty sure the servers track them from the server level rather than the client level. The same is not possible in Arcade maps with triggers as triggers are only executed at a client level. As such there is a layer of communication between client and server for such data to be transferred and that is where it can become unreliable. For example imagine if 1 bank field is updated yet another is not for real time changes? Or if the entire bank is transferred what happens if all clients exit just as the server finishes receiving the bank? Or what about banks for clients who have left a session and are already in another session? This sort of stuff is not easy to solve and many people here are trivializing it without thinking of the complexities it involves.
Quote:
Again, same for client side banks. Most people wouldnt even know how to delete an existing bank.
Except most people can fix the problem thanks to "Google". Only really incompetent people would struggle (why they even using a computer?). Client side banks allow you to recover from this by deleting the bank file. Such functionality would be required for server based bank files as well.
Quote:
Invalid, as this is strictly a problem of the chosen data structure. Each character could get its own bank section, mutliple banks are not necessarily required and there is always a way around them.
Is valid since Banks have a maximum size limit before sessions refuse to start (or have a high chance to fail to start). As such most RPGs have very limited number of character slots, often far fewer than the number of choices they give the player to choose from.
Quote:
There must be a way to wipe a server side bank, however, I dont really think its an issue that it can no longer be performed "manually". I think 99% of all players dont know how to approach that anyways. I also think server side banks require their own, seperate API, so the modder can decide which technology he wants to use (Maybe even mix both).
You are underestimating the average person. Maybe people do not know the approach off the top of their head but who needs to know anything in 2015 where you can just search or ask someone for the answer.
What if you could remote connect to some external data server and send SQL queries to it? Imagine an API which allows you to query data from a private owned database. Synchronization is handled by each client sending a request for it to the server which relays the request to the external server and the results are then forwarded to each clients which then unblock at a decided time. This pushes all problems with concurrency and storage to the author and his server rather than BattleNet 2.0. It would allow most of the above and solve the problem. Data loss and errors then becomes the sole responsibility of the content author.
Maybe you are right and I'm underestimating the average person. I guess I've just seen so many dumb things over the years that my expectations got lower and lower over time. That said, I still dont really agree with your logic.
I dont think anyone would "blame himself" if the client bank gets corrupted or destroyed. From my experience only IT-Experts really do backups, as they are the only people who really understand that Soft- and Hardware can sometimes fail. People always search mistakes elsewhere if they can. Do you really want to tell a customer who just lost all his progress because your software failed "Well... its your fault as you didnt do backups"? Hell... I dont. :D
The size limit of bank files got increased in a patch and, in fact, preloading banks of maximum size will not even work as the players time out far before finishing it. So the true limitation here is the battle.net timeout which will remove players who load for a too long time, not the actual size. When splitting the bank into multiple files (i.e. one per character), all banks still need to get preloaded as otherwise their information wont be available when choosing a certain character. Thus, splitting banks into multiple files will not increase the maximum amount of information you can effectively store, as it tackles the problem from the wrong side, so to say.
I agree that a custom SQL Database would be the 'wet dream' scenario, maybe Blizzard will surprise us with something cool for LotV! :)
Does anyone know if this is planned finaly?
If you didnt already read it then I think this: http://www.sc2mapster.com/forums/general/general-chat/72064-unnofical-summary-of-the-recorded-blizzcon-q-a/#posts is the latest info. Joecab said that they were discussing Server Side Banks internally, but also wanted to hear what we, the mapmakers, would need them for, probably because they dont want to implement something no one uses.
Also this: http://www.sc2mapster.com/forums/general/general-chat/59404-server-side-banks/ would be worth mentioning (keep in mind that it is not official informaion like in Joecabs post)
But I dont know if this is the latest post regarding this topic, would really like to know about the current state too
@TheUltragon: Go
Would be great for keeping track of Pick/Winrates.
I'd rather not have to set up some sort of "viral" thing to do so. Actually that sounds kinda fun, but still.
Nice, someone knows about that Viral Bank Injector. Lol.
Anyway, there are SO many applications to a server-side bank.
First thing out of my head would be metrics. Metrics to measure our game's performance. If you allow the game to grab server date + time, this would make metrics even more useful.
Second, banning, (but don't tell that to Blizzard.)
Third, small tweaks in the game, such as changing the announcements or changing a unit's movement speed.
Fourth, in some ways, games can become an MMO.
If the server-side bank can save and load during a game, two or more lobbies can communicate with themselves. Simplest thing to imagine is an in-game global chatbox where people would log-in when they play the game.
If it can't, it will still be useful for mechanics such as faction progression, wherein if a faction keeps on winning, the game can take note of it.
Oh, and fifth, how could I forget? Leaderboards.
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
Probably not seeing how unnecessary they are.
I hope they add some sort of clause allowing people to have their map removed if they use it for that case.
Wrong sort of bank? That would need a bank attached to the map and not to the players unless you really hate Blizzard and want to virally spread the data making hundreds of copies.
Wrong sort of bank? That would need a bank attached to the map and not to the players. Due to the nature of the problem coherency between sessions would be a huge problem and so chances of seeing this sort of bank are as good as 0 (and even if we got it, chances are mappers will mess up badly using it).
Anyway my suggestions for the implementation of server side banks.
Oh, they were referring to a server-side bank attached to a player? Geez, that's pretty useless then.
The only application I could think of for this would be a verification system for the client-side bank.
They should do a map attached bank. More application for us, less resources for them.
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
@ImperialGood: Go
I assumed by server-side banks they meant banks per-map, with the map being able to read any banks attached to it - even if the player or however they do it isn't playing the map at the time.
I guess that's a bit of an assumption.
If it's just a server-side version of the current bank system, who cares? But the above would be amazing. Where does it say what they were considering?
Most people want per player server side banks to prevent cheating. It is the same reason your Diablo III character is stored on the BattleNet 2.0 server as opposed to on your hard disk like the Xbox360/1 and PS3/4 versions. The result is Diablo III PC has 0 known instances of "hacked" stuff where as the consoles are plagued with cheated, impossible gear. If you read any of the previous threads here and at the official forums carefully it was made clear this is what they wanted.
Server banks on the publisher side for map would have very limited usability and suffer from the problems I mentioned earlier. Specifically the synchronization between possibly dozens of active sessions becomes a multi-threaded problem which I doubt most map authors have sufficient knowledge to comprehend let alone solve in a way that works. Even still this would not stop people cheating since ultimately users are the people running the game not the server.
All that is needed to defraud server banks is that the client play alone (or with a friend who also wants to defraud, or multiple friends etc) and then they modify the game process to create their fraudulent bank. The SC2 server will still say all clients are in sync so the game will still progress and since it is the clients uploading the bank to the server to store it will all make sense. If these were per-client banks then eventually the player will be banned for cheating so his fraudulent bank no longer maters. However if this was per map bank even if the player was banned you now have a corrupted server bank to deal with, your map is ruined.
Unlike Diablo III where BattleNet 2.0 computes all the game state and you only see the results, in SC2 BattleNet 2.0 simply acts as a coordination server with the clients all computing the results in parallel. Per player server banks could stream the results back from the player who it is intended for. However per publisher banks would have to rely on either a majority or a victim to stream the results for which might not be the actual results.
This is what I do not like about people making suggestions like this. They have not thought it through at all.
@ImperialGood: Go
I see the point about cheating. Personally though, I don't care about "cheating" at the moment - I want a way to track pick / win rates and such for multiplayer versus balancing.
I disagree that they'd have very little usability, though a lot of the usability could be kinda accomplished with Map Updates - but using banks would allow for a more "organic" process that can progress without the map owner's interference.
Wouldn't that defrauding rely on the defrauding players running a modified copy of the map that accesses the same bank? Not sure how they can corrupt the bank by just playing the map otherwise. Wintrading and other malevolent behavior that takes place within the "rules" of the map would be a problem for all types of banks.
Server-side map-attached banks don't need to replace the current local banks, I was thinking of them more as a server-side place for the "map" to store data. Synchronization wouldn't be an issue for this if timestamps are attached to any saved data, with each sync comparing and taking only the most recent if there is a conflict. I'd assume the bank would only update before/after games though, I can see dynamic updating during a match leading to a ton of problems.
Currently the only way I can think of to do this would be to attach game info to every player's bank with a timestamp, then run a trigger every match pulling all these, saving all unique timestamps into an array or whatever then saving it over the previous data in each player's bank. Essentially seeding all pick/winrate information between all players - but this relies on me playing the game with someone well-connected to the network to load the info into my bank for reading, and risks missing out on data if the network is disconnected at points.
To prevent this from becoming too much of a fight between map-based and player-based banks as well as to encourage a few more suggestions for different applications of sever-side banks, I just want to throw in some more information from the source that Joecab's post (see my comment above) is referring to, a conversation between mapmakers and developers of Blizzard: http://frozenerdz.com/episode-37-2-live-at-blizzcon-blizzard-arcade-qa/
In the script to this conversation you can find these parts:
So apparently they don't plan to just throw in some new feature but rather want to hear from us what we would use it for and design it specifically for those needs. If map-based banks would be what we are in need of then I guess they won't stick solely to per-player banks. But to decide that we would actually have to list those needs first in order to convince them.
This is especially important for the sake of hack proof banks, as they apparently are/were thinking to make the server-based banks editable, which would negate them for this specific need. On the other hand that could open other fields of usage which is another reason why they think conversation with the mapmakers is so important for this.
(The script has some errors in it so I'd suggest you to listen closely to the given sections rather than reading through it)
As mentioned earlier, conventional banks would not be suitable for inter-map communication and data exchange. This is due to the problems of concurrency if you have 2 sessions of the same map going on. Player banks stored on the server do not suffer from this since only 1 instance of an account can be playing online at any given time and he can be in at most 1 session at any given time.
That said publishers could have an alternative way to collect and push data.
Pushing data to a map could come in the form of a server based "read only" bank. The author can modify this locally (text editor or in SC2E) and push it out to the server like he does updates. The bank downloads during session starts and is frozen at that state for the entire session (changes pushed mid-session will not alter the session). The bank is also cached for load times in future (only re-downloads if it is missing or has changed). Since this bank is read only and pulled from the server it is impossible for hackers to modify it.
Pushing and pulling live data data could come in the form of various atomic counter interfaces. For example generic wins, global kills, universally dealt damage would be prime candidates for this as they are incremented quantities which are common between sessions. The interface works by applying a delta to them (eg WorldCounterAdd/Subtract) which when called would update a named counter atomically. You can then get the value of the counter which will return some consistent value. Such statistics should be sent in batches every few minutes or longer. There should also be an action to wait until all counter modifications complete (since they might not execute instantly due to net traffic) which should be used when recording stats at the end of game so that people do not end the session before all statistics are gathered. Transaction wrapper natives could be useful to allow several modifications to be sent as a single unit which either succeeds or fails to prevent inconsistent statistics being logged. These cross section counters can be set, cleared and viewed from the SC2E by the publisher. Each publisher would be limited to a certain number of such counters (such as 128) and they may be subject to reset if his maps are not played for extended periods.
Cross session communication should have its own interface. Messages can be broadcast by an action and received messages arrive by triggering a message event. Messages are not persistent and no log of transferred messages is made. Messages also have no guarantee that all active sessions will receive them, with the servers making a best effort attempt to track down active sessions only. Messages themselves are limited in complexity having an integer for author specified type and a payload. The payload could be anything from an array of integers to a string or even a single integer depending on requirements. The payload size should be small 1 kb max to prevent excessive traffic generation. Authors can also send artificial messages using the editor to all active sessions of their map allowing the generation of messages not possible by the maps. This would allow global announcements, cross session communication and even some cross session interaction.
Finally for session bridging there should be a special purpose interface. The partner interface is similar to the message based interface in mechanics excepts guarantees receipt of the messages with lower latency and to consistent sessions (however you still cannot determine when they received the message). The restriction is at most 1-2 other sessions can be linked at any time by this. Partnering sessions occurs by members of two different sessions calling the "get partner" native, which could block for a long time, and then the server matching them up. A partnership cannot be cancelled once made and remains active until one of the sessions partaking in it ends. Partnerships are intended for closer inter-session interaction as they can form flows between servers.
In order to execute most of the above, each server should select a "victim" from each session who's responsibility is to manage the communication (his results are used). If he leaves the session and the session is still active then another victim should be selected so communication continues. There might need to be come physical cap on how often related calls can be made to avoid excessive net traffic.
The server side bank for author solves the problem of quick, transparent revisions as well as notifications.
The atomic counters solves the problem of gathering global statistics. It can also be used for things like leaderboards to a limited extent or holding global records (such as fastest time, most points etc).
The messages and partnership would allow cross-session cooperation. Although loosely synchronized so real time is not possible it should be sufficient for several new game types. For example a tower wars could be made where each session is their own team and sending spawns goes via message to another session etc. Another example could be a hero defense teaming up with a base storm where by both sessions lose if the hero defense session fails and both win if the base storm mission succeeds.
Ah ah, for me it's about 2 things.
First - prevent players from modifying their banks in those maps that are muliple-sessions progress dependent (rpgs and such).
If players couldn't modify their bank following things would be possible:
-Item trading in rpg's without the dangers of players giving away items and then pasting their previous bank back.
-Item trading in rpg's without players hacking their banks and flooding games with eng-game OP gear.
(A few years ago I went on a playing frenzy for a certain arpg map in b-net. I've seen community around it rise and expand.
But everything changed when the fire nation attackedBut then the bank hackers came and spoiled map for majority of pubs. Bank resets and whatever anti-hacking measurements mapmaker implemented didn't help. The collapse of what was a pretty healthy playerbase shook off whatever desire I had to make an item-based map right there. You can argue that it's players fault for spoiling themselves with cheats, and it might be so, but when pubs fall - everyone suffers.)And second thing is - global leaderboards without assholes spamming top scores with impossible goals. Some maps have this feature without the trolls, but I wouldn't count on all playerbases to be as classy. Imagine something like impossible scenarios with global scores to beat without the doubt that you're competing against hacked result.
But I don't really have a say in this, haven't made a map in three years now, if they listen to someone they listen to active ppl who actually produce stuff I imagine.
And if players couldn't modify their bank following things would be possible:
Or you get the opposite where by a hacked result poisons the now hard to fix banks making the problem worse. The best way to implement these sort of metric logging is via special atomic server calls and the metrics themselves can be modified and corrected by the publisher in case of hacking.
Best post in there, +1
@ImperialGood: Go
Aw bummer, I forgot how unreliable b-net can be at times (like the never-ending page loads and getting permanently stuck on "entering lobby" thingy, nevermind sudden disconnects and crashes). Also I didn't take into account how sometimes sh*t happens and everything corrupts due to mapmakers mistake.
Yeah, a clean-slate bank reset button is a must. Also need to export data for backups, but that defeats the whole point of anti-cheating.. So it's exactly as you said - user must be able to instruct b-net to make/load several backups. That's alot of extra space per player (relatively).
Man, not everything is as simple as one wishes it to be, thanks for educating me on the issues, can't believe I didn't even think about the possible problems beforehand, what a poo-head.
One major argument in favour of server side banks is the fact that players would be able to keep their progress even when switching computers. All battle.net progress is linked to the battle.net account, however, currently bank files are an exception to that rule, causing confusion and anger.
Especially games like RPGs, which are really dependent on progress logging mechanisms, suffer from this problem. Players can get pretty pissed losing characters they worked on for weeks. And now try to explain a non technical person how to transfer his/her bank file to the new computer... Its a nightmare. I know because I already had to do this.
The same would happen with client side banks, as most people do not keep backups and are not even aware how exactly their progress gets saved.
I dont really think this is a strong argument agains server side storage, as the same would apply to pretty much everything that battle.net stores in databases (Ladder Rank etc.)
Again, same for client side banks. Most people wouldnt even know how to delete an existing bank.
Invalid, as this is strictly a problem of the chosen data structure. Each character could get its own bank section, mutliple banks are not necessarily required and there is always a way around them.
There must be a way to wipe a server side bank, however, I dont really think its an issue that it can no longer be performed "manually". I think 99% of all players dont know how to approach that anyways. I also think server side banks require their own, seperate API, so the modder can decide which technology he wants to use (Maybe even mix both).
I would like to see server-side map banks, and client-side player banks (like we have now), that would be the best approach.
On your sever-side map banks, you could host a leaderboard and items your players are trying to trade, along with the encryption alphabet, and public keys (if you want to do RSA). We'd need the ability to wipe this bank clean if necessary, but if the bank tools stay the same it'd be possible to do it. It'd also be nice if it could be stamped with a time and date stamp that maps could reference.
On your client-side banks, you could store private keys (if necessary), their characters, and any personal info you want them to store there.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Except in that case the client can always find blame in himself for not making a backup. If you play SC2 maps seriously you know to backup important banks from time to time to prevent loss. If you could not make a backup because you were not allowed to then all blame goes to someone else.
Except those are built into the game to be robust. I am pretty sure the servers track them from the server level rather than the client level. The same is not possible in Arcade maps with triggers as triggers are only executed at a client level. As such there is a layer of communication between client and server for such data to be transferred and that is where it can become unreliable. For example imagine if 1 bank field is updated yet another is not for real time changes? Or if the entire bank is transferred what happens if all clients exit just as the server finishes receiving the bank? Or what about banks for clients who have left a session and are already in another session? This sort of stuff is not easy to solve and many people here are trivializing it without thinking of the complexities it involves.
Except most people can fix the problem thanks to "Google". Only really incompetent people would struggle (why they even using a computer?). Client side banks allow you to recover from this by deleting the bank file. Such functionality would be required for server based bank files as well.
Is valid since Banks have a maximum size limit before sessions refuse to start (or have a high chance to fail to start). As such most RPGs have very limited number of character slots, often far fewer than the number of choices they give the player to choose from.
You are underestimating the average person. Maybe people do not know the approach off the top of their head but who needs to know anything in 2015 where you can just search or ask someone for the answer.
What if you could remote connect to some external data server and send SQL queries to it? Imagine an API which allows you to query data from a private owned database. Synchronization is handled by each client sending a request for it to the server which relays the request to the external server and the results are then forwarded to each clients which then unblock at a decided time. This pushes all problems with concurrency and storage to the author and his server rather than BattleNet 2.0. It would allow most of the above and solve the problem. Data loss and errors then becomes the sole responsibility of the content author.
@ImperialGood: Go
Maybe you are right and I'm underestimating the average person. I guess I've just seen so many dumb things over the years that my expectations got lower and lower over time. That said, I still dont really agree with your logic.
I dont think anyone would "blame himself" if the client bank gets corrupted or destroyed. From my experience only IT-Experts really do backups, as they are the only people who really understand that Soft- and Hardware can sometimes fail. People always search mistakes elsewhere if they can. Do you really want to tell a customer who just lost all his progress because your software failed "Well... its your fault as you didnt do backups"? Hell... I dont. :D
The size limit of bank files got increased in a patch and, in fact, preloading banks of maximum size will not even work as the players time out far before finishing it. So the true limitation here is the battle.net timeout which will remove players who load for a too long time, not the actual size. When splitting the bank into multiple files (i.e. one per character), all banks still need to get preloaded as otherwise their information wont be available when choosing a certain character. Thus, splitting banks into multiple files will not increase the maximum amount of information you can effectively store, as it tackles the problem from the wrong side, so to say.
I agree that a custom SQL Database would be the 'wet dream' scenario, maybe Blizzard will surprise us with something cool for LotV! :)
I hope blizzard will read this post, they wanted a discussion about it, they have one!