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

Discussion and feedback on Construct 2

Post » Mon Dec 14, 2015 6:19 pm

Fimbul wrote:Having to store references to other objects by storing their IDs as a number, then having a sub-event pick them out is garbage. Same goes for polluting your function namespace by creating pseudo "methods" that take an object ID as a parameter.

I'm gonna use the word "easy" very loosely here but couldn't Object types be defined as one (or multiple) of the Function params? Then they're passing UIDs (or whatever, underneath) so that in the Function, we immediately have the "picked" reference to our Objects. Seems like this would be an "easy" extension and improvement on what we already have in C2.
B
14
S
4
Posts: 300
Reputation: 1,643

Post » Mon Dec 14, 2015 7:52 pm

Fimbul wrote: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.

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...

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!
Scirra Founder
B
403
S
238
G
89
Posts: 24,654
Reputation: 196,155

Post » Mon Dec 14, 2015 8:13 pm

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?! ;-)
B
14
S
4
Posts: 300
Reputation: 1,643

Post » Mon Dec 14, 2015 8:22 pm

locohost wrote: 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..
B
79
S
29
G
32
Posts: 482
Reputation: 19,915

Post » Mon Dec 14, 2015 8:27 pm

Eisenhans wrote: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.
If your vision so exceeds your ability, then look to something closer.
Moderator
B
137
S
31
G
87
Posts: 5,557
Reputation: 60,458

Post » Mon Dec 14, 2015 8:34 pm

Proverbial kids, not actual ones ;-)
B
79
S
29
G
32
Posts: 482
Reputation: 19,915

Post » Mon Dec 14, 2015 9:05 pm

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.
B
14
S
4
Posts: 300
Reputation: 1,643

Post » Mon Dec 14, 2015 9:16 pm

Ashley wrote: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.

Ashley wrote: 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:
  1. Read the UID stored in the array "players" at X position 0
  2. Pick the character object with the UID above
  3. Read the turret property of the character object, which will be a UID (but is in fact just a number)
  4. Pick the turret object with the UID above
  5. 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.

Ashley wrote:
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)

Ashley wrote: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.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Tue Dec 15, 2015 9:54 am

locohost wrote: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.
B
137
S
33
G
17
Posts: 1,560
Reputation: 20,802

Post » Tue Dec 15, 2015 12:31 pm

glerikud wrote:
locohost wrote: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.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 9 guests