Slow spawning system

Hi there,

I built a spawning trigger system that creates enemies from invisible placeholders/locators when the player collides with a trigger.

When all spawned units of this 'wave' are dead I execute a couple of actions, like opening a door, enable another trigger and such.

But the system creates a noticeable hitch the moment the enemies are created and I don't get why.

On collision with trigger:

pick locators instances tagged with trigger's UID (repeat for each enemy/locator type)

destroy locator

spawn unit (only turret part of the enemy)

store enemy UID in array (to check if wave is defeated)

On enemy created:

container creates missing body object for turret

add obstacle and targets for behaviours

pin turret to base

store parent/child UIDs per object

Can anyone see any inherent issue or performance killer in this so far?

On a side note: going through all instances of an object only concerns the one in the active layout, right?

First question would be how many are you usually creating at once?

Second question would be are you using a 'for each'?

Side note answer: anything on a different layout should have no affect on current layout

I notice the hitch regardless of how many enemies I spawn in a wave.

A wave contains anything from 1 to 20 enemies of different types

A level will probably contain a 100 to 150 enemies

I tried

For Each: Locator_typeX->System: Compare Variable

as well as

Pick by evaluation: Locator.TriggerID = Trigger.UID

without a noticeable difference.

Creating a lot of objects at once is intensive. I think you should be able to create around 20 without getting a 'hitch' though. Is 'the hitch' on everything, so lower FPS? Or are you only noticing it affect the new objects?

One thing I would try is make a txt box (or use console.log) and append text on every part of event ("loop started" "variable checked" "instance created", etc etc, whatever descriptors you need to identify). Then you can see if certain events are running more than necessary. For example, if you used 'on created' -> 'for each' then if you create 20 enemies at a time you are running that loop 20 times when you only need to run it once. If you have 100 spawnSpots to check that is 2000 checks when it should only be 100. That could cause a 'hitch'

yes and that's what's odd, cause it also stutters when i spawn a single guy. proper freeze on the whole app.

check here - earliest occurence is when that first drop pod creats the single enemy:

https://www.scirra.com/arcade/action-ga ... 10787?cp=3

I had that suspicion of unnecessary embedded loops as well and I'm somewhat confident that i earsed all likeliness for that by now.

Could the container spawning the bases for my turrets be a performance strain?

add obstacle and targets for behaviours

Obstacles? Explain ?

Can you post screen shots of the events you are referring to?

I still have a feeling something is more CPU intensive than it has to be

99Instances2Go you know, adding obstacles for Los- and pathfinding behaviors.

Now that you address it ... I add those to the Enemies family OnCreate of each enemy instance. Is that even necessary or should it be enough when instancing that family for the first time only?

— the whole thing goes through a number of steps, trying to catch all that matters:

spawning all enemies whose locator is tagged to the current trigger, setting a few vars, disabling the trigger after that.

tried 'pick by evaluate' instead of loop too, no difference.

setting obstacles and targets for behaviors onCreate of instance

also setting an inital distance to player - later updating every 0.1 second

could this be expensive?

the initial starting point of the enemy state machine

(not doing very much anymore at this point tbh)

you know, adding obstacles for Los- and pathfinding behaviors.

There is a deep logic in C2. A lot is very similar.

There are actions that take time, some even more time then 1 tick. 'Find path' is one of those. That is why you have the 'on path found' conditions. Same Ajax actions. You have the 'on completed' conditions.

But, there are also actions/conditions that take a lot of time, but stay in the SAME TICK. The obvious loop conditions, by instance. You will not find a 'on loop completed condition'. Same logic goes for adding obstacles. You will not find a 'on obstacle map completed' condition. Hence, it happens in the same tick. If the generation of the obstacle map takes 5 seconds, the tick will rest for 5 seconds.

The obstacle map is build on the end of the tick. And is therefor available in the tick after you initiate the action.

But it gets 'worse'. There are obstacle maps that you dont realise. Like that one associated with the platform, to map the solids. And there is only 1 obstacle map for all instances with a paltform behavior. This is by design, for performance issues (those you try to obey, but it is impossible)

Also pathfinding has 1 and only 1 obstacle map for all instances of an object, with the bahavior attached. Change the obstacle map for one, and you change it for all. Same goes for LoS.

So, given that creating obstacle maps take time, that they happen in the same tick and that there is only 1 obstacle map ..... and If you use a loop to assign obstacles .. then .. i say ...

1/ the time for that one tick gets really long

2/ the pathfinders in that same tick start as there are no obstacles

3/ its a little dumb, do assign obstacles 1 (and only 1) time after all objects are in place

3/bis Attention with the 'newly created objects théorème'. You have to make a new Top-Level_Event to pick them.

I don't have time to dive into this at the moment but one thing stuck out to me, probably isn't causing the 'hitch' but:

Both of those 'for each' will occur every tick that the player is overlapping an active spawnTrigger. Even if you disable the spawnTrigger in a subsequent event I would still test that out to see how many times it runs. Maybe a 'trigger only once' would take care of it but would definitely test that out.