Reasons why Local Vars should be added

So, Local Vars. Not really used a ton while making anything other than a game.

Then again, if you wish to create a game, local vars can be really helpful.

“How can local vars be helpful in any way?”
It’s really simple. When a sprite is created it can be created with a number to identify itself from the other clones. For example, if you want an enemy to have its own X and Y saved as a var, then local vars can come in handy if you have multiple enemies from the same sprite type.
Not having local vars makes evolution games impossible. It can make many things much more difficult as well.

If Thunkable really wants to become something that makes all apps possible, then you need all the tools.
You can’t build a table with a hammer and some planks. You need nails too. And a saw.

Thunkable can be great, but it has less tools than Scratch or other block code sites.

1 Like

Is this local versus global variables? Or something else? Sprites /are/ created with a component ID that identifies them. You can store those and use them to keep track of and modify individual sprites. What specifically can’t you do that you’d need for an evolution game? (I like a challenge!)

1 Like

The ID isn’t enough in some cases. For example if you want to make a game where it’s in any way scrolling, every sprite would need it’s own X and Y vars. Evolution games require clones of sprites, each with it’s own var (for example, speed, size, color.)

Local vars would just be a great quality of life thing.

1 Like

Which is already available. What do you exactly need?

1 Like

Currently implemented in Thunkable. Each plant has a location (you can drag them around), day it’s going to get picked up, how much you’ll get paid for taking care of it, etc.

I put each plant’s sprite ID into a table, along with other parameters that I wanted to keep track of. Except X and Y - I just get those from the sprite whenever I want them, since the sprites can be moved by the user at any time.

1 Like

catsarisky this is a great idea, but I feel like it’s a little much when you can have just one block of code.

Also, my tables disconnect from the app very often. :frowning:

1 Like


If the brown plane stays in the center of the screen, and all the grey planes are moving objects. Each grey plane would need it’s own X and Y vars in order for this to work.

1 Like

Yep, and it does - use this and plug in each sprite’s component ID (which you can store in a list if you prefer)
image

1 Like

The issue is it needs to be:

Set [object’s] X to [(Scroll X) - (Object X)] Y [(Scroll Y) - (Object Y)]

This wouldn’t work because it’s X would be the result of the Scroll X and it’s X.

I think I’m not following you here?

1 Like

Sorry, this is really difficult to explain :joy:

It’s a scrolling game, ok? That means the player will remain in the center of the screen at all times. The player is not moving, everything else is.

So every thing would need it’s own Location variables that can be subtracted by two other variables, which are scrolling vars which change where everything is.

1 Like

Gotcha. I understand scrolling games. :slight_smile:
So let me see if I can mock that up for a second, because what I’m not understanding is why it isn’t doable, and maybe if I try to do it, then I’ll understand! Or maybe I’ll teach you something. We’ll see!

2 Likes

Also: Keep in mind that the player is moving at angles, not up/down/left/right, and the enemies are also moving.
Screen Shot 2021-07-16 at 11.25.32 AM
This is the code I’m using.

So this:

Here’s the code : Thunkable

2 Likes

I see what you mean now. I still think local vars could be useful for Thunkable.

Thanks again!

And now I want to build a scrolling game! :slight_smile:

You mean a variable scoped to the screen, right?

You can accomplish this by using function parameter variables. These are only accessible on the screen they live in

1 Like

No, a local variable is a variable that is limited to one sprite only.

The use of this is that a lot of sprites can have different values in the same variable, without having to create all those variables.

(also that picture is very blurred I can’t really see what’s going on.)

They can still be local in this sense. You can type a variable to be an object with key value pairs or have paths or both. This way you can assign many values to 1 variable in an orderly fashion.

SpriteVar:{
“Value1”:34,
“Value2”:485
}

For example

If I get to a computer I’ll while up an example. I use pathways to save data to cloud variables to objects.

You can do the same idea for app variables and in effect make each variable it’s own JSON tree filled with different key:value pairs and buckets to hold different info.

It’s a nice way to cut down on the total number of variables you use. But it requires you to be mindful of the data structure at all times.

1 Like