Unit limit in a map?

[Mufanza]

So I've been playing some maps over Garena the other night and this is what I noticed in some of them: once there's too many units in a map, they will become unresponsive. Orders ordered to this many units might get delayed even for a few seconds before finally operating and this also applies to orders activated through triggers. Also, units ordered to move long distances stops randomly on their way.
So I'm wondering: how many units exactly does a map need to start being unresponsive like this? I've created a dummy map to test this and I've been able to get unit count to over NINTHOUSAAAAAND without having the problems described above. Then I gave up. Sure, the map was lagging, but there was no delay in orders.

So, does this happen only in multiplayer, or do I need even more units to delay my map like that?

 

[Hashjie]

So I've been playing some maps over Garena the other night and this is what I noticed in some of them: once there's too many units in a map, they will become unresponsive. Orders ordered to this many units might get delayed even for a few seconds before finally operating and this also applies to orders activated through triggers. Also, units ordered to move long distances stops randomly on their way.
So I'm wondering: how many units exactly does a map need to start being unresponsive like this? I've created a dummy map to test this and I've been able to get unit count to over NINTHOUSAAAAAND without having problems described above. Then I gave up. Sure, the map was lagging, but there was no delay in orders.

So, does this happen only in multiplayer, or do I need even more units to delay my map like that?

When there are to many units in game your game can start lagging because of excessive usage of RAM memory of the player. In order to reduce the amount of units in your game it is advised to remove the unit from the game. Units will be automatically removed from the game after 60 seconds of decaying (corpse lying on ground when the unit dies). You can also try the following: remove all killed units from the game so that no units will start decaying for yet another 60 seconds before it is completely removed. You can also add an expiration timer to killed units in order to reduce the decaying timer.

It might also be that the game you where playing contained a lot of memory "leaks" caused by locations not being removed. Which can cause lag after a certain amount occurences.

You might also want to check out this tutorial: http://www.hiveworkshop.com/forums/miscellaneous-tutorials-456/about-movement-172309/
GUI orders can be interrupted that's why using Jass is a way better option for this, check out the tutorial it can help you a lot...

The GUI function interrupts orders, while SetUnitX/SetUnitY doesn't, which is most of the reason why it is preferred. ;D [Although, yes, SetUnitPosition is definitely slow as well]

The first post in that tutorial

 

[Mufanza]

Eh, well, thanks for the reply, I guess... But that has nothing to do with what I asked

You see, my map is not in the state of debugging yet - I'm currently just designing it. I would like players to be able to train as much units as possible, but of course, not for the cost of making the map unplayable.

Therefore, what I'm looking for is more like exact numbers of how many units can I have in map before it becomes delayed like I described.

 

[Hashjie]

Eh, well, thanks for the reply, I guess... But that has nothing to do with what I asked

You see, my map is not in the state of debugging yet - I'm currently just designing it. I would like players to be able to train as much units as possible, but of course, not for the cost of making the map unplayable.

Therefore, what I'm looking for is more like exact numbers of how many units can I have in map before it becomes delayed like I described.

There is no such number because that depends on the RAM memory of the player as I described.
The more RAM memory a player has, the more units he/she can handle inside a game.
As I've described above there are ways of reducing the amount of units in your game without actually removing any currently alive units in your game...
To make it playable I suggest removing any killed units (if you can't live with that since you have summoning skills that depends on unit corpses then I suggest you to take down the decay timer of units in order to remove corpses which are still inside your memory,
the default is 60 seconds before they are removed. This way the units that are removed can be replaced by newly spawned ones.)

The tutorial I send you was about units not doing what they are supposed to do as you've asked.
This is because the GUI function can interrupt orders of units that's why I referred you to that tutorial...

The delay you've had is caused by excessive RAM memory usage since there are either to many unit's inside your game or to many memory leaks.
A workaround would be: buying more RAM memory or removing all leaks and reducing the amount of units inside your game as I've described above.
In your situation it might be that the creator of the game has a lot of memory leaks + to many units inside the game, causing you to get delay.


I hope this helps in explaining the situation.

Creating a dummy map to recreate the problem would mean you'd have to spawn massive amount of units and create lots of memory leaks. Do this every ... seconds and your good to go, your computer WILL lag like hell

(Use at your own risk)
Example:

• Creating leaks and some units
  • Events
    • Time - Every 0.30 seconds of game time
  • Conditions
  • Actions
    • Unit - Create 1 Peasant for Player 1 (Red) at (Center of Region 000 <gen>) facing Default building facing degrees
    • Unit - Order (Last created unit) to Move To (Center of Region 001 <gen>)

• Massively spawn units
  • Events
    • Time - Every 0.30 seconds of game time
  • Conditions
  • Actions
    • Unit - Create 100 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees

 

[Dr Super Good]

Units become unresponsive when the rate the game engine can generate mini-move orders becomes less than the rate that units are finishing the mini-move orders.

You can have 10 units all moving at once or 1000 units with 10 units moving at once but in both cases units will respond perfectly.
You can have 100 units all moving at once or 1000 units with 100 units moving at once but in both cases you should start observing responsiveness problems.
If you have 1000 units moving at once responsiveness will be a major problem.

Mini-move orders complete when eithor the desternation is reached or if it collides with another unit. As such you can easilly support 300-400 units moving at once if you turn off their collision but with huge collision in small corrodor terrain you will be lucky to reach 50.

Each player is given a mini-move atleast once every game frame. This means that you can use multiple player slots at once to allow more units to move at the same time.

SC2 does not have this problem as it evaluates mini-moves as nescescary. It does exhibit strange movement patterns at times though.

 

[Hashjie]

Units become unresponsive when the rate the game engine can generate mini-move orders becomes less than the rate that units are finishing the mini-move orders.

You can have 10 units all moving at once or 1000 units with 10 units moving at once but in both cases units will respond perfectly.
You can have 100 units all moving at once or 1000 units with 100 units moving at once but in both cases you should start observing responsiveness problems.
If you have 1000 units moving at once responsiveness will be a major problem.

Mini-move orders complete when eithor the desternation is reached or if it collides with another unit. As such you can easilly support 300-400 units moving at once if you turn off their collision but with huge collision in small corrodor terrain you will be lucky to reach 50.

Each player is given a mini-move atleast once every game frame. This means that you can use multiple player slots at once to allow more units to move at the same time.

SC2 does not have this problem as it evaluates mini-moves as nescescary. It does exhibit strange movement patterns at times though.

Holy **** this is some usefull information! 0.o I didn't know, thanks!

Are there any work-arounds for this yet or do we have to just deal with this?

 

[Mufanza]

Dr Super Good: That explains why my test ended with such results, thanks a bunch!
So I could set this to solved by now, but this actually caught my interest as well as Hashijie's.
Why does it create a mini-movement once the unit reaches the destination?

 

[Hashjie]

I would also like to know if this counts for player interaction.
For example: I have 100 units moving around through triggers,
I order 10 units to move by moving it my self as a player.
Would this mean that there are going to be responsiveness problems?

In general: when are mini-move orders generated?

So what if I created a script that stops movement for the recent move orders when the maximum amount of move orders for a specific player gets exceeded?
Would this solve the problem? And what would be the exact amount that shouldn't be exceeded?
For example: What if I store the amount of move orders given to a player's units.
Would I be abled to see if these limits get exceeded and then stop movement for this specific player untill these values decrease?

Is there a way of detecting the amount of move orders of a player?
Even though this might not be such a solid idea since limitting movement of units for a player can be a pain in the @ss for the player.

 

[Dr Super Good]

Why does it create a mini-movement once the unit reaches the destination?

It does not, it perodicly creates them for every unit that is "moving". A unit is moving when it is in motion or trying to get into motion.

With a small number of units the mini-moves will be issued before previous mini-moves complete. With large numbers this is impossible.

Mini-moves are basicly a short distance movement order which tells the unit to move in 1 direction until a point.

The process of generating mini-moves is every frame, pick the next 2 elements from the lists of units owned by each player and then generate a mini-move for them.

SC2 (StarCraft II, the lattest RTS from blizzard) does movement differently in that it generates mini-moves as nescescary using a very different and likly less demanding system (you can see that the pathing in SC2 is very erratic at times when avoiding unpathable patches).

I would also like to know if this counts for player interaction.
For example: I have 100 units moving around through triggers,
I order 10 units to move by moving it my self as a player.
Would this mean that there are going to be responsiveness problems?

There is a difference between the 2? As there is not that is your question answered. Triggers generate orders just like players interacting with the game interface do.

 

[Mufanza]

Thanks once again. One last querstion: Is it right to assume that units in Wind Walk generate as little mini-moves as units without collision?

 

[Hashjie]

Thanks once again. One last question: Is it right to assume that units in Wind Walk generate as little mini-moves as units without collision?

I anticipate that it works as followed:

When the unit collides with another unit, meaning that if there is collision between the two units then the mini-move order will be completed.
If wind walk has no collision meaning that a unit with wind walk can move through other units, then the mini-move order will be completed as soon as the unit reaches it's destination.

I don't really understand this part though:

As such you can easilly support 300-400 units moving at once if you turn off their collision but with huge collision in small corrodor terrain you will be lucky to reach 50.

How can it support more units moving at once when there is no collision? Wouldn't this mean that there are in fact more mini-move orders then when there is collision, since the mini-move order will be completed when the unit collides with another unit?

Nevermind, I didn't read this part carefully enough:

With a small number of units the mini-moves will be issued before previous mini-moves complete. With large numbers this is impossible.

So: the longer the distance is that the unit has to travel the better?

 

[Dr Super Good]

Is it right to assume that units in Wind Walk generate as little mini-moves as units without collision?

They should. When units collide their current mini-move order is disrupted instantly and they come to a stop until they get allocated a new mini-move. This results into the chaining that occurs when movement is overloaded.

How can it support more units moving at once when there is no collision? Wouldn't this mean that there are in fact more mini-move orders then when there is collision, since the mini-move order will be completed when the unit collides with another unit?

Because they all can complete the mini-moves before they stop moving. Otherwise the mini-moves are interuppted prematurly (before they reach their target) by bumping into another unit. As mini-moves are issued at a fixed rate the optimum will occur when all mini-moves complete fully and none are interrupted prematurly by unit collisions.

What also plays a role is the terrain itself. More complex pthing patterns nearby result in smaller mini-move orders (they are ordered less distance away) than in large open pathing spaces. It TDs you can clearly see this where open mazes can often support 100s of units from the same player moving at once while in a RTS game like some stupid castle siege you will only be able to manually control about 4 squads moving at once before they become unresponsive (as they start to collide with each other).

 

[Hashjie]

Thank you for the elaboration. I fully understand now.

 

[Mufanza]

Another thing has crossed my mind:

Each player is given a mini-move atleast once every game frame.

So, let we say one player tries to move 300 units in a small corridor, while other players have 1 moving unit somewhere else on the map. Does the unit-response delay take place only for units of the player who has exceeded the limit, or will all units become unresponsive?

Also, if I understand that sentence well, you can use share-units to have more units move around the map without response problems?

 

[Dr Super Good]

Does the unit-response delay take place only for units of the player who has exceeded the limit, or will all units become unresponsive?

You just quoted the answer... The 1 player's units would be unresponsive while the other player will be highly responsive.

If I recall units in combat (being shot at and trying to get in range of the attacker) might cause them be be issued additional mini-moves but I am not sure. Usually maps in this state are unplayable or shortly won.

 

[Mufanza]

You just quoted the answer...

Yep, but I just couldn't believe my luck
You see, now I can just give all those masses of units to a computer player... Yes, they will be unresponsive for him, but it doesn't matter since they're just supposed to wander aimlessly around the map...

So yeah, thank you once again, you've been a great help!

Just one little last question if I may: are there any other downsides for having so many units move at once? Is there any other reason why I should avoid having so many units in my map at once, since the unresponsiveness is no longer an issue?