What to use for temporary variables?

manu5

  • Posts: 27
So with classic programming I use temporary local variables (inside a function block for example) to store the result of longer expressions (log(sqrt(x) + PI))  so I do not have to type (and calculate) it again. But what to use in Stencyl? Attributes are class variables and actor values are even more ugly. What do you suggest? Must write code?

sdieters

  • Posts: 2068
You can simply use an attribute. But if you want to give it a calculated value that doesn't change you can use a when created event.

Number = number attribute.

When created,
Set Number to ((square (x) + (pi))
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

manu5

  • Posts: 27
Yes, I know I could do it but I want something more elegant and fast. A variable that only exists inside that custom block. Like a regular local variable in programming languages. I am afraid I have to write code directly.

sdieters

  • Posts: 2068
any reason why you would do that?

i mean, i have never had any performance issues using regular attributes.
dont forget that only GAME attributes are like global variables, all the non-GAME attributes are just local variables
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

Hectate

  • *
  • Posts: 4643
You can use the code blocks to define and refer to temporary variables. By code blocks, I mean the ones under Flow >Advanced.
:
:
Patience is a Virtue,
But Haste is my Life.
Proud member of the League of Idiotic Stencylers; doing things in Stencyl that probably shouldn't be done.

dripple

  • Posts: 748
I had the same thoughts when I started using Stencyl, I always thought the Java-way. :D

First of all, you're not using Variables, you're using Attributes. To understand this helped me a lot. Attributes are (a little bit) more complex, they are Objects who are organized by the Stencyl Game Engine. That's an important difference. Yes, at the end they are Class-Variables, but there's more behind, i.e. a event system if attributes change.

For a better understanding, go to your game inside the games-generated folder and open one of the Design_XX_XX_<Your Behavior>.hx files and have a look how your Stencyl code looks like after generating into haXe.

What's your need for a smaller scope?

...  I want something more elegant
Elegant means: the "temporary attribute" should not show up in the Attribute lists?
On the other way round: if you follow Hectates good advice, you end up writing mixed Stencyl/haXe code using code blocks. That makes the source code unreadable with endless possibilities of bugs.


... and fast.
Not an issue. You can have thousands of thousands local attributes. The compiler optimizes the code very well.

Like a regular local variable in programming languages.
You're using a classic VPL, it's a good advice to change the mindset. Took me a while to adapt.
The elegance of an VPL: the Engine behind can be changed, fixed, whatever without breaking your code.
Another good example: Stencyls switch from 2 to 3, replacing the whole game engine and framework behind (e.g. NME to openFL). Games written purely in Stencyl had no issues at all, but custom code broke.

(I am really thinking of writing a longer post "From Java* to Stencyl" :D )
*whatever
Sure, my games won't get better with all the new features of Stencyl.
But I do have more fun creating bad ones.


MayazCastle Keeper

manu5

  • Posts: 27
Thanks for the ideas and explanations, it helped me a lot to see things in another way. And seriously, a "From programmer to Stencyler" article would be welcomed!

Hectate

  • *
  • Posts: 4643
dripple has a good point about code blocks being more susceptible to breakage. That said, I can fully understand just wanting a simple "Integer i = 0;" variable to use here and there rather than clutter the attributes section of the palette with lots of little single-use ones. As long as you know the risks there are benefits either way.
:
:
Patience is a Virtue,
But Haste is my Life.
Proud member of the League of Idiotic Stencylers; doing things in Stencyl that probably shouldn't be done.

dripple

  • Posts: 748
...ather than clutter the attributes section of the palette ...
That's why I asked for some tweaks in the IDE. A filter and a search function would be great!
But this is another story and shall be told another time (Michael Ende, "Neverending Story)
Sure, my games won't get better with all the new features of Stencyl.
But I do have more fun creating bad ones.


MayazCastle Keeper

gamegirlxl

  • Posts: 713
I've been calling attributes "variables" all the time, which might have been started with the fact that Scratch uses that name, although it was probably perpetuated by the fact that I haven't formally been taught classes yet.  I see the blue attributes like I see the function "string.length();"  where length is technically a variable of string.  I'm being formally taught C++, although I think that Java (which has a confusingly similar name to Javascript) looks like practically the same language.

I try to use custom blocks and such when I want to do a long calculation I don't want to see in my main code.  I think I'm especially vulnerable to the effects of too many attributes and even custom blocks because I'm on a small screen where I constantly need to scroll.  If I can, I try to use lists.  I like lists.

mliga

  • Posts: 22
I've comed to this also some times ago, and made a custom block that was storing temporary values into a single game attribute (of type list); this way i use [set register 1 to anything], and then [get register 1] for get value back; better would be have 'named'  registers, this will require a 2d list or something.
Is this what you're looking for?

dripple

  • Posts: 748
I try to use custom blocks and such when I want to do a long calculation I don't want to see in my main code.
This is another good approach to keep things organized (and I use it very often). Sounds complicated, but it isn't:
  • I use custom blocks very often. I love custom blocks! (okay, changing the signature is a night mare, but...)
  • I "outsource" them into a separate behavior.  I can access the custom block from everywhere.
  • Finally: the Attributes used by that custom block are only visible to in that behavior!

For me, this reflects the classic "Methods" the best.
Sure, my games won't get better with all the new features of Stencyl.
But I do have more fun creating bad ones.


MayazCastle Keeper

Jon

  • *
  • Posts: 17526
"function" level variables are something I've been wanting to put into Stencyl for quite some time, but I haven't though of an elegant, non-error prone (for the end user) and not-too-complicated way of doing this yet.

The best solution I've thought of is to introduce a new wrapper block that lets you define a variable within that and drag the variable out of the block (a la custom blocks) to clone/use it, but this is fraught with all sorts of issues we'd have to anticipate.

dripple

  • Posts: 748
Even if I vote for locals, I doubt that will confuse the most of the users then helping a few of us:
1. Game attributes
2. Behavior attributes
3. Actor values
4. Local behavior attributes?

Is there a technical benefit, Jon?  Would local variables unburden the engine?

Additionally, you need a way to organize the Locals  anyways (renaming, deleting,...), this might introduce a second palette "Locals". But then I vote again for updating the current attribute palette to help us organizing with name spaces (that's how I name my Atttributes)


« Last Edit: April 03, 2014, 10:00:58 pm by dripple »
Sure, my games won't get better with all the new features of Stencyl.
But I do have more fun creating bad ones.


MayazCastle Keeper

manu5

  • Posts: 27
I've comed to this also some times ago, and made a custom block that was storing temporary values into a single game attribute (of type list); this way i use [set register 1 to anything], and then [get register 1] for get value back; better would be have 'named'  registers, this will require a 2d list or something.
Is this what you're looking for?

I like this! Jon, maybe something similar would be nice to implement into Stencyl to solve this function level variables issue.