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

Discussion and feedback on Construct 2

Post » Tue Dec 15, 2015 12:48 pm

Eisenhans wrote: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.
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit
B
102
S
35
G
17
Posts: 2,158
Reputation: 18,481

Post » Tue Dec 15, 2015 1:11 pm

@flimbul

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.
Last edited by QuaziGNRLnose on Tue Dec 15, 2015 1:16 pm, edited 2 times in total.
B
64
S
10
G
8
Posts: 1,957
Reputation: 9,236

Post » Tue Dec 15, 2015 1:15 pm

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

Post » Tue Dec 15, 2015 1:21 pm

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.
B
64
S
10
G
8
Posts: 1,957
Reputation: 9,236

Post » Tue Dec 15, 2015 2:59 pm

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.
B
13
S
4
Posts: 280
Reputation: 1,573

Post » Tue Dec 15, 2015 4:44 pm

Fimbul wrote: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.
B
121
S
31
G
17
Posts: 1,468
Reputation: 19,930

Post » Tue Dec 15, 2015 5:56 pm

QuaziGNRLnose wrote:(...) reduce code bloat (...)


Well put. This is basically all we're asking for, really.
B
36
S
8
G
8
Posts: 532
Reputation: 6,898

Post » Tue Dec 15, 2015 6:06 pm

2) Another Configuration aside from HTML5, that would be great.
Image



The Things you can create is only limited by your imagination. If you don't have the skills then use your motivation as a natural force to exceed all expectations. Chadori RebornXD
B
51
S
17
G
90
Posts: 1,108
Reputation: 59,024

Post » Wed Dec 16, 2015 1:13 pm

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?

Yeah, that worked out pretty badly for multiplayer. If the vote counts had been representative, most users would be using multiplayer. From what I can tell, it's just a small minority. So I think that shows that large numbers of users - even a majority of those participating in the vote - will vote up features that sound cool even without actually ever using it.

I already know if we did that, even with rep limits/controls/weighting, the top requests will probably be "make Construct 3D" (probably with people saying things like "it's only one extra dimension, how hard can it be?!?!"), "make native exporters", and maybe something else like "add support for scripting". These all have serious technical, business, marketing and user experience implications. For example "Construct 3D" is basically an entirely different product which few people will be able to take full advantage of and IMO is kind of a crazy idea, but predictably will be super popular in any kind of vote. Then if that's the highest voted feature and we quite reasonably decide not to act on it, now it's fodder for the trolls: "look, Scirra ignore their users, they don't care what we think".

Fimbul wrote:Call the expression players[0].character.turret.fireRate directly

It's a nice idea and it does look useful. But if you think it through it becomes a lot more complicated with further-reaching implications than you appear to have considered. This makes it far from a straightforward suggestion.

Take the "players[0].character" part of the expression, which appears to refer to a "character" instance variable designed to store an object reference. Suppose the object reference is empty, or was destroyed or is otherwise no longer valid. Now the "players[0].character.turret" part cannot be evaluated. Now there are two reasonable ways to handle this:

- fail the expression evaluation, cancel the action/condition, cancel the event, and log some kind of diagnostic error somewhere. However this can leave events in a half-run state which can leave the game in an unexpected state. This is also different to how the vast majority of events work: you never need to look up diagnostics to see why something isn't working.

- return a dummy value like 0. Even this is surprisingly complicated. The event system doesn't necessarily know what the return value of "players[0].character.turret.fireRate" was meant to be, especially since no object exists at the time of the error. E.g. was it meant to be a string or a number? It could always return 0, but then if it was meant to be a string now you can end up with unexpected results since something which is normally a string is suddenly returning a number. If you then later extend this with array types and try to chain expressions like "players[0].character.someArrayValue[0].turret.fireRate", now you might end up returning 0 and then trying to access it as an array (i.e. equivalent to 0[0]), which starts to get even more gnarly a problem.

There's also the problem of validating expressions. Right now a strong point of the event system is it is near enough impossible to enter invalid events. However if you type in "players[0].character.", what should autocomplete show and what should the expression validator consider valid tokens to follow it? At edit-time, the editor does not necessarily know what type of object the reference could be pointing to. So should it just dump a list of every behavior and instance variable name in the entire project after it? Is that useful to the user? What if you pick a behavior that does exist in the project, but at runtime the object instance you get does not have that particular behavior? Even if a bunch of clever workarounds were deployed to dodge all these difficult questions, would the end result be something that is still easy, intuitive and useful, or would it just be a minefield of nasty gotchas for large projects?

This is a good example of how as a user it can be difficult to grasp the full extent of what is an apparently straightforward suggestion. It can lead down a rabbit hole of awkward bugs, difficult-to-explain features, gotchas, and make it more difficult to add more features later on.

A little-used feature of the expression system is you can refer to currently picked object instances by index with:
Sprite(1).X
This already works, and reads the X value of the *second* picked Sprite instead of the default first. However this is not always useful since you don't necessarily know which instances are picked or in which order. Perhaps a similar feature that picks by UID and *ignores picking* (so you can always get any instance) would be better, e.g.:

Sprite[1].X

would pick the Sprite instance with UID 1 and then get its X position. This is a lot easier to implement and avoids many difficult cases above, but still has some gotchas.
Scirra Founder
B
378
S
220
G
84
Posts: 23,863
Reputation: 188,019

Post » Wed Dec 16, 2015 1:48 pm

family(index).x
Mind blown.
Image ImageImage
B
164
S
49
G
138
Posts: 7,953
Reputation: 91,872

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Baidu [Spider], SnipG, yme and 6 guests