My two cents... some steps towards object orientation:

Ability to make user defined methods for objects

For example: There could be a "private" event sheet for every object, or you could make one. In that event sheet you could make functions like "ShootPlasma". In the event sheet of the level, you could then see "ShootPlasma" as an action of the object, like any other inbuilt actions like "Destroy". This would greatly help with encapsulation and benefit large projects with lot of developers!

"Object reference" as an inbuilt data type

More comprehensive set of inbuilt data types

A list type, for example.

Multiplatform runtime, and preferably edittime too! Mac OS X is pretty popular nowadays! Okay, it's already said quite a lot of times...

Improvements for object selection

Something like families or attributes, but with ability to be changed runtime; something like adding "tags" to object instances, and selecting instances with tags.

Also: a way to distinguish between two instances of the same class in an event! Read this:

"Layout" as an edittime AND runtime exportable/inportable dataformat (based on XML)

This would lessen the need for implementing own level loading and saving routines and make large projects more modular! There shouldn't be a need for user-made levels and game dev made levels to be fundamentally different.

Sounds like construct is heading towards the realm of object-oriented programming! (Well, actually there's no methods in the containers, so I guess it isn't object-oriented. But... heck. That's still awesome.)

Drasa (Finland)

Ashley: Hm, now that you say it that way, I have to agree, it is more elegant that way, after all :D

Well, nothing at all, but you'd have to add a family to every object for that to work. I think it would be generally more "elegant" if there was a way to address "any object (of type X)".

This problem is more generally represented: how to pick any objects of object type (for example, any sprite). One solution is to assign a family to every object of object type. For example, if you want to pick amongst every sprite, picking amongst family red equals to that, if every sprite belongs to family red.

It's another family trick, I guess that families extend to many things they weren't originally even thought of... It's a bit hacky but it should work.

What :D? Now I'm getting really confused, broken finnish?

I'll post this again here:

Oh, by the way, Ashley, Davo and Rich, are you using ASSERT macro when developing? I don't know much about developing software of this scale, but I guess it'd help with bugs, especially if you left ASSERT on in unstable or non-final builds so the whole community would test the software with assert.

Oh, by the way, Ashley, Davo and Rich, are you using ASSERT macro when developing? I don't know much about developing software of this scale, but I guess it'd help with bugs, especially if you left ASSERT on in unstable or non-final builds so the whole community would test the software with assert.

So, you are creating some kind of customisable "struct", like in C? (or object in c++) So that the members of the structure can be other data types or objects of construct?

If there's going to be multible choises for runtime, it would indeed be nice to have DirectX 9, DirectX11 and OpenGL versions.

Yeah, quarp was originally included for that reason :)!

(I requested the feature :B)