Well, there were three main plugins that were specifically requested in the last dev poll:

** Array (though, I would personally go much further and introduce proper data structures and a visual array editor)

** Save

** Tilemap (seems to be a heavily requested plugin)

You were already planning on doing data storage anyway, so saving is covered, but I suggest doing a tilemap plugin next would be a good idea - it's been a heavily requested plugin since the 0.x days, and it can also be integrated with pre-existing tilemap editors such as Tiled, which can even make an early version of the plugin easy to use because the tools are already there for the user.

And I'm not sure if this is a 'minor' feature, but implementing resources (especially resources that you can place in the project folder/.capx file to allow for easy relative paths) would be a great idea, especially to make it easier for plugins such as sound later along the line.

Sounds reasonable, though I wonder why you didn't do something else first, such as families. I know collision polygons will probably come alongside the image editor and animations for obvious reasons, but I wasn't expecting the Tiled Background plugin so soon, not that I'm complaining!

Anyways, sweet build!

... LOL.

I forgot the Turret Behavior even existed, because I never needed to even use it until now! Looks like I would like to have it now, certainly! XD

But, yeah, now I feel rather silly. Thanks, Ash!

Oh, crap, I think I discovered a bug with the distance expression - mostly to do with picking.

Simply put, I tried a little test with placeable turrets, all of which have a range, which is calculated using the distance expression... Unfortunately, when using the "compare two values" condition, I couldn't get the turrets to fire, period. I messed about with the condition, and discovered that it only worked with the "greater or equal" sign, but then I also noticed that, when I tried to debug the output value for the distance expression, the first one to print was a number that was way too big to be possible. And then I realized that I kept the original instance of the turret object outside the layout - I brought it in, and did more tests, and I realised what the problem was.

Simply put, the "distance" expression plus the "compare two values" condition will ONLY work if the original instances of the two objects are involved - once the TestEnemy gets outside the TestTurret's range, all turrets will cease firing, even if it's in range of the other turrets, or there are other instances of TestEnemy in the original TestTurret's range.

Example cap (click on the black stuff to spawn turrets)

Okay, I just discovered that you can't access an object's ID through expressions. THAT would a good idea to implement. Unless I'm somehow missing something.

Ah. I forgot that condition could be used like that. STUPID STUPID DUMB. XD

Still, it couldn't hurt.

Speaking of which, while distance is a good expression to have, I realized that having a "check distance" condition would also be extremely useful, as you won't have to allocate a private/instance variable in order perform a simple distance check.

Don't know why objects don't already have it, really.

And as a bonus, you'd only need to do one set of C++-based plugins for a whole bunch of platforms, since it's all OpenGL!

Hells yeah! OpenGL all the way, man!

Speaking of which... For the inevitable EXE exporter, are you guys gonna do OpenGL or DirectX? I would think that OpenGL is ideal, as it would make cross-platform EXE export much easier to implement, and the performance is not an issue (in fact, I hear OpenGL has faster draw cells than DirectX), and funnily enough, OpenGL has had features such as tessellation (as an extension in this case) 3 years before DX11, and unlike DX10 and 11, it can work on Windows XP, which is still widely-used.

Though, I'm no expert on the subject, mind you.

Grids of points can overlap with none of their points touching! All the points just fall in between the other points. It won't do at all! Collision polygons are the standard used by physics engines and other algorithms like lighting. We may as well use collision polygons and then you get your physics polygon automatically.

Yeah, that might work. As well, it could certainly make shadows better-quality and, well, actually fit the shapes of the sprites rather than using the bounding box!

Also, speaking of lights, I imagine lights can be improved in some ways upon their implementation in C2, such as being able to replicate the effect of hanging a light above an object when in top-down view (to cast a shadow on the ground), and for light to either be sunlight (rays are parallel) or closer lights (which don't cast parallel light rays).

Anyway, collision polygons are a reasonable compromise, as they're used with physics anyway, and in some ways just as effective as per-pixel without being nearly as speed-dependent.

There'll have to be collision polygons instead.

Are we talking "manually created" polygons or automatically generated?

Arrays are kind of another thing to tackle entirely - if we're going to do arrays, we might as well go all-out and implement proper data structures, basically re-do the entire 'S' plugin except with a visual array editor and make the entire thing much easier to work with. But that's for another topic.

Anyway, this is a fantastic idea, and I approve. I don't think there's any point in making them persist.