Sneak peek: r36 Local Variables

Discussion and feedback on Construct 2

Post » Mon May 23, 2011 3:19 pm

Hi all,

Just thought you might like to see how the next build is shaping up. I've been working on global variables, as per request in the last poll, but also adding in a 'local variables' feature as I go.

If you ever needed a temporary number to store a value just for a couple of events, local variables are perfect. Previously you'd have to add a global variable or stow it away in an instance variable. The problem is those are visible to the rest of the project. Lots of these temporary variables end up 'junking up' the project with random bits of data.

Local variables are a new type of event block. They look a bit like comments, but declare a temporary variable that is only usable in its "scope". At the top level, they're global variables, but in a subevent, they become local and are limited to use within that one subevent.

For example, to calculate the average position of a bunch of objects, you need a temporary place to store the sum of X and Y values. With local variables it looks like this:



The variables Xsum and Ysum don't appear anywhere outside that subevent, so they don't mess up the project.

This is a totally new feature for C2! I'm not aware of anywhere a feature like this has been done before. You'll be able to play with it in the next build! If you have any ideas that would make this extra-awesome, let me know :)
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon May 23, 2011 3:34 pm

Cool, this feature is pretty useful. Can you, for example, put the declaration block as subevent of an event, and then just set the value in the declaration block without using any actions?

Like:
[a collides with b]
subevent: Local number aPosition = a.x

?

maybe it wouldn't even have to be a subevent, just a same level linked event.

I'm just a bit concerned that having them only apply to one subevent makes them a bit limiting. Sometimes an algorithm takes up a few events.

EDIT: ok, I think what you meant was nesting level. I was under the impression that you can only use them in that one event they're linked to.
B
25
S
3
G
6
Posts: 1,197
Reputation: 5,620

Post » Mon May 23, 2011 4:26 pm

Initialising a local variable with an expression like Sprite.X isn't going to be supported immediately - it's a little complicated - but it will come in a later build. For the first release if you need an expression all you need to do is follow with a 'set variable' action.

They're not limited to one event: they can be accessed in all its "sibling" subevents and subevents to all those events. It's like scope in programming languages: you can use local variables everywhere inside the curly braces they're defined in, but not in code outside of that. This gives another advantage: you can re-use the names in different scopes, such as having 'sum' in one subevent in one place, and another 'sum' in another subevent somewhere else.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon May 23, 2011 4:33 pm

Do the variables and their values only last one tick, or do they remain for multiple ticks? I think they'd be far more useful if they would last for multiple ticks.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Mon May 23, 2011 4:45 pm

I was considering having them reset to their initial value every time the event ran. If they persist their value they're exactly like global variables, but only accessible within their scope. Does that sound like a better idea?

I'm not sure: if they persist, in the example in the original post, the second time you click the Xsum and Ysum values increment from their old sum values, which might be unexpected.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon May 23, 2011 5:11 pm

Hmm... perhaps a 'retain value/reset value" parameter?

I'm not sure either. One benefit of doing it this way over normal globals though is they can be created dynamically at runtime. I personally would like the option for them to be able to retain their values, but if not, I can continue using a hash table for that instead. Either way, looks handy!

One other thought, I assume the syntax checker will properly know if a local variable is currently usable/within its scope or not?
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Mon May 23, 2011 5:27 pm

Yes, the syntax checker knows which variables are available in the current scope.

I'm siding with not persisting values for local variables. If you want a persistently stored value I don't see why you wouldn't use a global variable instead.

Local variables are intended for small clusters of events where you need somewhere to temporarily dump a value, but you don't want to be forced in to using a global or instance variable. I think for this purpose, non-persistent local variables are fine.

In programming languages, local variables by default are not persistent either - they're the same kind of temporary holding space.

Does that sound fair? I can do the initial release with non-persistent local variables, and everyone can have a play with it and see how it works out. If it turns out it would be really useful to persist them I can always change it later.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon May 23, 2011 5:29 pm

I agree with Ashley I would make them work like they do in c++. Im not sure its the most intuitive for new people but it is something that has to be learned anyways and when you move on to another language that idea of local variables will persist and in the end teaches people proper programming practices.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Mon May 23, 2011 5:47 pm

How about both, a local value, and a non declared variable?
Also arrays.
Image Image
B
161
S
48
G
91
Posts: 7,357
Reputation: 67,269

Post » Mon May 23, 2011 6:27 pm

Arrays are kind of another thing to tackle entirely - if we're going to do arrays, we might as well go all-out and implement proper data structures, basically re-do the entire 'S' plugin except with a visual array editor and make the entire thing much easier to work with. But that's for another topic.

Anyway, this is a fantastic idea, and I approve. I don't think there's any point in making them persist.
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Next

Return to Construct 2 General

Who is online

Users browsing this forum: spacedoubt, Unconnected and 0 guests