You must explictly declare which banks you want to preload in map properties. There's option for it somewhere in menu, should be called "Preload info".
In case of using Trigger GUI elements, the editor does that for you (at least it used to), but in case of raw script it doesn't, as it doesn't process it.
btw. Small notice in regards to your code, when bank fails to verify it doesn't mean the data from it hasn't been loaded, but only that the signature check failed. And calling BankLoad again won't erase the data here (unless you do that manually by iterating over sections). Thus you likely want to call BankRemove after BankVerify fails. This guarantees it will be cleared.
Thanks. So basically this might be a good use of the GUI then, because its nicer to have this closer to code. Its also helpful because you're telling me preload is the only way to make the bank load at all. I didn't realize that, I thought that was just for optimization (I mean, I care about optimization and planned to add it in, but I never dreamed it wouldn't allow the banks to be loaded at all!).
Also, thanks. I really kinda dislike this bank API. I think it kinda fails at the rules of single responsibility, as BankLoad seems to also take care of creation. It should be more like "BankCreate()" "BankSave()" "BankLoad()" "BankExists()". This API isn't the best but I can at least now see how it was intended for use. Thanks!
Edit: Its not that bad though, I believe I was nitpicking and ranting a bit earlier. XD
Edit: I see an advantage of using [MAP] -> [PRELOAD INFO ..]. Going to be more maintainable having the "ALL PLAYERS" option
If we are not talking about banks, then preloading is indeed only a way to optimize the map. All others assets can be read on demand if not preloaded.
Banks however are special. Loading them on demand would not be feasible. Not in a multiplayer game, with p2p netcode. Where each player would need to transfer bank data to every other player in this particular game. Some banks can go over 1MB.. and since the current bank API is not asynchrous it would cause a lag spike that could last seconds.
The game could preload all the existing banks certain player has. But that would not be wise given the fact that banks are scoped to publishers account, and not the map. Thus it could preload a lot of irrevelant data. That's why we were given system as such, where map must declare what banks it wants to use by listing them under preload section, with an option to limit it to certain player.
edit:
I need to correct myself on one thing. Even though game protocol is P2P, the bnet servers are used as broadcasters, thus clients do not have to transfer the bank data to every other client in the game, as bnet server will do that. But it doesn't change the fact that you've to receive the bank data of every other player in the game in order to stay in sync.
Banks however are special. Loading them on demand would not be feasible. Not in a multiplayer game, with p2p netcode. Where each player would need to transfer bank data to every other player in this particular game. Some banks can go over 1MB.. and since the current bank API is not asynchrous it would cause a lag spike that could last seconds.
No peer-to-peer transfers happen as most people are behind NATs. Instead the banks are sent to the Blizzard server which then uploads it to all the clients. This happens during map loading. This is why it must be preloaded, to instruct the clients to perform that operation synchronously during the map load process.
Even though game protocol is P2P
The game is not peer-to-peer in any way, shape or form. Some silly people call the synchronization model "peer-to-peer" however even that is wrong since that term describes a communication configuration and not a synchronization model. The game is a standard client-server model where clients each keep a copy of the game state while the server coordinate them.
While p2p term might not apply here, it comes very close in how I envision it.
On a network level it is client-server. But not the communication method is what I refered to, but the process of evaluating game state.
If server is not responsible for its computation, then it has no relevance under these terms.
Its role here is just to broadcast game input coming from its clients. There is no centralised unit. Each of the clients processes input on its own. And it's up to the clients to determine whether input they receive is valid at all for the current state. And now tell me that is not similar to parallel data processing - where p2p term applies.
Though, I do realize that clients are transfering only inputs of their own actions, and not the results of the computation, what I suppose make it invalid to describe as p2p.. still, not outrageously wrong as you would want it to be.
Also, I'm aware that Blizzard might have put some additional tasks on the server in order to get the best of this model. Tasks beyond wraping input packets with client id and instantly passing them over. But it's not what I was after.
No peer-to-peer transfers happen as most people are behind NATs.
While it's true, and having just said I didn't refer to network model. I'll just add it's not a showstopper. Techniques like udp hole punching exist and are used with great success as far as I'm aware.
Its role here is just to broadcast game input coming from its clients. There is no centralised unit. Each of the clients processes input on its own. And it's up to the clients to determine whether input they receive is valid at all for the current state. And now tell me that is not similar to parallel data processing - where p2p term applies.
The problem with using it in that context is the word to. That implies 1 peer directly communicates with another peer, and not to a server. Since it does so via a server, this means it is a client-server model. If the server fails, all clients are disconnected instantly.
In the case of Heroes of the Storm the server logs all game commands. It can stream these commands to clients, eg someone who disconnected, who can then fast forward through these commands to catch up to the current game state without any other clients even being aware this is occurring. Hence again it is a client-server model.
A more correct term for describing the sort of synchronization would be state replicating, since each client replicates a copy of the game state as controlled by the server. This is opposed to state streaming used by games like Diablo III where only the server maintains the game state and all clients are instead streamed a snapshot of it.
Techniques like udp hole punching exist and are used with great success as far as I'm aware.
StarCraft II, like all Blizzard games, uses exclusively TCP. As far as game development goes there is little to gain from using UDP but a lot to lose.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I have a script which is supposed to load a bank file if it exists and display a message to the user based on the load status.
What I have is (similar to) this. I stripped it down so you don't have to view all the logic which isn't relevant to the question.
Basically my problem is no matter how many times I load the map, the game outputs "New player detected. Creating new bank file!"
bank b;
int i = 1;
playergroup playerGroup = PlayerGroupSingle(i);
if(BankExists("bankname", i)){
UIDisplayMessage(playerGroup, c_messageAreaSubtitle, StringToText("The bank exists. Welcome back!"));
b = BankLoad("bankname", i);
if(BankVerify(b)){
UIDisplayMessage(playerGroup, c_messageAreaSubtitle, StringToText("The bank loaded successfully"));
}
else{
UIDisplayMessage(playerGroup, c_messageAreaSubtitle, StringToText("Failed to load bank. Creating new!"));
b = BankLoad("bankname", i);
}
}
else{
UIDisplayMessage(playerGroup, c_messageAreaSubtitle, StringToText("New player detected. Creating new bank file!"));
b = BankLoad("bankname", i);
BankOptionSet(b, c_bankOptionSignature, true);
BankSave(b);
}
You must explictly declare which banks you want to preload in map properties. There's option for it somewhere in menu, should be called "Preload info".
In case of using Trigger GUI elements, the editor does that for you (at least it used to), but in case of raw script it doesn't, as it doesn't process it.
btw. Small notice in regards to your code, when bank fails to verify it doesn't mean the data from it hasn't been loaded, but only that the signature check failed.
And calling BankLoad again won't erase the data here (unless you do that manually by iterating over sections). Thus you likely want to call BankRemove after BankVerify fails. This guarantees it will be cleared.
Previously known as: SomeoneTookMyNameTT
I'm might be wrong here, but I remember that someone said you have to use explicit values in the parameters of the bank functions.
So, you can't have BankExists("bankname", i);
It has to be BankExists("bankname", 1);
In reply to Forge_User_72656615:
In reply to Talv_:
If we are not talking about banks, then preloading is indeed only a way to optimize the map. All others assets can be read on demand if not preloaded.
Banks however are special. Loading them on demand would not be feasible. Not in a multiplayer game, with p2p netcode. Where each player would need to transfer bank data to every other player in this particular game. Some banks can go over 1MB.. and since the current bank API is not asynchrous it would cause a lag spike that could last seconds.
The game could preload all the existing banks certain player has. But that would not be wise given the fact that banks are scoped to publishers account, and not the map. Thus it could preload a lot of irrevelant data.
That's why we were given system as such, where map must declare what banks it wants to use by listing them under preload section, with an option to limit it to certain player.
edit:
I need to correct myself on one thing. Even though game protocol is P2P, the bnet servers are used as broadcasters, thus clients do not have to transfer the bank data to every other client in the game, as bnet server will do that. But it doesn't change the fact that you've to receive the bank data of every other player in the game in order to stay in sync.
Previously known as: SomeoneTookMyNameTT
In reply to Talv_:
No peer-to-peer transfers happen as most people are behind NATs. Instead the banks are sent to the Blizzard server which then uploads it to all the clients. This happens during map loading. This is why it must be preloaded, to instruct the clients to perform that operation synchronously during the map load process.
The game is not peer-to-peer in any way, shape or form. Some silly people call the synchronization model "peer-to-peer" however even that is wrong since that term describes a communication configuration and not a synchronization model. The game is a standard client-server model where clients each keep a copy of the game state while the server coordinate them.
While p2p term might not apply here, it comes very close in how I envision it.
On a network level it is client-server. But not the communication method is what I refered to, but the process of evaluating game state.
If server is not responsible for its computation, then it has no relevance under these terms.
Its role here is just to broadcast game input coming from its clients. There is no centralised unit. Each of the clients processes input on its own. And it's up to the clients to determine whether input they receive is valid at all for the current state.
And now tell me that is not similar to parallel data processing - where p2p term applies.
Though, I do realize that clients are transfering only inputs of their own actions, and not the results of the computation, what I suppose make it invalid to describe as p2p.. still, not outrageously wrong as you would want it to be.
Also, I'm aware that Blizzard might have put some additional tasks on the server in order to get the best of this model. Tasks beyond wraping input packets with client id and instantly passing them over. But it's not what I was after.
While it's true, and having just said I didn't refer to network model.
I'll just add it's not a showstopper. Techniques like udp hole punching exist and are used with great success as far as I'm aware.
Previously known as: SomeoneTookMyNameTT
The problem with using it in that context is the word to. That implies 1 peer directly communicates with another peer, and not to a server. Since it does so via a server, this means it is a client-server model. If the server fails, all clients are disconnected instantly.
In the case of Heroes of the Storm the server logs all game commands. It can stream these commands to clients, eg someone who disconnected, who can then fast forward through these commands to catch up to the current game state without any other clients even being aware this is occurring. Hence again it is a client-server model.
A more correct term for describing the sort of synchronization would be state replicating, since each client replicates a copy of the game state as controlled by the server. This is opposed to state streaming used by games like Diablo III where only the server maintains the game state and all clients are instead streamed a snapshot of it.
StarCraft II, like all Blizzard games, uses exclusively TCP. As far as game development goes there is little to gain from using UDP but a lot to lose.