Yeah. While flowcharts are good for smaller things (and excellent for algorithms), they're hopelessly impractical for actual larger-scale programming, not to mention somewhat limited by the amount of input/output thingies.

Judging from the votes so far, the most voted feature is global variables. The next three requested features, in order:

* Fine Collision Detection

* More Plugins

* Families

Specific plugins requested:

** 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)

My personal list, from highest priority to lowest:

* Families

* Fine Collision

* More plugins:

** Custom Movement Behavior

** Array/Data Structures

...Cave Johnson, we're done here.

Holy crap, that was quick. I'm now grinning from ear to ear, all I need now is a proper Custom Movement behavior, animations, fine collisions, and families, and I'm good to go with what I want to do.

Nice! Once behavior actions, conditions and expressions are implemented, behaviors will be at full capability again, aside from the limited amount of built-in behaviors, of course.

Well, yeah. I was thinking of suggesting that myself, but I wasn't sure if it was better for the editor and the runtime or not.

And I did say 'further down the line', I know there's plenty of features that need to come first, after all.

Basically, this is a topic for discussing the possible methods of loading content and layouts that C2 can, further down the line, provide developers, to suit their games.

Now, the way it's pretty much always worked with Construct when changing layouts is, well, a no-frills switch with a slight delay due to loading stuff. Well, there would've been an option for transitions, too, but those got broke in 0.x for some reason I can't recall, which results in one having to do it all in events, lol.

Anyway. Transitions aside, there's no real way to tell the user, in case loading takes more than a second, that the game certainly has not crashed and there's nothing to worry about. Which is what loading screens are for. In that case the developer should be given the ability to create:

* Custom Loading Screen Layout: Whether it's simply a blank space or an animated image with a loading bar, it certainly would be nice if you could have loading customized loading screens to suit your game, that work like regular layouts except able to access conditions, actions and expressions exclusive to it.

Or, if you don't want a loading screen, you should also be given the ability to stream layouts and content.

* Seamless layout changes: Basically, the ability to move between layouts without giving the player any hints that they were separate in the first place. Basically, you can 'slot' two layouts together, and you can use a player object as an indicator of when one layout should load or be removed from memory. The more 'common' objects along the 'seam', the smoother and more seamless the process is.

* 'Transition' layouts: Take the above idea, but slot in a small layout in the middle. Some games have rooms/corridors which purely exist to disguise loading between areas, such as Metroid and some of the Castlevania games. While the player is in the transition room, load up the opposite layout, and when he leaves, dump out the layout he isn't in. Simple.

Also, using 'storage layouts' to store objects so they can be used in any other layout without taking up memory while they're not being used is a valid technique, perhaps there should be options to better accommodate this (as, depending on the object(s), loading an object into memory might cause the game to freeze for a second or slow down).

Well, yeah, but I'm not exactly worried about that, if people want it bad enough, nothing will stop them.

That is true, but isn't that the same of many games?

For example, with GTAIV, changing certain .ini files... Which can result in... I dunno,

Just to clarify what I mean, Construct 0.x exports purely to a single .exe file.

However, the main problem with this method of export is that for updates, patches, etc. you would need to update the entire thing, which is even more problematic and time-consuming for the end user if the game is large. It's only a good idea if the game is small. Otherwise, the whole export should be split into multiple files and folders, methinks.

Sprite and Animation Editor. nuff said.

Isn't that coming in the next build? This topic is for features that weren't originally in C1.

I'm surprised anyone is voting "no", because this is actually a good idea. Might as well, families pretty much serve the exact same purpose as custom attributes, which means attributes like Solid might as well be behaviours anyway.

Also... Didn't someone mention the idea of creating behaviors/plugins using events a while back?