Feature: Server-side storage of player data
Priority: 0
I've just put some thought on how this would be actually implemented. As far as I know anyone with a valid SC2 account has 157MB of storage space that is tied to your account. (well, the numbers are from the "Manage Published" menu in the Galaxy Editor)
If server-side banks are to be actually implemented my guess is via those account storage. However instead of having just banks server-side, I think this 157MB storage could be put to much more usage. Not every players publish maps, and much of those space are just left there.
There could be multiple ways to do, make it only accept bank files to an upper size limit and allow players to upload bank files.. or an option that locks the bank file so that it cannot be edited or even opened at first. The only way to access the bank would be from inside an actual game.
Feature: Map-side reserve option of user stats data
Priority: 1
When publishing a map, there really should be an option for reserving user stats data. This would be useful for maps with large playerbase, with features like ranking system.
Say there's a map with 20MB publishing size. Give an 1MB option for user stats data, then this map would take up 21MB in the publisher's account space. Actual map data takes up 20MB, and the other 1MB would be reserved for given purposes.
The difference is on whether the players download assets after launching game instance, or before.
If you make it available in-game, you can use the screenshot as asset in triggers and such. Yes, in this case players download the screenshots when they launch a game instance ( not waiting in lobby )
If you make it *not* available in-game, players download the screenshots *before* they launch a game instance because bnet has to display the screenshots on map info. Overall upload size won't be much different, because even if bnet is hashing every screenshot for comparison you'd still have to upload the file via editor. However in this case *players* wouldn't have to d/l screenshots when they launch a game instance, because the screenshots are not going to be used in the actual game.
people sticking to WoL won't be at too much of a disadvantage
I don't know if this tendency applies to all servers, but from what I've seen popular maps tend to stick with WoL because migrating to HotS would mean losing some portion of players. Instead HotS version of the map would be published separately.
Some sort of AI compensation would be nice. If players get trouble countering skill A but easily dodge skill B, then the boss would gradually use skill A more often. This can prevent the game from getting repetitive, when done well.
..wow. I didn't think about that.
If the number of dummy players are the same with the number of teams there shouldn't be any problem.
But what about those game types with no teams at all? Even for 15 player FFA at least one of the players have to attack his own unit.
I actually like that idea, mr. Devil. If you could run the game entirely in "test document" or single player entirely - every map would run more smoothly (essentially...).
I've checked it, and it's published as public. I can't search for it with "sniping" though.. strange.
It seems that having two or more locales with different map names is causing trouble. I can search for the name I've used in KR/TW publish, but not "sniping" or "sniper".
Here's link. starcrft://map/1/205898
it should launch SC2 and show the map info directly after you log into NA server.
and I'll publish to EU too, once I get this map name issue settled:) Thanks for notifying.
Sniping Sniper is a simplified top-down view arena shooter, where your skills matter.
There is only one objective: survive.
Published on NA region as "Sniping:Sniper" (without the quotes)
Published on EU region as "Sniping:Sniper" (without the quotes)
Features
Four Distinct Abilities
Snipe - EN 25. Line Damage. Not like Promod. Streaks are possible.
Resist - EN 50. Hardens your armor for a short time. Good reflexes are rewarded.
Pulse - EN 75. Interact with environment and gain tactical advantages. Burn trees, Scan structures, and even burn your enemies' energy.
Corvid Railgun - EN 100. Sniping means "long distance". Blast your enemies from where they can't even see you. Available after 60s of every game.
Two Modes - Free For All and Team Deathmatch. Supports up to 10 players.
Three Arenas - Each arena has unique environment.
Fury Option - Rage-quitting is not healthy. Unleash your rage to your enemies.
Basic Stats - Track your accuracy.
Bot Support
Bots have random skill levels.
Beware; bots are not designed for practicing. Bots use all abilities at will, with the exception of railgun.
There is no setup for bots. bots are not designed for practicing.
Skillful bots are hard to meet. Frag them, and they will be a part of your stats.
Comments
This map was originally published in KR/TW. Thanks to the Global Play feature, now I can translate my maps and publish to other regions. I'm looking forward to any feedbacks/suggestions/comments ;)
Too bad Blizz won't allow it..
I was thinking about the technical side, and to make MMORPGs with this there should be a way to go around the player limit.
What I mean, is if GameA has 14 players and GameB also has 14 players, to join them we need a way to simulate the ally properties.
Once GameA's player quota is full, any player's units from other gameB has to be assigned a controller, which all slots are already being used by GameA's players. If the joining units are assigned "Neutral" or "Hostile", its gonna put strict limits to the game types possible with this system.
@butterflo: Go Just remember to make the player's race Protoss AND remove the other options, that's how I did it, because if you just select the race in Game Variants you still get to play other races right now.
Solved. the reason second case wasn't working for me was that I had some players set to non-random.
From Map >> Player Properties >> set *ALL* Race set to "Any"
..doing this made it go through the header transmission error. As SoulFilcher said removing other options in Game Variants forces all players to one value as intended, but it wont raise any header error if Player Properties races are all set to "Any".
I have no idea what's going on here, but here it is.
case 1:
From Map >> Player Properties >> Race set to "Protoss"
When I publish this, Bnet says "Zerg". and I can't change it as its grayed out.
This also seems to cause the race setting in game variants unchangeable.
case 2:
From Map >> Player Properties >> Race set to "Random"
..Now I can change the race setting in game variants.
From Map >> Game Variants >> Player Attributes >> Check "Zerg" "Terran" "Random"
This leaves only one choice, so the race is set to Protoss.
When I publish this, it fails in "Transmitting Header File". the log says "Variant definitions could not be validated".
is there any working way to set the lobby race to Protoss only?
I didn't thought about private maps. Deleting a map would make the name unusable also..
Thanks for comment;) I guess I'll have to use a similar different name.
0
Feature: Server-side storage of player data
Priority: 0
I've just put some thought on how this would be actually implemented. As far as I know anyone with a valid SC2 account has 157MB of storage space that is tied to your account. (well, the numbers are from the "Manage Published" menu in the Galaxy Editor)
If server-side banks are to be actually implemented my guess is via those account storage. However instead of having just banks server-side, I think this 157MB storage could be put to much more usage. Not every players publish maps, and much of those space are just left there.
There could be multiple ways to do, make it only accept bank files to an upper size limit and allow players to upload bank files.. or an option that locks the bank file so that it cannot be edited or even opened at first. The only way to access the bank would be from inside an actual game.
Feature: Map-side reserve option of user stats data
Priority: 1
When publishing a map, there really should be an option for reserving user stats data. This would be useful for maps with large playerbase, with features like ranking system.
Say there's a map with 20MB publishing size. Give an 1MB option for user stats data, then this map would take up 21MB in the publisher's account space. Actual map data takes up 20MB, and the other 1MB would be reserved for given purposes.
0
The difference is on whether the players download assets after launching game instance, or before.
If you make it available in-game, you can use the screenshot as asset in triggers and such. Yes, in this case players download the screenshots when they launch a game instance ( not waiting in lobby )
If you make it *not* available in-game, players download the screenshots *before* they launch a game instance because bnet has to display the screenshots on map info. Overall upload size won't be much different, because even if bnet is hashing every screenshot for comparison you'd still have to upload the file via editor. However in this case *players* wouldn't have to d/l screenshots when they launch a game instance, because the screenshots are not going to be used in the actual game.
0
I don't know if this tendency applies to all servers, but from what I've seen popular maps tend to stick with WoL because migrating to HotS would mean losing some portion of players. Instead HotS version of the map would be published separately.
0
BEHOLD!!!
0
Some sort of AI compensation would be nice. If players get trouble countering skill A but easily dodge skill B, then the boss would gradually use skill A more often. This can prevent the game from getting repetitive, when done well.
0
exactly. larger banks = more data per transmission.
0
@Enexy: Go
..wow. I didn't think about that.
If the number of dummy players are the same with the number of teams there shouldn't be any problem.
But what about those game types with no teams at all? Even for 15 player FFA at least one of the players have to attack his own unit.
and theres no bank limit in test mode 8)
0
@GizmoPT: Go
Fixed. I had to change the map name and publish it again.
Now published as "Sniping:Sniper" (without the quotes)
0
@GizmoPT: Go
I've checked it, and it's published as public. I can't search for it with "sniping" though.. strange.
It seems that having two or more locales with different map names is causing trouble. I can search for the name I've used in KR/TW publish, but not "sniping" or "sniper".
Here's link.
starcrft://map/1/205898it should launch SC2 and show the map info directly after you log into NA server.
and I'll publish to EU too, once I get this map name issue settled:) Thanks for notifying.
0
Sniping Sniper
Sniping Sniper is a simplified top-down view arena shooter, where your skills matter.
There is only one objective: survive.
Published on NA region as "Sniping:Sniper" (without the quotes)
Published on EU region as "Sniping:Sniper" (without the quotes)
Features
Comments
This map was originally published in KR/TW. Thanks to the Global Play feature, now I can translate my maps and publish to other regions. I'm looking forward to any feedbacks/suggestions/comments ;)
0
Too bad Blizz won't allow it..
I was thinking about the technical side, and to make MMORPGs with this there should be a way to go around the player limit.
What I mean, is if GameA has 14 players and GameB also has 14 players, to join them we need a way to simulate the ally properties.
Once GameA's player quota is full, any player's units from other gameB has to be assigned a controller, which all slots are already being used by GameA's players. If the joining units are assigned "Neutral" or "Hostile", its gonna put strict limits to the game types possible with this system.
0
Solved. the reason second case wasn't working for me was that I had some players set to non-random.
From Map >> Player Properties >> set *ALL* Race set to "Any"
..doing this made it go through the header transmission error. As SoulFilcher said removing other options in Game Variants forces all players to one value as intended, but it wont raise any header error if Player Properties races are all set to "Any".
Thanks for your help:)
0
I have no idea what's going on here, but here it is.
From Map >> Player Properties >> Race set to "Protoss"
When I publish this, Bnet says "Zerg". and I can't change it as its grayed out.
This also seems to cause the race setting in game variants unchangeable.
From Map >> Player Properties >> Race set to "Random"
..Now I can change the race setting in game variants.
From Map >> Game Variants >> Player Attributes >> Check "Zerg" "Terran" "Random"
This leaves only one choice, so the race is set to Protoss.
When I publish this, it fails in "Transmitting Header File". the log says "Variant definitions could not be validated".
is there any working way to set the lobby race to Protoss only?
0
THIS. NOW MMORPG IS POSSIBLE.
..sorry for all caps, but this has so, so much potential.
Battle.net currently has 14 player limit. Say game A starts with 10 players, and later game B starts with 7 players. (with the same map)
1. game A's trigger compresses all player data into bank, and external program sends it to game B.
2. game B's trigger then decompresses that data, and creates units / use ability / give orders to 'simulate' the game A's actual progress.
3. game B's trigger compresses all player interaction into bank, and external program sends it to game A.
...and so on.
the practical problem would be the delay between each transmission, the trigger would have to "compensate" the delay.
0
@Taintedwisp: Go
I didn't thought about private maps. Deleting a map would make the name unusable also.. Thanks for comment;) I guess I'll have to use a similar different name.