How do I pick all instances of a family near any instance of another family?

For reference, the families "UnitsandBuildings" and "Targets" are composed of the same objects, I have them this way so when they interact (combat) I can distinguish one from the other. As this is a real-time strategy game, hundreds of these instances could exist at the same time. This results in these pictured lines of code running hundreds of times every tenth of a second. Is there a way I can pick all instances of a family near any instance of another family without having a loop that runs 1000+ times a second?

I would think you could create a sprite that is the size of the range you want to have as an attack. You will do this for each different type of unit that will have a range.

Then you can have an overlapping and the forEach will be after overlapping. So it will only be on the units that are overlapped.

Hey, I'm curious why you want all families getting other nearby families every 10th of a second? Are you trying to keep a potential target list?

The only reason I wonder is because in order to provide an alternate method, I need to know the goal of the current code.

If you simply need every entity knowing about all other entities in proximity every 10th of a second... you probably are going to have to live with that. Either it won't be a problem and you are pre optimizing, or it already is. This could be an instance where you either have to compromise, find another solution (need to know goals to help here), or consider a more powerful platform.

The goal of the code is to determine whether a valid target is within range and then how to attack it. What it picks and how it responds depends on the target's distance and the Unit's attack type (range or melee) I guess I'll post the full section of code here since it of itself can't be usefully stolen. The 0.1-second condition was added purely to limit CPU usage because targets didn't really need to be checked 60 times per second.

I like the sprite idea; however, would the engine have to render the range sprites constantly? some units have a range of 1000 pixels, would that be a concern? If it is would the invisibility of the sprites stop the engine from rendering them?

The absolute Sprite box size only sort of matters. The sprite you use doesn't need to be rendered at all so that really doesn't matter. The thing that matters the most is going to be unit count and if you already are having trouble. As a matter of fact, I usually always use a number of collision sprites for overlap tests and never render them at all, but it can bog down with many units. If you are testing overlaps, construct has a decent algorithm for narrowing down the number of items it has to test. Obviously, the more items in collision, are then more items to test range against. But in no way is construct events going to be able to outperform behaviors. Likewise those will never beat unity or unreal.

This is a tough problem, and kudos for trying to build an RTS in c3. Unfortunately, if you are trying to build a massive RTS (on the scope of say COH, SC2, Supreme Commander), you probably can't. Not unless you are willing to compromise massively, build your own pluggins and behaviors, etc...

I advise you run alot of tests. Figure out what you NEED, and then determine how many units you WANT. Create some tests.

If you want 100 units per team and envision 4 teams possible to be built, then a simple 400 unit test map can be helpful.

Are you saying the loop is working though? Even if the picking is fixed, I don't think finding a path every tick is going to work. I would try and bring it to a more simple approach than what I'm seeing in the screenshot which is embedded chaos. Also I'm wondering why do you need 2 identical families? That was possibly the start of the problems.

To answer some questions:

1. The loop is working

2. The pathing does not occur in every tick. There are conditions carefully placed to ensure pathing only occurs when needed. The only exception is when a ranged unit is retreating, but the CPU usage is still heavily used when units are not near each other, and only the first half dozen lines of code run. This is because each of the 4 factions can have 120 combat units at a time, which means the loop could run 480 times 10 times per second which taxes the CPU even if every unit is sorted out within the first 6 conditions.

3. The different families are in place because the sprites are used by both factions. Therefore, if Unit A attacks Unit B, Both would be referenced in the same family, requiring local variables to be used to ID 2 entities using the same family. Instead, I have 2 separate families so both parties can be easily identified.

The scale of the game is pretty large. I asked about the feasibility of multi-player for a game of this size in another thread and was told it would likely be impossible to keep 800 sprites updated in real time. I eventually want to move out of Construct 3, as I want the game to be 3D eventually, and I keep getting the feeling the engine was not designed to run an RTS game.

I will try the spirtes idea and update back.

I implemented the sprites idea as pictured below. The CPU usage has fallen by half. It's not perfect, but it is likely as close as I can hope to get with the engine. Thanks for the ideas, if anyone sees a problem or inefficiency with the way I implemented it, please let me know.

To answer some questions:

1. The loop is working

2. The pathing does not occur in every tick. There are conditions carefully placed to ensure pathing only occurs when needed. The only exception is when a ranged unit is retreating, but the CPU usage is still heavily used when units are not near each other, and only the first half dozen lines of code run. This is because each of the 4 factions can have 120 combat units at a time, which means the loop could run 480 times 10 times per second which taxes the CPU even if every unit is sorted out within the first 6 conditions.

3. The different families are in place because the sprites are used by both factions. Therefore, if Unit A attacks Unit B, Both would be referenced in the same family, requiring local variables to be used to ID 2 entities using the same family. Instead, I have 2 separate families so both parties can be easily identified.

The scale of the game is pretty large. I asked about the feasibility of multi-player for a game of this size in another thread and was told it would likely be impossible to keep 800 sprites updated in real time. I eventually want to move out of Construct 3, as I want the game to be 3D eventually, and I keep getting the feeling the engine was not designed to run an RTS game.

I will try the spirtes idea and update back.

I posted this earlier, and it says it needs moderator approval, I'm unsure why, as nothing else in this thread did.

Does anyone know why this is happening?

When you use 2 families to determine factions surely you still have to use a variable to determine faction A and B because all objects are in both families and you would be picking all objects in the game when you say 'family' regardless of faction. So you just need one family with the instance variable for faction.

Not sure why your message needs approved, but in response:

Whoever said you can't run 800 sprites needs to qualify that statement. Construct can do Alot more than 800. I have a project with a customized version of box2d where I run 1000 physics objects in C2. C3 is even faster by miles. I imagine, with some smart optimization after you find bottlenecks, you could run 800 units around no problem. You can easily create 1000 objects with behaviors such as Car and not have a problem (i5 8th gen)

In my experience, construct is amazing and fast at small projects and prototyping. It is no slouch at rendering either. It begins to fail when you need to scale and that is more of a human problem than a construct problem. Part of this is that it is more difficult to do good "SOLID" event scripting and write reusable code across multiple projects in Construct. Behaviors and plugins become a good way to help solve this problem, BUT, if you are developing plugins and behaviors you can easily find that your time goes much further programing scripts in Unity or Unreal. A lot of useful OOP practices simply can't be done or taken advantage of in construct. Almost every major product I start in construct gets moved to Unity as soon as I have an idea for how the game feels and the relationships between objects. I once converted almost all behavior from events to scripts for optimization reasons, and used events for game manager stuff, but it would have been faster in unity.

When I start a new project and want to "SEE" things fast, I work in construct. When I want to structure logic and work on abstract stuff, and scalability.... I tend to fire up unity first. I have this weird draw towards Construct though. It makes me feel good working in it, even if I know I will switch later. If you know you are switching to something else after prototyping, then you don't need to worry about optimization at all right now.