You should avoid most WebGL effects, but some work just fine with minimal performance impact. I had a small list that work well in a post I made awhile back, but there's no real list stickied.

You just have to test on your device and see how the performance is impacted. Check the cpu usage with and without then compare it.

Sure is.

Find the Touch X & Y. Calculate the angle from Touch X & Y to the Object X & Y.

Then move that object in the direction of that angle.

If this doesn't make sense, you need to do more tutorials to understand basic concepts first. Good luck!

The way I understand it, is code on a sub-branch will fire at the same time. At least that is how it happens in my experience.

Every Tic

Do X

Do Y

Do Z

XYZ fire at the same frame.

Every Tic

Do X

Do Y

Do Z

XZ fire at the same time, then Y goes after X is done.

Are you checking cpu usage with debug/profiler or using the cpuutilization text?

It's due to your spray rate, each interval has a timer, and within that timespan if you car is moving really fast, it would be far in front. It's normal actually.

If you want accurate smoke trails, you have to adjust the rate to be dynamic, so a faster car will output more trails than a slower one.

It's nothing to do with PC speed.

In the meantime, just use separate turrets (or families of turrets) for player and enemies.

Is the particle a spray or one shot?

If its a spray, it should always be positioned to the car at that imagepoint.

If its a one-shot and there's a delay as you say, have a check for your car velocity, if its slow, then use an imagepoint where it looks right. If the car is moving fast, use another imagepoint towards the front of the car, so the particles look correct.

Yeah would be nice. Hopefully its not due to a technical limitation and can be adjusted easily.

The player can escape as soon as you change the instance variable on the player ship from IsVortex=1 to IsVortex=0. It will no longer be forced to be stuck to the vortex line as it spins and shrinks, able to fly away.

It will still be in range for the original distance check, since it would be less than 1600 pixels away at that point. So if you want to face away and fire afterburners, you have to do separate checks for angle vs vortex (within (vortex.angle -180) by 30 degrees), and if its within that angle and afterburners are fired, change an instance variable. So you need a new var for your ship, call it "IsEscaping=0", so when you want to escape and it fits the angle/afterburner check, change it to IsEscaping=1

In the original distance check, make sure you also add Player.IsEscape=0 so that distance check ONLY triggers when player is not trying to escape the vortex.

This kind of stuff is what I do for my own space game. I tend to always think outside the box and apply work-arounds for solving a problem, but it works.

Pathfind is not a good way to do something such as dynamic movement that needs to be constantly updated. The reason is each time you set a new destination, there's a delay, and it also is very costly to constantly update pathfind, especially if you have lots of deers.

So the bullet suggestions from the above or other ways is better.

Don't bother with KS unless you are willing to spend a lot of money on marketing it.

I've tested one just recently, no marketing $ spent, though I had a TON of offers as soon as the KS went live. Like constantly spammed by marketing companies who want to "help".

Without marketing and relying only on visits that are natural, from people browsing KS categories, I got bout 400 visits in 3 weeks. Successful campaigns get tens of thousands of visitors. Because only a small % of visits like your game genre and will back you.

It aint like what it used to be where back then, natural visits were the bulk due to KS being more popular and less saturated.

Since I suck at maths, I tend to solve problems visually and then implement that.

Here's what I would do.

1. Make an invisible sprite, as a long line, default 64 x 64 is fine. Set its Height to 10, Width 2* (whatever u want the radius of your vortex pull to be). So if you want it to pull when the ship is within 1600 pixels, make it 3200 pixels.

2. Make the point of origin in the center. Add 1 more image point, at the tip of the line, or (32,64) coordinates.

3. Give it the behavior Rotate. Set it to whatever speed that you want the vortex to look like.

4. Give the vortex line an instance variable "IsActive=0".

5. Give your ship an instance variable "IsVortex=0".

6. Do your distance check, when the ship is <1600 distance, set the ship instance variable IsVortex=1 and Pick the Vortex Line Nearest to Ship.X & Ship.Y (so it filters out only that vortex its close to), and set the instance var IsActive=1. Also, set the angle of the Line Vortex towards the position of your ship (X,Y) so the line will instantly point to "touch your ship".

Now, both ship & vortex will have their instance variable flagged to 1, we consider that On/Active.

7. Do a check for your ship, if IsVortex=1, set it's position to another object, the Line Vortex at image point 1. This will cause the ship to be "stuck" to the line vortex. Now the line vortex is rotating and the ship gets dragged with it, spinning around your vortex.

If there's multiple vortexes, simply do a filter to pick by evaluate VortexLine.IsActive=1 so the ship only attaches to the currently active vortex.

How to get it to spin closer and fall into the vortex?

8. Do a check for your vortex line, if IsActive=1, set its Width to be Self.Width * 0.95 (or whatever speed you want, a lower number will suck the ship in faster).

Done, visually it works exactly like a vortex sucking in your ship if it gets too close.

There's probably a much shorter way to do it with a math formula, but this works and doesn't use much CPU calculations, it's simply a re-sizing of a spinning line's width.