Active object amount limit?

Definitely an interesting and worthy question - but one that is difficult to fulfill with a proper answer.
It doesn't directly depends on the number of objects - it depends on what you do with that objects.
Optimizations could give you a very good bost in a similar scenario with thousands of object - but only if you're doing something "wrong", which is hard to say...
Do you move all units at the same time (foreach loop on all objects?)
Do you handle units outside the window (if there are?)
Do you handle collisions / do so with "box" collision or advanced collision?
Builtin or custom movements?
Do you auto-pair health or add this on foreach loop?
What else do you do on each unit, every frame?
Could you consider splitting your units - like moving smaller "flocks" of them at time,
and/or skipping some frames to allow for system relief?
(like updating their infos -if applicable- every 10 frames would give you 6 times more headroom on 60FPS)
etc. etc. etc.

However, maybe a silly consideration here,
but that's an heck of strategy game with 2000 units and more in the playfield :O,
maybe you can still create "mass" effects with lesser units - in the order of the hundreds?
Semms more like a swarm than a strategy battle :o

Go to the Click Store and get Beetle Invasion. That will bring tears to your eyes and will help you. 2,000 units is a lot IMHO.

Marv

Do you say you want the 2000+ objects visible on the screen at the same time? If so, I think that's pretty unrealistic. But if this is a scrolling game and you mean 2000+ in total, as most of them will not be visible at the same time, you could make a system that destroys objects that are not visible, and recreates them when they are near visible zone. In short: any object that is not on screen or within player's reach should simply not exist. In order to accomplish this you must most likely organize the level in arrays that are divided into zones.

Quote from Bonehead

For the movement, yes and no. I was planning, that you could choose a mass from the horde of minions, select an attack point and then the mass will attack the target until they die/run out of ammo. So there would be a need to control many of them at once, but that need will not be anything recurring every 0,1 seconds but like 2, 3 times a minute. Since I know that a strategy game is a hard challenge as it is, I was planning to put the most weight of the strategy part on good attack direction choices rather than on very specific micro play.

Surely an interesting challenge.
Your "control" would be every 2-3 times a minute, to make them move,
this is not bad, as movement can be very expensive, depending on how you need to perform it
(if bouncing ball and no collision checks - you're pretty on the soft side anyway!)

But I guess Fusion would have to anyway handle their angle / shooting direction on every frame, even if static,
so you'll likely have to "foreach" them on a very frequent basis to update their direction
-calculate nearest enemy to each unit?-
Macro-units would make this last paragraph quicker, like calculating only one target for a "mass" of units, without taking into account each of them singularly.

Quote

There is no real need to handle units outside window. Also, units don't have to survive outside window to avoid units surviving outside play area.

so this is going to be a very crowded window!
But this is obviouly "good" for preformance, as you won't have to worry about hordes outside view area

Quote

I was hoping for them to have some collision understanding, but it doesn't have to be solid or anything highly advanced. (Like 1 out of 4 chances for a collision between two minions. With more than 200 objects, nobody can monitor their overlapping anyway so it shouldn't spoil anything). I was planning to use obstacle backdrops to help them maintain some sort of a path when attacking and kill any units outside window, since I planned minions to spawn constantly unless they reach a limit.

No collision would surely give you a good performance boost, and as you say, moving a horde could make collision checking pointless (if not against buildings)

Quote

Basic bouncing ball would be enough movement for them. Since they'd spawn constantly, I found a story way to make sure you can kill any minions that would otherwise get stuck or act erratic.

Good to know, bouncing ball is pretty lightweight and solid, one of the best among builtin movements.

Quote

Well, attacking and perhaps collecting would be enough for my plan. Like you may guess, I did realize already when I began planning a strategy game with Fusion 2.5 that there needs to be some limits to meet all the limitations. Maybe some orders would cause more advanced attacks, but those attacks would still rely upon easy bullet or animation means to happen. (Like a flamethrower or such made by animation/overlapping an object in stead of those small particles creating a flame effect.

Luckily limitations are not that many, Fusion can really keep on with your ideas if you learn how to deal with him,
it can happen that you may run into a very expensive way of doing something and seems it lets you down - but usually inspecting your code you can find bottlenecks and see i.e. that you don't really need al that "control" over that many things all the time.
You animation attacks, instead of particles, are going to be good idea imo!
Btw, many good "Particle animator" software exist and results can look very good (I recall someone suggested TimelineFX - and it indeed looks good!)

Quote

And it is true, it's a lot. I kinda was planning to maintain like 200-400 minion cap for teams 1 and 2, and possibly for a NPC 3 if needed story wise. The 2000+ hope comes more from the idea that you also need buildings and some active objects like bullets to make it work. I may have to do like you say and for an example create unit that has an animation of four minions to boost the numbers with less actual objects? Maybe shooting could also be an animation and when the shooting minion has a collision with something, I just kill the animation and start a "HIT" animation with the targeted unit to avoid the need of a bullet object?

Creating an animation of multiple units would surely help, i.e. reducing to 1/4 number of objects to move on screen
Shooting animation is also a very good idea to avoid countless bullets (and it's probably like many games do, to my knowledge, at least with very small projectiles that would be anyway hard to see)
Two very good ideas imo.
But you may even not need to run into all these optimizations from start, Windows runtime is quite powerful with active objects,
maybe do some quick test with the way you find more comfortable with and then start to think at it if/when things start to get bad! X)

Btw, I've checked Beetle Invasion, and it's very nicely done - and damn hard!
Died ten-fifteen times before even finding a very basic tactic XD

Im abit lazy at this moment in time, so i havent read throug all the posts here.

However, to maximize the number of Objects, i do have a smart idea ( forgive me if this is allready mentioned or not relevant ).

The idea is to only use 1 Object per Agent/ Enemy.
You do probably ( not nessesarily ) Detecors for your Agents, and theese can be embeded within the Age itself ( As a UserAnimation ).
However, switching to the 'Detector Animation' and back to the, for example, 'Running animation' will reset the 'Running animation' making it appear like the animation aint playing at all.
^ This isnt nessesarily a problem, as one could use an AltValues and manually create an 'Animation Speed/ Possition' variable acting as a stored anim speed that can be reverted to after Detector Animation changes back to whatever Animation was playing before. I havent done this before, but i am goin to try.

This is perfectly sensed,
I've seen this applied before as one of the "three" main solutions to the "different collision masks" problem/need,
I read this suggested by SolarB first time - crediting original idea to Muddymole - so I'd say this is solidly tested in Fusion

As you say, you can restore the animation frame by storing in values current frame prior to switching and reverting back after.

Though personally I've never used this solution much,
I think it could be very useful to halve object count, if you are going to need detectors.

Eh, you hit a hard wall here,
instance-to-instance interaction/scoping is a little convoluted in Fusion

this can be usually solved using a detector and foreach looping:

type 1 attacking
>>> count each one of type1, loop name "attack"

on each one of type1, loop name "attack"
>>> place "detector" on attackrangeX,attackrangeY
>>> set detector ID to fixed value "type1"
>>> set detector "do_damage" to type1_attack_damage
>>> start loop "test detection" 1 time

on loop "test detection"
+ detector overlapping "type 1"
+ type1 fixed value <> detector ID
>>> sub do_damage from "health"

but this could damage performances on high numbers of attacking minions

though simple boncing on collision still works on instance to instance

King_Cool that idea will work great. Just remember that animation changes suffer from the update lag bug, so changing detector size on the fly and colliding against other embedded detectors are a no-go.

Quote from casleziro

King_Cool that idea will work great. Just remember that animation changes suffer from the update lag bug, so changing detector size on the fly and colliding against other embedded detectors are a no-go.

I had to test this, and it doesnt seem to be the case.
There does not seem to be a lag with changig Animation Sequences.

See frame 2

Please login to see this attachment.

The blue and red box are visualizations of each object's embedded detector. As you can see, they're overlapping on-screen. But because of the animation lag, the actual collision isn't being registered. If you move the base objects closer together (for example blue up until it is overlapping red's hitbox) you'll see the collision register.

There's no way (outside of math to simulate them) to collide embedded detectors against each other. The objects will always be at least a frame out of sync and use one of the base object default animations as a collision.

Please login to see this attachment.Please login to see this attachment.

Now if you have no need for a second embedded/variable detector, then it's fine; changing a single detector to detect fixed objects or backdrops won't have any problems. That might be where you misunderstood me.

Ah i see

The Event:

ObjA overlaps ObjB = ObjBs 'collision mask' lag 1 frame behind for both ( #1 ) its possition and ( #2 ) its Animation

This is very good to know, i didnt know so thanks for pointing this out