Arrays, implicit?


I wrote a game that created an array and explicitly added Enemy Sprites to it so I could reference them and have them do things like randomly shooting.

BUT, I had a student write a game, and he simply declared an array of Enemy and arcade seemly just implicitly references all Enemy already created. Is this a quirk or really how it is designed? If I create more Enemy, are they automatically in the array of Enemy?


1 Like

That is by design. It allows you to grab all references to sprites of kind.

Yes, but sprite list (in the pic above) won’t update automatically.

Is there a way to refresh it? Should we call set sprite to array of ‘kind’ before each use? Or should I teach more explicit handling of the array?

Yes, or you can just use it directly since it’s an array by itself.

1 Like

To break down the complication for young coders, we use the following model:

  1. Variables are containers for data;
  2. The execution of ‘set xxx to y’ instruction;

The actual execution of ‘set xxx to xxx’ instruction has 2 steps:

  1. the ‘array of sprites of kind xxx’ part, looks for all sprites of certain kind and put it into a temporary container;
  2. looks for a container named ‘sprite list’ (create one if not exists), put every item from the above container into it.

After that we have a container named ‘sprite list’ with all sprites of kind at the moment of execution, in this case, an apple and a donut.

Note: Common misunderstanding for young coders is that considering ‘set variable_y to x’ as something like ‘y = x^2 + 123’ in algebra, in algebra, all later reference to y is exact ‘x^2+123’(declaration form), while in aracde.makecode programming env variable_y is what ‘x’ is at the moment of the execution of ‘set variable to x’ instruction(value form).

This is a simplified model, masking complication of pointers, pass by value / pass by reference, but easy to understand for students.

Hope it helps.

1 Like

Whenever you create a sprite, it is being tracked (in the game, but really it is stored in the ‘sprites’ class). So whenever you call ‘array of sprites of kind’, it calls the function within the sprites class to get all instances having that kind. So there is really no need to keep your own sprite list, unless you want to limit which sprites are added to it. If that is the case, then you would explicitly use the ‘add’ functions to do so.


This is all very helpful. Why haven’t any of you written an O’Reilly manual for makecode? :wink: I am seriously asking.

Question then, was the set sprite list in my example even needed? Looks like this works:

Going to be very nice to remove these complicated constructions from my instructions…most kids can pull this off from my remote videos, but a few are really good at messing up the nesting :wink:

Thank you all! Really appreciate the help!


The idea of defining a sprite to be a certain ‘kind’, is definitely a improvement and a great help in finding sprite in your game. In Touch Develop, Arcade’s predecessor, you had to indeed keep track of the sprites you created by adding them to an array (if for instance you wanted to destroy them, or recycle them later).

You might want consider why you are using an array in the first place, especially if you are keeping track of them just to destroy them. In a screen game (no tilemap which has walls), you could also set them to ‘auto destroy’ (this means they dispose of themselves when leaving the screen). For a tilemap (which is bounded by external walls), you could set them to ‘destroy on wall’ so they dispose when hitting a wall.


1 Like

Thanks again! We definitely need the array as a fleet of enemy ships is flying toward us and firing their lasers :smile:

And instead of destroying them when leaving screen or when we hit them, we just send them back to stage left to fly in again. Really reinforces understanding of the coordinate system and location.

Thanks again for helping wrap my C brain around the arcade way. Here is the simplified approach to the very incomplete game:

1 Like

Recycling sprites is probably better for the performance of the game, instead of allocating and removing memory each time. It is also good to understand how arrays work, but also to consider how many sprites are being used in a game.

You have developed a really good game, especially how the spawning of sprites is random. I noticed that you recycle the ‘EnemyBorg’, when they leave the screen left. However, you have not cleaned up the enemies lasers. You should set these to auto-destroy as well. In the screen shot you see the number sprites continuously increases. You can see how many sprites are in use by selecting ‘Show Stats’ in the Menu.

In the Status Bars extension you can also set the event when the health reaches zero. For instance:

Really good game, well done.