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.
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!)
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.
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.
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.
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.
Gotcha. I understand scrolling games.
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!
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.
