Game/Code freezing

arcade-T4L-HarrierV3 Hey guys, I’m doing well teaching myself this awesome platform. I currently have a meowbit and love testing it on the device. However, i’m at the point now where my simulator is getting really laggy, unresponsive. It runs great on the meowbit UNTIL you get up to the boss, then it as well starts to freeze. Wondering if someone could have a look at my code? Is there something in there making it super unresponsive? Is there a more efficient way to do what I’m doing here in terms of code? Or is there just too much code for the simulator to handle at the moment (i’m hoping that’s not the case! I’d love to have games that scale into decent sized projects). Any help appreciated!
Will upload my space shooter (not much happens after the first boss until I fix this plus, I’ve set the health of everything to low so one can progress quickly).

1 Like

I love your game! It has a lot of character.

I was able to play your game on two different machines in two different browsers. It worked fine in Google Chrome on a rather underpowered laptop, and then I ran it in the new Edge on the desktop in my office. Ran fine on both. What browser are you using? I’ve noticed that Firefox runs MakeCode Arcade really poorly. Clarification: I’ve found that Firefox, in general, runs really poorly with many applications, MakeCode Arcade included.

Then, I ran your game on my BrainPad Arcade. It seemed to work fine for a bit, and then I got an out-of-memory error (Error 21). I thought that was a little odd, since there didn’t seem to be anything terribly crazy about your code in terms of memory use.

The first thing that I did was to turn on stats on my BrainPad Arcade. (You can do this in the browser simulator, too.) When a game is running (and not showing a message from something like game.splash), press the Menu button to get to the diagnostics screen. There, turn on stats. Press B or Menu to get back to your game. (The icon that displays statistics is selected in the following screenshot. It looks like a stopwatch.)


I watched the stats as I played your game, and noticed that the game was tracking more sprites than I saw on the screen. So, I took a closer look at your code for anything that might cause memory problems. I found a couple, along with a couple of other things that looked a little off the mark.

One place where you are creating sprites that will not auto-destroy is where you are creating the bosses.


The second line - set Bosslevel1 to sprite of kind Boss - is fine. This line, though, creates a new sprite each time this function is called … which means we need to make sure that the old boss sprite is destroyed. You have a perfect place for that already, so I made a small change:


I added the line set Bosslevel1 auto destroy ON so that, when the boss flies away, as soon as it leaves the screen, the sprite is destroyed.

You use projectiles for the shots fired by the player and the boss, as well as for the asteroids, and that’s perfect. Projectiles auto-destroy when they leave the screen.

The other place that I thought may be causing a problem is with the player’s shots. I noticed that when I fired shots that there seemed to be too many sprites that my BrainPad was tracking. I’m thinking that, because of the effect that you’re using on the shots, it was still tracking player shots after they’d left the screen. I removed the line that creates the “cool radial” effect, and the number of sprites seemed more accurate. Try either removing that line for now or shortening the time that the effect is displayed, since the shots aren’t on the screen for one second.

Those were the only two places that I saw where you may be chewing up memory. I corrected a couple of other bugs, too.


I added the first line, which destroys the projectile when it hits the boss. Without it, the projectile keeps hitting the boss, usually triggering this collision enough times to make the boss run away after just one shot.

If you go back to your Boss Escape function, you set vx and vy to be a random number between 0 and 0. That will always be zero. :slight_smile: No need for the random number. Just set them to zero.

The last error is in your first game.onUpdate function:


You have set Bosslevel1 vy to pick random -100 to -100. One of those is probably a typo. You probably meant for one of those to be 100, not -100.

After my changes, the game still would generate Error 21 on my BrainPad Arcade from time to time, but not nearly as often as before. Anyone else see anything that would cause memory issues? I know that there were up to 20 sprites on the screen from time to time, but I’ve created games with that many sprites before and it didn’t seem to pose a problem.

Again, great game! Keep working at it!


@AlexK Those look like some nice fixes to start making it run better :slight_smile:

I haven’t had time to take a look at the game itself quite yet, but could you tell me if it always seems to crash around the same time as the scene changes (e.g. just before / after a splash screen or when opening a menu)? If so, that crash is very possibly due to this issue, which will be fixed with this change (I need to go back and finish testing / fixing any issues it causes, I just got went down a small rabbit hole fixing a minor thing the fix broke).

Basically what’s happening in that bug is that it’s letting the game update loop run multiple times at once for a little bit after each scene change. Will take a look at the code tomorrow and see if I can find anything else though! (also we’ll have to check on firefox as well, it’s always worked fine on my computer before? Maybe just need to try a wider variety of computers on firefox to see what’s going on)

IIRC, the Error 21 would happen pretty randomly. I didn’t notice much of a pattern other than the sprite count was above 15. It might have been crashing during a collision … not really sure, though.

I’ll go back and edit my statement about Firefox. It’s nothing really to do about MakeCode Arcade specifically. I find that any JavaScript application runs relatively poorly in Firefox. On my teaching computer last week during class, I forgot that I didn’t have Chrome installed. So, I ran MakeCode Arcade in Firefox, and it did not go well. Adobe Connect chews up so many cycles as it is, and throwing Firefox into the mix just made my computer very sad. We made it through and, before class tonight, I installed Chrome on that computer. Worked like a champ, even with Adobe Connect trying to drain the life out of the computer.

FWIW, MakeCode Arcade also works wonderfully in the new Chromium-based Edge. Mac and Windows both!

I have noticed an oddity in Edge proper (i.e. not Chromium Edge) with MakeCode Arcade that I haven’t noticed in other browsers: Whenever I save a cartridge (i.e. click on the “Save” button), the whole application immediately bogs down to the point that, if I’ve saved a program a couple of times, I have to close Edge and reopen it. Really bizarre, and it’s peculiar to Edge. Maybe not worth pursuing, given the switch to the V8 JavaScript engine when the new Edge gets pushed out.

Thanks guys, those fixes made it run smoother. I’m finding however, edge can run my game pretty hit and miss. Lots of delays and input lag. When I install Java separately and run makecode arcade in chrome using the Java plugin, it runs 110% better. Someone else might be able to confirm this - just found it interesting, my game went from unplayable in the simulator to completely playable (the fixes also helped! but it still run a bit funky in edge).

Question! The BIG one. Any idea roughly when MakeCode is coming out of Beta? It already seems like such a polished product - just curious to hear about it’s roadmap, timeline or any updates in the near future. The only thing I’ve heard recently is the assignments integration in MS teams. I’m part of a 23 million dollar STEM project here in NSW and we love utilising this in our government education system. When people see the word ‘Beta’ eyebrows are always raised. Any little hints of timeframes? :slight_smile:

For best performance use Edge Insider builds. It’s as fast or faster than Chrome since it uses the same engine.

I’m not sure why you needed to install any Java plugin - this is not needed.

@AussieAlpha we’ll get back on a timeframe for the full release of arcade next week when our Project Manager gets back :slight_smile:

1 Like

I was using a non-insider Edge version on a surface pro 4. Did the research about not installing Java but thought I would try different combinations to see if anything resulted in better performance, for this insistence, surface pro 4’s at least, that’s what yielded the best result. Great tip on Edge insider builds. I might give that a go a compare performance. Thanks!

Hi there! I just spoke with some folks from NSW about your MakeCode for Minecraft implementation. You guys are doing some really cool stuff! :smile:
With regard to timeline for Arcade - we’re hoping to pull it out of Beta sometime this calendar year, but we don’t have any dates yet. The big thing that’s keeping us from GA is performance improvements…
Hope that helps!


Hi Jacqueline.
Great timing! I just got word from our NSW tenant administrator (Michael Clipsham) that he was only talking to you recently and then I saw this nice little reply. Thanks for the feedback about our work and also thanks for the information about beta - subject to change I know, but it’s a great indictor that MakeCode Arcade isn’t going away anytime soon! We are having too much fun with it! Do keep in touch!

hey guys I don’t seem to see your code anywhere. Could you send me the link.