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.

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.

It could be the screen size has changed and the text is wrapping around around. I'm thinking of HTML / CSS wraparound problems in the context of web dev, so this might not be accurate, but something to consider.

Do you have a picture you could share?

I understand you have a gameboard and need the actors to stay on their paths?

If this is the case, I would use a graph structure where the guards move along edges between nodes in the graph. You could roll your own plugin to store a graph tree, use the editor, or build up waypoints using plopped gameobjects and use the "moveto" behavior.

If you have other behaviors or custom movement already controlling the guards, then simply use some game objects for the catwalk itself or the boundaries. You can text for collisions (overlaps) and then provide logice for the guards to go a different direction.

Do you already have in mind how the backend communicates with C3 (custom plugins or the like?)

I'm not sure you can do that, if I understand correctly. You can of course, use data you create anything from a csv, to json, etc... and save to locations etc...

Are you trying to create a data and then save those datas into the game so when it is exported its all together?

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.

Heloha,

I'm mostly familiar with c2 scripting environment. I was digging through the sdk for c3 trying to understand how one behavior might access another on the same object or different object. I think I was told that this is not allowed but wanted to confirm.

An example use case is Solid/Platforming behaviors. My use case is creating relationships between different types of components such as Stats, stat modifiers, etc...

Cheers

I would also add there are many tedious things about adding variables or behaviors to game objects. Adding alot, making changes, removing them etc... So tedious I usually create new behaviors to add variables in bulk when I need many. At that point I usually just switch to unity, because scripting in unity is faster than making new behaviors...

When you click to add a new game object, a dialogue opens that is focused. Without clicking anything, you can simply type the type of object you want to add and hit enter. This is fast and should be the model for how other dialogues behave.

This contrasts with adding behaviors and variables to an object, which don't follow the same flow. After clicking either of those you have to then click into the new popup window. The dialogue should already have a button that is autofocused so you can just hit enter, type in the of the behavior and enter, but it doesn't.

Instead, you have to use the mouse longer than is needed, click more than is needed, and travel the length of the screen. This makes creating objects and adding needing behaviors tedious for no reason.