Most of these have changed a few times already and/or are hard to define. The only one I (think I) know is the bank size limit, which is 8KB per player (If you're doing only singleplayer, there is no limit. >8KB causes problems if there are multiple players as different banks start overlapping or something like that, but if there's only one player that can't really happen. Also, the reason I put "player" in italics - You can have multiple banks per player, but the 8KB limit is for all banks put together for each player.)
For the script and memory limit you'd have to ask someone else. As far as I know, one of those (maybe both) have been increased by 4x in 1.5
According to that, the reason >8KB maps don't work is because data from different players begins overwriting. If you only have one player, there simply won't be any data that can overwrite his.
- Thousands of snapshot actors (like building images in the fog) create lag (Disabling visibility of not in that moment required actors fixes that. To recover them, make them visible again.). 9000 is to much. Actors with a model in general could create that lag, too.
- Thousands of units will eat up a lot of FPS. 15k is the limit I think. You shouldn't really come close to that limit. Store the information of not required units in the global data table and recreate them, when required.
- 256 x 256 map size is max.
- Zooming in the camera creates non-visible/reachable areas at the sides of the map. The camera will hit the boundary even if you can't see anything close to it. You can even create a paradox where a wide-screen sees less than a normal aspect ration. If your camera always follows a unit, you can try to improve the situation by raising the followed unit into the air via unit height and lower its actor back to the ground via site operations.
- Thousands of snapshot actors (like building images in the fog) create lag (Disabling visibility of not in that moment required actors fixes that. To recover them, make them visible again.). 9000 is to much. Actors with a model in general could create that lag, too.
- Thousands of units will eat up a lot of FPS. 15k is the limit I think. You shouldn't really come close to that limit. Store the information of not required units in the global data table and recreate them, when required.
- 256 x 256 map size is max.
- Zooming in the camera creates non-visible/reachable areas at the sides of the map. The camera will hit the boundary even if you can't see anything close to it. You can even create a paradox where a wide-screen sees less than a normal aspect ration. If your camera always follows a unit, you can try to improve the situation by raising the followed unit into the air via unit height and lower its actor back to the ground via site operations.
Nobody will ever reach the script size limit once 1.5 hits. (SCU @ 20% :D)
Memory limit is pretty big aswell, you will most likely never touch this.
Is the memory limit added up between all players in the map? Like let's say the map allocates an array of 100,000 integers and 15 human players. Will the map run into problems?
Dr. SuperEvil is right- those tend to be the most limiting factors. As long as you plan around limitations and don't give up easily, you can do quite a lot. That said, I'll throw out some of the limitations I'm aware of:
Map Size limit (256 x 256) can't be increased
Banks can not exceed 8kb of data (approximately 8000 characters) per player in a multilayer game (I believe the problem may disappear in single-player games, I'm not sure though)
You can't have a map file size over 20MB, but that can be avoided through the use of dependencies (each of which can have up to 20MB of data and does not count toward the map size)
There is a memory limit, though I'm not entirely sure of what it is. It's mostly related to your global variable count. You are very unlikely to hit it unless you're using some extremely complex triggers that require a TON of variables, like in the case of mafia.
Having too many units on-screen at once can cause problems, though the limit is extremely high (At the very least in the 1000's, I'm almost positive it's much higher). You shouldn't run into any issues here.
Finally fixed certain problem related to going over 8kb of limit per player. That kinda would explain a lot about decks not entirely loaded right. Same with achievements and EXP.
But yeah back then when I asked of help more than once. I was unaware of certain unpopular thread related to 8kb limit.
On positive side, forcing deck sizes to certain maximum should not hinder designing of decks that much.
Found a topic from 2010 that says there's a 10,000 doodad limit. Don't know if Blizzard increased the limit since then. 10k doodads seems overkill for a map anyway but it doesn't seem too far-fetched for a large RPG map with pretty visuals.
http://www.sc2mapster.com/forums/development/map-development/10422-doodad-limit/
I would just like to add that there is a doodad limit in the editor. Whenever you place more doodads than the limit, upon saving and re-opening your map, the editor will just delete a bunch of the doodads (without telling you) putting you back at the limit. I think it's 10,000.
The map I am currently working on had a heck of a lot of trees. Trees are 1x1 and I was liberal in my placement. So I made all the trees 2x2 which cut the number of doodads I used in half XD
Something like script limit, bank size limit, memory limit, etc. All things to consider when designing for a large ambitious project.
I'll start with a list based on 1.5:
I say the top two limits are your imagination and your time.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
@tordecybombo: Go
Most of these have changed a few times already and/or are hard to define. The only one I (think I) know is the bank size limit, which is 8KB per player (If you're doing only singleplayer, there is no limit. >8KB causes problems if there are multiple players as different banks start overlapping or something like that, but if there's only one player that can't really happen. Also, the reason I put "player" in italics - You can have multiple banks per player, but the 8KB limit is for all banks put together for each player.)
For the script and memory limit you'd have to ask someone else. As far as I know, one of those (maybe both) have been increased by 4x in 1.5
There's no bank limit on single player playing on battlenet?
@tordecybombo: Go
http://www.sc2mapster.com/forums/resources/tutorials/28875-trigger-bank-facts/
According to that, the reason >8KB maps don't work is because data from different players begins overwriting. If you only have one player, there simply won't be any data that can overwrite his.
Here a few I experienced with my diablo map:
- Thousands of snapshot actors (like building images in the fog) create lag (Disabling visibility of not in that moment required actors fixes that. To recover them, make them visible again.). 9000 is to much. Actors with a model in general could create that lag, too.
- Thousands of units will eat up a lot of FPS. 15k is the limit I think. You shouldn't really come close to that limit. Store the information of not required units in the global data table and recreate them, when required.
- 256 x 256 map size is max.
- Zooming in the camera creates non-visible/reachable areas at the sides of the map. The camera will hit the boundary even if you can't see anything close to it. You can even create a paradox where a wide-screen sees less than a normal aspect ration. If your camera always follows a unit, you can try to improve the situation by raising the followed unit into the air via unit height and lower its actor back to the ground via site operations.
interesting
Nobody will ever reach the script size limit once 1.5 hits. (SCU @ 20% :D)
Memory limit is pretty big aswell, you will most likely never touch this.
Any notable data limits?
Is the memory limit added up between all players in the map? Like let's say the map allocates an array of 100,000 integers and 15 human players. Will the map run into problems?
@tordecybombo:
If you are scripting in GUI, the player count should not effect the memory limit.
The editor automtically initializes arrays with default values.
Still say my two points will be the most likely to be breached first.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
@DrSuperEvil: Go
Dr. SuperEvil is right- those tend to be the most limiting factors. As long as you plan around limitations and don't give up easily, you can do quite a lot. That said, I'll throw out some of the limitations I'm aware of:
I agree, but I'd be nice to know the technical limitations of an SC2 map as well.
THE Card Game and THE Deck Builder, yeah.
Finally fixed certain problem related to going over 8kb of limit per player. That kinda would explain a lot about decks not entirely loaded right. Same with achievements and EXP.
But yeah back then when I asked of help more than once. I was unaware of certain unpopular thread related to 8kb limit.
On positive side, forcing deck sizes to certain maximum should not hinder designing of decks that much.
What about point, region, and doodad limits?
Found a topic from 2010 that says there's a 10,000 doodad limit. Don't know if Blizzard increased the limit since then. 10k doodads seems overkill for a map anyway but it doesn't seem too far-fetched for a large RPG map with pretty visuals. http://www.sc2mapster.com/forums/development/map-development/10422-doodad-limit/
Quote from DrSuperEvil:
Still say my two points will be the most likely to be breached first.
True story.
That's giving too much credit to the editor. The editor is good but it's not that good.
@Karawasa: Go
I would just like to add that there is a doodad limit in the editor. Whenever you place more doodads than the limit, upon saving and re-opening your map, the editor will just delete a bunch of the doodads (without telling you) putting you back at the limit. I think it's 10,000.
The map I am currently working on had a heck of a lot of trees. Trees are 1x1 and I was liberal in my placement. So I made all the trees 2x2 which cut the number of doodads I used in half XD
If you can find a way I can store thousands of heavily randomized items within the 8 KB bank limit I will agree with you.
Speaking of banks, you cannot load an individual string that exceeds 781 characters.