Oops. Guess I forgot to keep up with the updates. I'll update this to work with custom control schemes.

Predictive aiming and attaching to hardpoints is on it's way, though I probably won't be able to finish them this week (with the holidays here in Brazil and everything).

Next up is targets as a list (both for actions and conditions).

I could add "bind to object at point" as an action, but that would be deprecated by the container feature.

I'll resume working on the turret behavior on monday, and I'll see if I can add something to the extension or code a "hardpoint" behavior that attaches objects to other objects (while keeping angles relative)

Meanwhile keep this topic updated, my goal is to have the turret behavior be able to do everything you want.

When the turret has no targets, it returns to it's starting position.

Is that what you want?

You can try this:

turret behavior

HTML5 is new and a lot more hyped. It makes sense, from a financial perspective, to make a tool to occupy a less crowded market, especially if you're developing it from scratch, as is the case with C2.

Additionally, from a developer perspective, it's a lot

easier to

• get funding for an HTML5 game
• get people to buy a HTML5 middleware if you're an influencer/affiliate/partner
• reach a wide audience

than with a traditional exe exporter.

Apparently, Scirra's business strategy is to empower indie developers and help them make money, unlike clickteam, for instance, which caters to hobbyists (all MMF devs who attempted to create games commercially seem to waste more time working around bugs and "newbie-friendliness" than coding actual games).

Even the SDK is a lot easier than what you'd find in Unity, Unreal, Source and other big platforms. If there's a feature you don't have, you can either wait for Ashley or work around it with a custom plugin - that speaks a lot about the maturity of the platform. Also, with each new *big* feature (groups/families/image points/collision masks) you get less and less reliant on Ashley to do stuff for you.

This is the reason scirra has my money.

Besides, no one ever said an EXE exporter was out of question. If an Exporter SDK existed, people would be working on EXE exporting already. Let the product mature a bit and get all the core features. Buyers were even considered "early adopters" until a couple weeks ago!

Bump: z-ordering with foreach and "send to top of layer" may be just as efficient, but it sure makes a mess out of your code - especially if you have to order several different objects that aren't grouped into a family.

With number based z-ordering, I can keep track of the numbers myself, and assure there is never a collision (order numbers being equal). Even if there is, construct could draw whatever first (the first one that gets called in the draw loop is behind) without any other special logic to handle such z-order collisions.

It sounds exactly like the sort of problem a game creating engine should abstract away.

don't use img.onload. It either won't fire or it will fire as soon as you change the SRC attribute, and there are no workarounds.

use img.completed, which is a flag that returns TRUE when the image is loaded. You'd have to check it every tick though. In my "insert external image into sprite frame" plugin (I can't come up with a good name), I use cf_fake_trigger and evaluate that flag every tick.

Well, you can also test the distance between objects with events: distance(a.x, a.y, b.x, b.y) < 100

but I understand that's not very convenient. It's on the todo list, but it gets a bit tricky with things like poly-circle and circle-poly collisions.

hence the "ugly hack" part (if I were to make this as a plugin)

A circular collision mask is the same as calculating distance from the center of the object (you can offset this, obviously).

If a point's distance relative to your object is less than the radius of the "circle mask" (which isn't really a mask, just an imaginary concept), that point is colliding with the object.

I could probably make a behavior to make objects "collide" with perfect circle masks, but it would be an ugly hack and it would probably be computationally expensive for multiple objects. PM me if you really need this urgently and can't implement it via events.

Distance(ThisObject.X, ThisObeject.Y, ThatObject.X, ThatObject.Y)

Distance(ThisObject.Point, ThatObject.Point)

Distance(ThisObject, ThatObject)

Last one looks cleanter, IMHO.

If the expression can extract X and Y out of the object, it looks cleaner than the "point" alternative and avoids creating yet another construct.

But there will be a way to group different objects, right?

I can think of a couple situations in which that'd be useful, such as when you want to create/destroy/rotate/move an entire composite object at once.

It would automatically associate all instances with each other (for instance, a condition that selects one object would include all objects of that group into the SOL).

That would enable things like a tank emitting smoke particles, complete with a main cannon and a machine gun turret, with a health bar and a player name (for instance).