Hey folks!
I was recently asked by someone who runs a coding club about what pitfalls I often see when people are making games in Arcade. I started writing it up in an email, but decided that this list might actually be useful to other people who are making games in Arcade or are helping to teach classrooms of students. This is going to be a “living” topic that I’ll keep updating as I think of other things to add.
Likewise, if you have something that you think should be included in this list, please let me know in the comments!
Pitfall #1: Wrong variable
This happens when a coder forgets to change the variable dropdown in a sprite block from the default variable. For example, in this snippet the variable in the second position block should be “myEnemy” and not “mySprite”
Pitfall #2: Using global variable instead of local
This happens when a coder is creating multiple enemies and they use a global variable instead of the local variable inside an overlap event.
For example, in the snippet below a new enemy is created every half a second. Every time the code in the on game update runs, the myEnemy variable is reassigned to the new sprite being created.
The overlap event is supposed to destroy an enemy when it overlaps with the player, but because it’s using the global variable myEnemy, it will always destroy the most recently created enemy sprite and not necessarily the one involved in the overlap event.
The fix for this is easy, you just need to drag the local variable from the overlaps event block like so:
Pitfall 3: Using an unassigned variable in an event
Coder references a global variable inside an event that is not necessarily assigned yet.
This is usually caused by blocks that pause. For example, in the code below a cutscene plays using the arcade-story extension before the player sprite is created. If the player presses the A button before the cutscene finishes, it will trigger a simulator error:
The fix here is to create a boolean variable named something like “gameHasStarted” that you can check before referencing the sprite:
Pitfall 4: Code pauses somewhere it shouldn’t
This happens when a block that pauses is used somewhere time-critical like an on-game-update loop. You can usually recognize this happening because the game “freezes” for a few seconds before continuing or gets stuck on a black screen even though there’s no simulator error.
By “block that pauses”, I mean any block that waits until whatever it is doing is complete. The most commonly used blocks that pause are:
- The play sound/song/melody/effect blocks in the music category
- The print text blocks in the arcade-story extension
- The pause block in the loops category
These blocks pause the current thread, which is fine in most cases but not fine if done inside the game-update thread. Here’s an example snippet that demonstrates what I mean:
If this were in a game, the game will freeze when the score reaches 100 until the sound effect finishes playing. The fix in this case would be to change the on game update block into a forever block from the loops category.
Here’s a partial list of blocks where it is not okay to pause:
on game updateandon game update every * msin the game categoryon sprite of kind overlaps tilein the scene categoryon sprite of kind hits wallin the scene categoryon life 0,on score, andon countdownevents in the info category
And here is a partial list of blocks where it is okay to pause:
on sprite overlaps other spritein the sprites categoryon startin the loops categoryforeverin the loops categoryon button pressedevents in the controller category
Pitfall 5: Not handling overlap events between sprites
This happens when you have an overlap event between two sprites and you don’t handle it properly. The usual sign that this is happening is you see a player’s lives suddenly going from a high number to 0 when overlapping with a sprite or the player’s score climbing up very quickly.
This problem is caused by the fact that overlap events fire once every time the game updates. Arcade games typically run at a framerate of 30 frames per second, so your event will trigger 30 times a second!
Here’s a snippet that demonstrates this bug:
To fix this code, there are a few things we can do.
Option 1 is to simply destroy one of the sprites (make sure you drag out the local variable). This option might be appropriate if one of the sprite’s is a collectible item like a coin or something like a projectile/enemy:
Option 2 is to move the sprites so that they are no longer overlapping. The way you do this will depend on what kind of game you’re making, but here’s an example that moves the enemy to the right of the player sprite:
Option 3 is to make it so that one of the sprites can no longer overlap with sprites temporarily. Games often do this to make player sprites temporarily invincible after taking damage. This example does this by setting the “ghost through sprites” flag to true on the player sprite for 1 second:
Pitfall 6: Creating lots of sprites and never destroying them
This usually happens when a coder creates enemy sprites inside of an on game update or on game update every * ms block and doesn’t clean them up properly. The usual sign this is happening is that your game starts out running smoothly but gets laggier the longer you play it.
For example, this code creates enemies every half second on the right side of the screen and makes them fly to the left of the screen. If the player overlaps with an enemy, it gets destroyed. However, if the player doesn’t overlap the enemy then it will go past them off the screen and keep flying off screen forever:
To fix this code, we can set the “auto destroy” flag to true when we create our enemy sprites. This flag will automatically destroy sprites that go off screen:
If you have a game where you don’t want sprites to be destroyed when they go off screen, you can also consider checking how many sprites exist before spawning a new one. This snippet uses the length of the array of sprites of kind block to stop spawning enemies if there are already 20 alive in the game:
