"galaga" tutorial creates unlimited number of enemies without ever destroying them

[yellowsilver]

Describe the bug Website https://arcade.makecode.com/#editor contains a tutorial called "galaga". When I create a game following this titorial and I upload it to meowbit, the game works correctly for a few minutes, but then starts to slow down and becomes unplayable. It is caused by the fact that the game creates unlimited number of enemies without ever destroying them.

To Reproduce

1. Create a game by following "galga" tutorial.
2. Upload it to meowbit.
3. Play it for five minutes.
4. See how the game slows down and becomes unplayable.

Expected behavior Game created by following "galga" tutorial should not slow down.

Desktop (please complete the following information):

• OS: Linux Mint
• Browser: Firefox

Additional context In my opinion, problem can be fixed by improving the tutorial. We should add there a piece of code which periodically deletes out of screen enemies. Such code can be seen here: https://makecode.com/_3TudXg9R6baU

It is just:

game.onUpdateInterval(5000, function () {
    for (let e of sprites.allOfKind(SpriteKind.Enemy)) {
        if (e.x < 0) {
            e.destroy()
        }
    }
})

[abchatra]

@ganicke can we fix the tutorial to set autodestroy for the enemy sprites?

[ganicke]

Sure, I'll look at that. Could leave the current behavior as an allegory for life.

[ganicke]

@abchatra - We can add to the onUpdate() event to AutoDestroy them. However, the starting location needs to change to 168 in order for enemies to survive until they get on-screen:

game.onUpdateInterval(500, function () {
    bogey = sprites.create(img`
        . . . . . . . . . . . . . . . . 
        . . . . . . . . . . . . . . . . 
        . . . . . . . . . . . . . . . . 
        . . . . . . . . . . . . . . . . 
        . . . . 9 9 . . . . . 5 . . . . 
        . . . 9 9 9 9 . . . 5 5 . . . . 
        2 2 2 2 9 9 2 2 2 2 2 f 4 4 . . 
        . . 2 2 2 2 5 5 5 2 2 f 4 4 4 . 
        . . . . . . 5 5 5 . . . . . . . 
        . . . . . . . 5 5 . . . . . . . 
        . . . . . . . . 5 . . . . . . . 
        . . . . . . . . . . . . . . . . 
        . . . . . . . . . . . . . . . . 
        . . . . . . . . . . . . . . . . 
        . . . . . . . . . . . . . . . . 
        . . . . . . . . . . . . . . . . 
        `, SpriteKind.Enemy)
    bogey.setVelocity(-100, 0)
    bogey.setPosition(168, randint(0, 120))
    bogey.setFlag(SpriteFlag.AutoDestroy, true)
})

[abchatra]

@riknoll @jwunderl for the opinion.

[ganicke]

2613 takes @jwunderl 's suggestion and replaces setPosition() with .left() and .y. This solves the initial off-screen problem.

[jwunderl]

I think without changing stuff inside arcade that's the safest change (it does make the tutorial a small amount more involved in having them use the dropdown to find left, it's very useful property to know exists). Getting rid of the 'random' magic 120 / 180 values in favor of screen width / screen height likely makes it a bit easier to understand what's going on at least to even things out~