Collisions and Triggers: Using Overlaps in MakeCode Arcade
Even back in the late 1970’s, during the golden days of arcade games, people expected their experience to be interactive. Yes, they wanted to control their character — but they also wanted their environment to respond to their presence.
Think about the fruit in Pac-Man, the flag pole in Super Mario Bros., or the barrels in Donkey Kong. The programmers of those games had no idea when your character would run into one of those items. How could they? And yet, the games responded at just the right time. This is made possible using “collision events”.
In MakeCode Arcade, collision events are triggered using overlap
containers.
These special blocks look for collision events, then run the code inside when one is triggered. This concept may appear to be pretty simple but let’s dig deeper to see what it looks like while you’re coding.
The first thing to notice is that the outer block is shaped like a container. This is meant to indicate a clear beginning and a clear ending to the code that runs when it’s triggered. The reactions start when the title condition is met (in this case, when a Player sprite overlaps a Food sprite) and it will run all of the blocks inside until it gets to the bottom of the container.
How do the blocks inside know which sprites to act on? Ideally, the coder limits the reactions only to the two sprites that overlapped.
In the example above, one sprite is kind Player and one sprite is kind Food. The title condition tells us that the Player will go by the name “sprite” and the Food will go by “otherSprite” — which is why the animation shows the programmer dragging the otherSprite
variable into the destroy
block. Clearly, we want to destroy the Food when there’s a collision.
Using the method above, we can be sure the code runs on the exact two sprites that overlapped.
MakeCode Arcade has other overlap blocks, as well. Look at the image below to learn how to use a container that runs code when a sprite overlaps a tile on your tilemap.
The first half of this container condition works just the same way the previous one did. It will run the code inside when “sprite” of kind Player overlaps the tree tile. This time, instead of having an otherSprite
variable to use in your code, you’re given a location
variable so that you can detect the exact spot on the map where your sprite overlapped the tile.
Finally, there’s a similar container that detects when your sprite hits a wall (whether that’s the side of the game window, or a wall in your tilemap.)
Just like the last one, this gives the name “sprite” to your Player, and gives you a variable called “location” that holds the details for the place where the sprite hit the wall.
With just these three overlap containers, you can build all sorts of magical worlds where sprites interact, secret portals reveal hidden treasures, and the end of the road means the end of the game. Try building something of your own, then share your game in the comments to help new readers understand how collisions work!