I'll pay $300, maybe more, for Construct 3

1 - Start treating arrays as a proper type, instead of an object. We have string, number and bool, why not array?

IIRC, Classic had some support for arrays as an expression type, but it was difficult to get right. One of the main problems was whether to use copy or reference semantics. Copy is easy and convenient, but if you're dealing with a 10mb array will quickly hammer performance and bloat memory. References were very difficult to get the memory management right for in C++. This would be easier in JS, but then makes for some gotchas - for example if you put an array object's array in to an object's instance variable then change it from there, both get updated, and that might not be what you wanted.

[quote:3rgsnepg]3 - Pointers as a type. This means you can store references to an object inside another object, as a property. Right now you can do this by storing the object's ID, but you can't do stuff like player.weapon[1].destroy() in a single event

The event system is very different to programming languages, so when you suggest a feature and give a line of programming code as an example, I'm not sure how exactly you think this would really work! UIDs already allow this, and as per the way events usually work, you need the condition to pick the instance to run the actions on, so there needs to be a condition involved either way...

[quote:3rgsnepg]4 - First class functions. You should be able to return functions as well as store functions as properties of an object. This is something that javascript can already do, so why not?

Again, if you just throw out a programming language feature, how would that really look in the event system? And why would that be useful?

I'd add most of the other suggestions in this thread have been suggested several times in the past - we have a very long todo list, and a finite amount of hours in the day. So if you really want a feature suggestion to be taken seriously, you should go in to detail about how it would work, give several examples of previously difficult things that become a lot easier with the feature, and some reasons why it's important enough to do before all the other feature requests we have!

How about a "Digg" style page somewhere on Scirra.com that we can use to post these feature suggestions and "sales pitches" and then let others vote them up/down to build a C3 feature list? How useful and fun would that be?!

then let others vote them up/down to build a C3 feature list? How useful and fun would that be?!

Do you remember the last voting?

All the kids voted "multiplayer", not having any idea what they were doing..

Do you remember the last voting?

All the kids voted "multiplayer", not having any idea what they were doing..

I would have said it was the vocal 'minority' rather than kids who brought that to the fore.

Proverbial kids, not actual ones

Ok I hadn't thought about any of that. Then perhaps anyone could post a C3-feature-sales-pitch but restrict up/down voting to high rep users and moderators. Your rep must be some minimum (like 10K) to participate. Or let anyone vote but give the high rep folks some kind of x100 multiplier/weight to their votes. Maybe something like that would work.

This would be easier in JS, but then makes for some gotchas - for example if you put an array object's array in to an object's instance variable then change it from there, both get updated, and that might not be what you wanted.

Better to have the gotchas than to not have proper arrays at all! I'd rather have it always be reference and if you want by copy you can manually copy the array yourself. This is just an organization feature, really.

I'm not sure how exactly you think this would really work (...) you need the condition to pick the instance to run the actions on, so there needs to be a condition involved either way

I'm not sure what the problem is. The current system is to have an event where we pick a variable out of an object, corresponding to the UID that we want to work with. Then we have another event that picks that object by it's UID, and we perform actions on it.

An example: say we want to get the fire rate of a turret. The current workflow is like this:

• Read the UID stored in the array "players" at X position 0
• Pick the character object with the UID above
• Read the turret property of the character object, which will be a UID (but is in fact just a number)
• Pick the turret object with the UID above
• Read the fireRate property of the turret object we just picked

With my proposed system, you'd have two ways of doing it:

• Call the expression players[0].character.turret.fireRate directly. There is no ambiguity at any point about what you are referring to, and the SOL is never modified.
• Use the "pick an object by UID" condition to pick players[0].character.turret, then read the "fireRate" property. The expression editor doesn't understand nested expressions right now.

This example may sound weird, but let me give you a typical scenario of an RPG:

Each character has a healthbar and an inventory with N slots

In the inventory, on slot 0, there is a fire sword

That fire sword has a name, damage, attack speed, critical hit chance, etc.

That sword's damage and critical hit chance is also divided based on it's fire damage and slashing damage

Really the only problem is that the expression editor doesn't understand nesting (because as far as it is concerned, a UID stored in a variable is just a number), the rest is all secondary. Sure we could try to think some magic with regards to modifying the SOL, or calling methods directly by reference, but that's all secondary.

It's feasible to make a plugin that does exactly that with the current SDK, I believe, but we'd need the path expression to be surrounded by double quotes, like jQuery Selectors. It would be better if it was more integrated with the SDK.

[quote:28918sp9] 4 - First class functions. You should be able to return functions as well as store functions as properties of an object. This is something that javascript can already do, so why not?

Again, if you just throw out a programming language feature, how would that really look in the event system? And why would that be useful?

Maybe I don't need to pass around functions, sure, but we need at least a way to have methods without having to clutter the namespace with object-specific functions, as well as a proper way to do callbacks (again, without storing function names in arrays). If we were able to store functions in an object's property lists, that would solve the problem, and if we're doing that, why not go all the way and allow expressions to be passed around? Again, that is secondary, the primary goal is just to allow objects to have their own functions without polluting the global namespace with functions like addItemToPlayerInventory(item,quantity,playerUID)

I'd add most of the other suggestions in this thread have been suggested several times in the past - we have a very long todo list, and a finite amount of hours in the day. So if you really want a feature suggestion to be taken seriously, you should go in to detail about how it would work, give several examples of previously difficult things that become a lot easier with the feature, and some reasons why it's important enough to do before all the other feature requests we have!

Well right now I'd say the biggest thing is to extend the SDK, and for that we need an extensible editor, and for that we need C3, so I think you're already on the right track there. It's hard for me to gauge what's easy and what's hard to do since I don't know the internals of the engine.

How about a "Digg" style page somewhere on Scirra.com that we can use to post these feature suggestions and "sales pitches" and then let others vote them up/down to build a C3 feature list? How useful and fun would that be?!

+1000

I think this is indeed something Scirra needs. A place where people can add and vote for future features (with moderation oc. and a big text that this page is only about suggestions and Scirra may take it into account if they see it right and feasible). Or it could be a page that shows suggested features but not the number of votes it has.

Also, I'd say that there should be a similar page for bug reports as well. A lot of users are not using the current forum-based solution.

You could restrict users who bought Construct 2 or 3 to be the only ones able to vote on features if you want to prevent spamming.

> How about a "Digg" style page somewhere on Scirra.com that we can use to post these feature suggestions and "sales pitches" and then let others vote them up/down to build a C3 feature list? How useful and fun would that be?!

>

A place where people can add and vote for future features (with moderation oc. and a big text that this page is only about suggestions and Scirra may take it into account if they see it right and feasible). Or it could be a page that shows suggested features but not the number of votes it has.

IIRC, Ashley said this wasn't implemented because he was concerned about competition stealing ideas from such a page.

Do you remember the last voting?

All the kids voted "multiplayer", not having any idea what they were doing..

Despite its relatively light usage, this was still an important feature or option for C2 to be a much better tool for future professionals, and provides a great selling point even with the complications of writing your own Node server (which could be a simple echo, then handle logic in C2).

Letting the community vote is important because we're not voting on features in a specific game (eg: the ones we are making now) but the possibilities we want in the future. Having options is what Construct 2 is all about.

So I would say that I completely agree with letting people vote, but Scirra can then fine tune the order of implementation based on difficulty of the tasks. Voting just makes sure they know what their customers want.

—

That's a terrible excuse, you can modify the elements in-place in a small buffer of vector object and generate no garbage, passing the result by value to a fixed object like you do with any other variable types, the same way you can with arrays. Vector types are not complicated to implement, and construct already "supports them" through having multiple variable, all we'd need is a better IDE that can manipulate / recognize vectors/arrays.

That's a terrible excuse, you can modify the elements in-place in a small buffer of vector object and generate no garbage, passing the result by value to a fixed object like you do with any other variable type, the same way you can with arrays.

Especially considering that objects are currently recycled in the same fashion in the current iteration of the engine IIRC.

I don't know why that wasn't done, but the SDK still had references to a deprecated vector type when I first checked, and I believe that's how it was explained in the reasons for deprecating it, but I may be misremembering.

[quote:t984e942]One of the main problems was whether to use copy or reference semantics. Copy is easy and convenient, but if you're dealing with a 10mb array will quickly hammer performance and bloat memory

Ashley

Just have two different types then, one that passes by reference and another by value. MOST arrays will not be bigger than a few elements and just serve to reduce code bloat. If you don't like the effect it may have on new users being overwhelmed, hide advanced types behind a setting like "enabled advanced view" like most programs with power-user features do.

Well I don't have a lot to offer the "arrays" discussion. Overall I'm pretty happy with what we have in C2. It's really just missing a few IDE features like strong debugging and fast navigation around the Event sheets. If that's all C3 gets I'll won't be upset.

IIRC, Ashley said this wasn't implemented because he was concerned about competition stealing ideas from such a page.

Well yes, I can see the point in that. Not displaying the number of votes for each element might help, but there still would be a public list... Well, I still believe it can be done somehow to serve it's purpose and keep the valuable information safe.

However that's not a problem for a bug reporting page.