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.
don't have sales or engagement data for Scirra, but having multiplayer does "check a box", and therefore I'd expect people to be more satisfied with the product once they see it is multiplayer-capable.
I used to be frustrated with multiplayer via websockets (which was the old way of doing it), and was a big supporter (formatting is broken in that thread) of it when it was in development.
Overall I was pretty happy with the end result, and I'd guess that scirra was losing sales because of lack of multiplayer support before, but again I don't have any data to support that claim. Still I'm not sure I'd say multiplayer was a disaster even if people end up rarely using it.
... 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?!?!")
I say we are definitely lacking at least some support for 3D. I mean at least some textured primitives should be supported, right? I'd love to be able to do something like this in-game.
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".
I can think of a few ways of doing it, but one way would be to return to the forum pools, where you suggest "what's next for construct" and people pick what they want most, this way you are still in control and people still get to vote.
I don't mind that we don't have the page, since you're pretty active in the forums especially with regards to replying to posts when you're called - that's more than enough for me - but I remember that voting and discussing the proposed ideas was a lot of fun.
> 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.
I get that there are edge cases that are hard to work around, but other parts of construct have similar things anyways. There are plugins that throw warnings in the debugger when you do something unexpected, for instance. Overall this stems from the idea that user code should never generate errors, which IMHO is naïve, but I get the rationale of catering to beginners - in the end it's as if we ran code with error warning turned off and an exception catcher that does nothing. I mean, even excel has #N/A and Err:000 placeholders, but that's outside the scope.
Imagine the following is already implemented in Construct:
- Arrays and dictionaries can be referenced directly in the expression editor via the syntax Array[0] and Dictionary["index"]
- This isn't hard to imagine and is probably overdue anyways
Objects can have arrays and dictionaries as properties - again, as requested above
There is an expression returnValueByUID(objectUID,property) that, given an object's UID and a property, returns the value stored in that property for the object with that UID
Other similar expressions exist: returnStringByUID(objectUID,property), returnArrayByUID(objectUID,property) and returnDictionaryByUID(objectUID,property)
The expressions listed in 3 and 4 can already be implemented via the SDK. That way, my players[0].character.turret.fireRate expression would become:
returnValueByUID(returnValueByUID(returnValueByUID(players[0],"character"),"turret"),"fireRate"). Again, this can already be acheived by the SDK, but the resulting expression is messy. It's still better than nothing, though.
- 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.
This is already what happens if you do it the current way, by picking objects sequentially using the "object UID exists" and "pick by unique ID" conditions. If the UID doesn't exist, your event sheet is left in an unexpected state. If you're a power user, you should be aware of the possible states. This is not a beginner feature.
return a dummy value like 0. Even this is surprisingly complicated.
I know you thought about those things and are perfectly aware of the problems with such a solution: what if 0 is the correct value? How do you distinguish a valid-returned zero from an error-returned zero? Again, an excel-like #NA or #ERR:XXX, or even a debugger warning (like already happens in some cases) would mitigate the issue, but how exactly it should be implemented is up to you. Again, all I want is a reduction in code bloat, which is generated too quickly by the current workflow.
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?
Which is why I suggested that there should be a "pointer" property type, so that it could "point" to a specific type of object (this is the same as saying "static typing", which I personally don't like, but whatever, better than not having it). If we could "point" to objects, then we could "point" to arrays/dictionaries, and this solves that other issue of having arrays/dictionaries as object properties.
With pointers, the expression editor knows what to expect, and can keep working fine. It also allows more flexible families and object grouping, so the entire family feature can be simplified.
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?
Make the "pointer" static-typed: you have to specify what type of object the pointer can point to. Issue solved. I mean, you already have to specify that a property should hold an integer/string/bool, why not a pointer to a specific object?
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.
oing by your proposed syntax, your example would become turret[character[players[0]].turret].fireRate. Same situation as above. I mean, sure, I'd rather have that than nothing but I still prefer players[0].character.turret.fireRate