Local variables

New releases and general discussions.

Post » Thu Apr 16, 2009 12:14 am

Or I could just make a quick plugin.

Get It Here
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Thu Apr 16, 2009 2:15 am

404'ed.
B
6
S
3
G
6
Posts: 219
Reputation: 3,013

Post » Thu Apr 16, 2009 7:52 am

[quote="BROO":r9uiscdv]Do not want it. This is just another source of data (we have PVs, Hash Tables, Arrays, Global Variables at the moment, it's much enough). And it'll take some more ACE entries.[/quote:r9uiscdv]

Wow. I won't ever understand this idea. Just because there are workarounds for a problem doesn't mean that the problem is fixed (and your suggested workarounds are far from being as convenient as a local variable).

Say you have certain effects that will only apply to a level (layout) and that you'd like to take control of by using a variable - since you might not want to use a global variable for every single level you build (the bigger the games become that we build in Construct, the more painful it'll be to do everything with gvs), and you want to keep the game logic 'logical' (maybe so that someone else could understand it as well) a local variable would be perfect.

We had a similar argument on the chat yesterday as well. There's this notion here that the solution to a problem (if a feature doesn't work or the app isn't yet feature complete or production ready) is not that important if there's already a workaraound available.

I think that it's very short sighted to rely on your users using workarounds for problems. I've seen that over the years happening with complex 3d apps, where some things are now really hard to learn for students, cause they just don't get the workaround that was introduced 3 years ago to 'solve' a problem that was never fixed because it would've been too complex to do at the time. So since the problem was 'somewhat solved', the developer never went back to solve it properly - probably because fixing bugs isn't sexy on release lists.

Just because something is theoretically possible doesn't mean it's practical. Construct, just as 3d applications, is (going to be) a complex piece of software that a huge chunk of people with no technical background will use to create amazing stuff - and that's the beauty of it. But the more you ask them to use workarounds that often need you to think in very technical terms, the more you alienate users that are probably more interested in just making their art come to life.
B
6
S
2
G
3
Posts: 520
Reputation: 2,690

Post » Thu Apr 16, 2009 8:19 am

It's not that Layout Variables are necessary to avoid workarounds, it's that the same exact thing can be achieved with very little effort and very little overhead, as compared to the effort needed by the developers to implement a feature such as this.

In other words, if you can easily do the task another way (and in this case, you can), then the feature being requested is pretty much useless, so why bother debating a whole new method of doing things? (Especially when the developers themselves have said "not bloody likely?")

Using a sprite, or even a text object, to store variables isn't hacky, it isn't cumbersome, it's not some outrageous or radical idea, and it would have just about zero impact on your game performance, so... what's the problem again?

It's all rather beside the point anyway since Aeal has already made a plugin that does this very thing, and actually has more functionality than Layout Variables because you can have more than one object per layout to store your variables in if you wanted to.

On the other hand, Aeal's plugin is a third party creation that not everyone is going to have, so it's just going to cause problems down the line if your .cap uses it and you need assistance in Help/Tech or something, because people will just be confused about why they can't run your .cap and then they'll have to go download the thing and install it and blah blah blah... or they just won't bother.

Long story short... there's not a single thing wrong with making a separate sprite or text object that stores certain variables for you, I do it all the time in my projects. It makes the whole concept of Layout Variables rather pointless if you think about it.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Thu Apr 16, 2009 8:40 am

Classic, open source working the way it's supposed to.
Devs make what is absolutely necessary, third party's come along and add to it.
Its a great little system, not perfect, but it works, and the reason it works is because it leaves room for these differences of opinion. In other words if you don't like something... change it. If someone else doesn't like the change they don't have to use it.
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Thu Apr 16, 2009 9:03 am

Deadeye: There is no 'problem' with using a buffer sprite if you think about it that way, but it definitely is a somewhat hacky way to do it. Because it's a workaround by definition. We don't have local variables, so we use bufferSprites to simulate local variables = Workaround.

If you use global variables for things that are global, why shouldn't it make sense to implement local variables that'd apply to layouts only?

Sure it's good that Aeal has done it, I just wanted to emphasize the point that this IS a workaround and someone who's completely new to Construct (and as it seems a lot of new people are joining now), using buffer sprites to store local variables would probably not be the first thing on their minds - So you have a steeper learning curve, cause you need to know this workdaround in order to make use of a local variable.

Maybe I'm a little too worried about this, but I've seen this same thing happening with Maya, where Alias (and now Autodesk) started explaining workarounds to their users that at first seemed perfectly fine, but once you start repeating this method over and over again, you'll end up with a huge chunk of workarounds for things that could be implemented natively, so that it would actually make a lot of sense. If you always know 10 workarounds for various tasks, good for you, but in an application that's decidedly non-techy, it's probably not what you want to do looking forward.

Again, I'm not out to piss on anyones boots or introduce egos here, I just want the app to grow into the right direction. Maybe the way I see it is bullshit as well, but I do think that this is a clear case of "Hey, it'd be cool to have this feature natively in Construct, so we don't have to use a workaround all the time!"
B
6
S
2
G
3
Posts: 520
Reputation: 2,690

Post » Thu Apr 16, 2009 9:37 am

Potential feature creep.

There is one problem with local variables - what if you want to read a variable of another layout? That is right, you cannot, because it is local. Like you want to check if the door was opened in another layout, but there is no way to see that until you get there.

Construct has several data plugins - Hashtable, Array etc. - you could make a global data object and store layout variables there that you can access from anywhere. They'll also be neatly organized into one bunch that you can easily browse.

I wish there were more types of data objects, though; a stack, a custom data structure (for characters for example) and so on.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Thu Apr 16, 2009 9:42 am

Urgh, Mipey posted before I finished writing, but I'm posting anyway even though he mentions feature creep, which I also mention bleah whatever:



I guess I just don's see it as a "workaround." If there were a Layout Variables feature, and it didn't work properly, then you'd be forced to do a "workaround" such as making your own variable holder object.

Since there are no Layout Variables, then making your own variable holder object isn't a workaround. It's not a hack, it's a technique. It's not a bandage for a broken feature, it's a method to a means. Where you see a workaround, I see a clever solution to a problem.

I'm sorry, but I feel pretty strongly about this sort of thing. If you can do a task easily with a couple of clicks or few events, then a full-blown feature that does that exact same thing is largely unnecessary, isn't it? I'm not against adding new features at all, but if a feature is to be added then let it contribute to productivity in some significant manner.

And quite frankly adding little, single-task features like this, over time, will just lead to feature creep, or software bloat, or however you want to term it. Slippery slope? Maybe. But a sprite or a text object is a multi-tasker. You can do the same task without adding a new feature. And keeping out unnecessary features keeps Construct lean.

So if you have to perform some task in Construct, ask yourself... is it hard to do? Is it laborious? Does it involve complex math? Will an alternate method markedly increase development speed or productivity? Will an alternate method markedly increase runtime performance? Does a means to do it simply not exist? If so, then request away. Otherwise, ask yourself if it's really necessary. And I simply fail to see how Layout Variables are necessary.

No offense, Aeal ;)
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Thu Apr 16, 2009 10:08 am

If there's a guy that'll come to conclusion "Oi! I need local variables" faster than noticing "Sprite object has private variables" then I'll be surely surprised.

The more ACEs or Plugin duplicating the existing ideas, the bigger mess you get in ACE list / Plugin list.

Edit:
I mean, I don't mind you guys making plugins. But if you won't make really helpful one, then nobody will bother downloading it. And even if some novice guy will use it, but he'll later encounter a problem and send up Needing-Your-Plugin CAP file, I won't be bothered searching for CSXes or even installing provided one. That'll make mess in my nice and tidy Construct Sanctuary and will force me to get to know new solution's I won't use (what for?).
B
6
S
3
G
6
Posts: 219
Reputation: 3,013

Post » Thu Apr 16, 2009 10:25 am

If you consider what a workaround really is:

"A workaround is a bypass of a recognized problem in a system."
"Typically they are considered brittle in that they will not respond well to further pressure from a system beyond the original design."

Then it's clear that using organised methods to hold your game data - such as a hash table or array - which can be saved to disk properly, unlike layout variables would potentially be able to - are neither a workaround nor tough solution, but a genuinely superior one for many uses.

Layout variables are a feature I can see some people using, but ultimately sometimes causing themselves more organisational or hassle as a result of, when there's easier solutions out there! The only caveat is that initial values for hash tables/array can't be set; this can be remedied via some very simple additions to the SDK. If a dev wants to take it on I can send them the sources for either.
B
3
S
2
G
5
Posts: 1,777
Reputation: 5,529

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 2 guests