How do I make a dynamic 'frontline'?

This is pretty hard to explain but I am making a game that is loosely inspired by this animation:

The part that I am concerned with right now is the quite literal front line. The main two parts of this that I need to figure out are #1 how do I make it so a sprite moving into it shifts that part of the line backwards? and #2 how can I make encirclement manuvers work (if the line intersects itself, it connects creating an encircled area in the process). Any ideas?

You're probably on the right track for a way to do that. Basically, drawing to a 2d grid and then looping over it to find the edges.

Your screenshotted events aren't working because you first pick one point, but you can't pick the second point when the first is already picked. A quick fix would be to add a "pick all point" condition after the finding if the point was blue.

You're probably on the right track for a way to do that. Basically, drawing to a 2d grid and then looping over it to find the edges.

Your screenshotted events aren't working because you first pick one point, but you can't pick the second point when the first is already picked. A quick fix would be to add a "pick all point" condition after the finding if the point was blue.

It seems to be working; Thank you! The only issue now is that it is insanely laggy. Any ideas on how to optimize this?

You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p

That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

https://www.dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p?rlkey=x69nftupmwepk22idoycmf8vj&st=uhxgwm1i

That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

Thanks for the tips. I might try some of those out too, but I just found another way as well; I just pinned a box to the player and used some code and parameters to only update the frontline in that box. It's a huge improvment already.

> You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

> dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p

>

> That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

Thanks for the tips. I might try some of those out too, but I just found another way as well; I just pinned a box to the player and used some code and parameters to only update the frontline in that box. It's a huge improvment already.

It seems that this optimisation causes a bunch of points around the edge of the square to not appear properly. I'm not sure what could be causing that, but I'm working on a fix.

> > You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

> > dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p

> >

> > That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

>

> Thanks for the tips. I might try some of those out too, but I just found another way as well; I just pinned a box to the player and used some code and parameters to only update the frontline in that box. It's a huge improvment already.

>

>

>

>

>

>

It seems that this optimisation causes a bunch of points around the edge of the square to not appear properly. I'm not sure what could be causing that, but I'm working on a fix.

I still haven't found a solution to this. Could anyone help me out? I can upload the file if you need it.

Well, I found a fix. Let us never speak of this again.

Now to write an algorithm to connect the dots...

You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

https://www.dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p?rlkey=x69nftupmwepk22idoycmf8vj&st=uhxgwm1i

That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

Ok so it works and runs great now with only 1 unit attacking, but with multiple attacking at once it seems to glitch out a bit and not show them properly. I can only think of 2 reasons for this; Either running the function twice at once is problem for some reason or it is a performance thing. Assuming it is the latter, do you mind elaborating a bit on your array idea, (assuming it is compatible with my update box technique) R0J0hound?

I just mean instead of creating all those sprites in grid positions and then picking them later, you could just set values in a 2d array and be able to access grids directly without picking. Its main con is it’s less visual than using sprites.

Other than that the general logic should be the same. Updating only the parts that change instead of the whole thing is a decent idea to make it perform better.

I don’t have much input about what may be amiss with your event logic though. It’s kind of a more hands on thing and I presently don’t have a whole lot of time for that.

> I just mean instead of creating all those sprites in grid positions and then picking them later, you could just set values in a 2d array and be able to access grids directly without picking. Its main con is it’s less visual than using sprites.

> Other than that the general logic should be the same. Updating only the parts that change instead of the whole thing is a decent idea to make it perform better.

> I don’t have much input about what may be amiss with your event logic though. It’s kind of a more hands on thing and I presently don’t have a whole lot of time for that.

I see... thanks for the response! Edit: after looking into it more it doesn't seem to be a performance issue anyway. I think my code is just busted.

Hmmm... okay, so the issue seems to be caused by multiple things:

1) I had it wait a seemingly insignificant time before calling the DrawLine function, but forgot that I set the time scale way lower since then. Making it wait 0 seconds makes the stuttering problem way better.

2) It actually does seem to partially be a performance thing. Lowering the time scale more helps a bit, but still doesn't completely eradicate the issue.

By now it doesn't seem to miss any points, but it can still stutter for a second. Good enough I suppose.