To further clarify, I have created images showing how the AI should behave according to certain conditions:

<img src="http://i.imgur.com/eNay9B6.png" border="0" />

In the situations above, even if the player turns, the AI should still end up positioned behind the player or head-on with the player (the latter of which causes the AI to enter 'fire' mode and try to just shoot down the player).

This implementation should be easy - just have pathfinding find an optimal path to the player's current position.

<img src="http://i.imgur.com/dj1TRrB.png" border="0" />

If the angle from the AI's position to the player is less than 45 degrees, the best course of action is to simply engage the player since the player is most likely going to be attacking the AI ship soon.

So the hard part now is determining the perpendicular position.

Once this is all set up, it shouldn't be too hard to set up a random counter to make the AI ship run away sometimes as well.

The question is: How do I determine the 'spot' mathematically?

I had typed up all my notes, but the 'Authorization Error' I seem to get every now and then on this forum happened, and I'd rather not type it all up again (why isn't this fixed?).

Here is a brief version of my notes on this.

Two States:

-Move (starting state)

-Fire

Fire:

-If in Fire, set variable PredictedFiringAngle = angle(Self.X, Self.Y, Player.X, Player.Y) + asin((Player.Speed * sin(angle(Self.X, Self.Y, Player.X, Player.Y) + 180 - Player.MovingAngle))/ SelfBullet.Speed)

-Update this variable before every fired shot

-If Player is within 50 pixels of self, do not end this state, instead just keep firing at the object's fire rate

-If Player's angle = angle(Self.X, Self.Y, Player.X, Player.Y) + or - 10 degrees for 1 second or more then Player is facing the AI and the AI should turn and fire back.

-If Player is beyond 50 pixels of self, set state to Move after several shots

Move:

-If Player's angle = angle(Self.X, Self.Y, Player.X, Player.Y) + or - 10 degrees for 1 second or more then Player is facing the AI and most likely firing, so enter Fire state.

-If Player is within 50 pixels of the AI, immediately enter Fire state and fire upon the player.

-AI should try to move behind the player and avoid flying into the path of the player (avoid dumb AI)

-???

Any thoughts on this?

I'm all for the wiki and increasing the 'general knowledge' of the community as a whole.

There are a lot of ways to implement something in Construct 2. This freedom is great because it allows people to come up with creative solutions, but it's kind of like reinventing the wheel: there are lots of ways to do it, but there is likely a 'most efficient wheel' and for production purposes, it's best to use that. So for all the 'solutions' that are possible, it would be nice if there was a place where the 'most efficient while remaining clear' solution was to be found.

Your guess is as good as mine.

From my testing, pathfinding is more or less inconsistent due to CPU issues. I can tell because when my enemy ships are pathfinding, a yellow afterburner sprite appears behind their engines. When they are moving due to bullet behavior (the default behavior I gave them), this sprite does not appear.

I am currently having them 'pathfind' every 1 second, but I'm not sure that is optimal. I'm thinking of removing pathfinding altogether and giving them a set AI behavior, in particular the rotate-move-rotate-fire behavior I am trying to set up that I didn't get many responses on.

I am starting to think that pathfinding by itself is not really a good behavior to use, but instead to be integrated as a small part of an object's behavior for solving the problem of how to get from position A to position B.

Any tips for optimizing pathfinding events so you're not draining the CPU?

I hate the bump a REALLY old thread.

Can someone give us an update on the current state of multitouch in Android?

I'm beginning to wonder if my simultaneous touch issue is more of an Android issue.

For those curious about my issue, try this on a mobile Android device and tell me if the second touch is ever correctly assigned a Touch ID: Test

I suggest adding a health bar to the towers or otherwise indicating that hitting them actually does something.

The first time I played, I had no idea if hitting the towers was doing any damage to them.

just set the X and Y and pin right after it, on an Start of Layout event.

I do everything via code, that BACKUP canvas is only to preview and loading purpose.

Suppose I have multiple instances of an object. For example, I have four instances of the brakes sprite.

Would I just create that sprite multiple times and then pin it? What if each instance has a different angle?

To include an eventsheet, simple click on the "Add Include" button, inside the Events Menu, on the top left of your screen.

I know to reduce memory load/usage, it's wise to dump all objects into an 'object dump' layout.

What about if you have to pin objects to another? Suppose I have the brakes on my spaceship positioned exactly. If I move the spaceship to another layout, how would I 'move' the ship to the current layout without having to repin everything, especially since scaling might mess with the pin positions?

Ashley, what might cause two touches to both have the same ID?

Thanks. I wonder if that's in the manual somewhere...

I've added debug counters to my gameplay link above.

Apparently if LeftTouchID = 0, when the user touches the right side of the screen, RightTouchID = 0, causing both touches to have the same ID. Is this a bug?

I'm having this same issue. My game seems to work fine in Chrome and Safari, Firefox and IE = game broken.