Teacher guide: Arcade Foundations

The idea in plain words

An Arcade game is made of sprites: small pictures the game can place, move and test. The screen is 160 pixels across and 120 down.

• A sprite's position is two numbers, (x, y). x counts across from the left; y counts down from the top. So (0, 0) is the top left corner and (80, 60) is the middle.
• A sprite's velocity (vx, vy) is a speed in pixels per second. The game engine moves the sprite a little every frame (each redraw of the screen, about 30 a second), and keeps going until something changes it.
• move with buttons hands a sprite to the arrow keys, and on A button pressed is an event: it runs its blocks each time A is pressed.

The simulator (the little game console beside the blocks) runs the game straight away. Click it first so it hears the keyboard: arrow keys or W, A, S, D move, space or Z is A.

Why programmers use them

Every 2D game is pictures on a grid, moved. A game engine saves work: you say where a sprite starts and how fast it goes, and the engine draws every frame. Velocity is how clouds drift, cars drive and balls fly without a single loop.

An everyday picture, and where it breaks

A position is a pin on a map: it says where you are now. A velocity is cruise control in a car: set it once, and the car keeps going at that speed until you brake.

Where it breaks: setting a speed is not "move this far". A sprite with vx 30 does not stop after 30 pixels; it drives off the edge of the screen unless something stops it (stay in screen, bounce on wall, or a new velocity).

Try it yourself (5 minutes)

1. In the first lesson, change the duck's y from 100 to 20. It jumps to the top, because y counts down.
2. In the second lesson, run the plane. Steer it, then watch the cloud bounce by itself.
3. Change the cloud's velocity from 30 to -30, and to 30, 20. Which way does it go each time?

Questions students ask

• "Why is my sprite at the bottom when I wanted the top?" y counts down from the top. Use a small y.
• "Why do the arrow keys do nothing?" Click the game screen first, and check move with buttons names your sprite.
• "Why did my sprite slide away for ever?" You set its velocity (a speed), not its position. Change x to move it once.
• "Why did my old sprite disappear when I made a new one?" Both use the same variable name. Click the name and choose New variable.

How it connects

Next unit sprites notice each other: an overlap event runs when two sprites touch. Velocity returns with timers (enemies that fly in), chasing, and gravity, which is a change of velocity every frame.

The idea in plain words

Sprites pass through each other, but the game notices when they overlap (touch). Three ideas make that into a game:

• Every sprite has a kind: Player, Food, Enemy or Projectile. The create block starts with of kind Player, so change it for coins and monsters.
• An on overlap event names two kinds. It runs when a sprite of the first kind touches a sprite of the second kind, and for no other pair. Inside, sprite is the first one and otherSprite the second.
• Info blocks keep a score, lives and a countdown at the top of the screen, and end the game by themselves when the lives or the countdown reach 0.

A timer event, on game update every 1000 ms, runs its blocks again every so many milliseconds (1000 ms is one second). It can make a new enemy each time.

Why programmers use them

Nearly every game rule is "when this touches that, do something": eat the dot, lose a life, open the door. Kinds let one event cover every coin in the game. Info and timers are jobs the engine does for you, so a game can be built in a lesson.

An everyday picture, and where it breaks

Kinds are like coloured wristbands at a school sports day: the rule "red meets blue, blue scores a point" works for every child, whatever their name. A child with the wrong wristband is ignored by the rule.

Where it breaks: an overlap is not a single tap. It runs every frame (about 30 times a second) while the sprites still touch. An enemy that is not destroyed or moved away takes a life every frame, and the game ends at once.

Try it yourself (5 minutes)

1. In Overlaps and kinds, collect the coin, then change the coin's kind to Player. Now it cannot be collected.
2. In Score, lives and timers, play the dodge game and lose on purpose. No game over block was needed.
3. Take destroy out of the Player–Enemy event and touch one rock. All the lives go at once.

Questions students ask

• "Why doesn't touching the coin do anything?" Check its kind matches the second kind in the overlap event.
• "Why did the player vanish instead of the coin?" Destroy otherSprite, not sprite.
• "Why did one hit take all my lives?" The enemy is still touching. Destroy it in the overlap event.
• "Why do no enemies appear?" Start them at x 160 with a negative vx, inside the timer, not in on start.

How it connects

The Decide unit adds if inside on game update, checked every frame (wrap-around, safe zones, chasers). Projectiles bring another kind, and the final challenge, Space dodger, is this unit's dodge game grown up.

The idea in plain words

An if block asks a yes-or-no question (a condition), such as car x > 160. When the answer is yes (true), it runs the blocks inside. When it is no (false), it skips them and does nothing.

else adds an "otherwise": exactly one of the two parts runs. else if adds more questions, asked from the top; the first true one runs and the rest are skipped.

In Arcade the big question is when an if is asked. A game redraws the screen about 30 times a second; each drawing is a frame. on game update runs its blocks every frame, so an if inside it keeps asking for as long as the game runs. on start runs once, before the game begins, so an if there is asked one time and never again.

Comparisons are in Logic: < less than, > greater than, ≤ and ≥ with "or equal to". A sprite's x and y blocks are in Sprites. Remember y counts down the screen.

Why programmers use them

Decisions are what make a game react: wrap around when you leave the screen, change the music in a safe zone, turn an enemy towards you, make a guard turn at the end of its walk. Each one is a position (a number) and a question, asked every frame.

An everyday picture, and where it breaks

A lifeguard watching the pool: every few seconds she asks "is anyone in the deep end who shouldn't be?", and acts the moment the answer is yes. That is an if in on game update. An if in on start is a lifeguard who looks once when the pool opens, sees nobody, and goes home.

Where it breaks: a lifeguard blows her whistle once. An if in on game update acts every frame while its question stays true, so anything inside it (a point, a lost life) happens 30 times a second unless the blocks inside also make the question false (as wrap-around does by moving the car back to x 0).

Try it yourself (5 minutes)

1. In the If lesson, run the car: it wraps around the screen. Then load Sam's version (the if in on start): the car drives away for good.
2. In the Else lesson, run away from the cat with the arrow keys. It only follows you left and right.
3. Add a second if … else for y and vy. Now it chases you everywhere. Then load the follow version: one block does the same.

Questions students ask

• "Why doesn't my if do anything?" Check where it is. In on start it is asked once, before anything has moved.
• "Why does my enemy run away?" The speeds are the wrong way round. If the player has a bigger x, they are to the right, so the enemy's vx must be positive.
• "Why does my score shoot up?" Something inside on game update runs every frame. Put it inside the if, and make sure the if stops being true.
• "Why build the chaser if follow does it?" So you know what follow does. Your own version can do things follow cannot, such as chase only when the player is close, or run away.

How it connects

Next unit fires projectiles, steered by the same if and else. In Arcade advanced skills the same idea gives a floor for jumping (if the player's bottom is below the ground, stop falling), and the Level up lesson shows the trap from the other side: an if that stays true in on game update fires every frame.

The idea in plain words

A projectile (in Sprites) is a sprite fired from another sprite, with a speed across and down. It has its own kind, Projectile, so the overlap that catches a hit names Projectile and Enemy, not Player. The engine removes a projectile once it leaves the screen.

Read a game is a review lesson with nothing new: a complete game, longer than anything so far. Students find the blocks that do each job (make an enemy, fire, score a hit), trace what they do, and change just those to change the game.

Why programmers use them

Firing is the heart of every shoot 'em up, and its kind keeps a shot's rules apart from the player's. Reading before changing is how programmers work on code they did not write: find the part that does the job, change only that.

An everyday picture, and where it breaks

A projectile is a ball thrown by a player: once it leaves the hand, it flies on its own.

Where it breaks: in a game the ball is not the player, so "the player touched the enemy" never sees a hit by the ball. The game needs a rule for the ball's own kind.

Try it yourself (5 minutes)

1. In the Projectiles lesson, fire at the alien with the A button (space on the keyboard).
2. Change the overlap to Player and Enemy and fire again: the shots pass straight through.
3. In Read a game, find the one number that decides how often enemies arrive.

Questions students ask

• "Why do my shots go straight through?" The overlap names Player and Enemy. A shot is a Projectile.
• "Why does the shot go the wrong way?" Its speeds are vx and vy: vx across, vy down. A shot upwards has a negative vy.
• "Do I need to destroy shots that miss?" No: the engine removes a projectile once it leaves the screen.

How it connects

The final challenge, Space dodger, uses rocks, lives, timers and decisions together. Arcade advanced skills starts with every sprite of a kind: one press that does something to every alien at once.

The idea in plain words

The challenge builds Space dodger: a ship moves up and down, rocks fly in from the right, a hit costs a life, and the score counts the seconds you survive. It uses every idea from the course, with only two new blocks:

• auto destroy (the set flag block in Sprites): a sprite is removed once it leaves the screen, so rocks that miss do not pile up.
• high score (in Info): the best score so far in this browser. The game over screen shows it by itself.

The lesson is built in three milestones with less help each time: most of the code, then an outline, then goals only. Finishing it marks the course Challenge complete.

Why programmers use milestones

Real programs are combinations: variables, events, decisions and timers working together. Building in milestones keeps a game playable at every stage, so each change can be tested by playing. Game studios work the same way: prototype, playtest, change one thing.

An everyday picture, and where it breaks

Milestones are building a cubby house: first a floor you can stand on, then walls, then a roof. You can use it after every step.

Where it breaks: a cubby's floor stays put, but code that worked can stop working when you add the next part. Play the game after every milestone, not only at the end.

Try it yourself (5 minutes)

1. In Space dodger, play the Run step: every rock comes down the middle. One pick random block turns it into a game.
2. Take destroy out of the Player–Enemy overlap and touch one rock: all three lives go at once.

Questions students ask

• "Why did one rock take all my lives?" The overlap runs every frame the sprites touch. Destroy the rock in the event.
• "Why does my score race up?" It is in on game update (every frame). Use on game update every 1000 ms.
• "Where did my high score go?" It is kept in this browser; another browser starts again at 0.

How it connects

This ends Arcade Foundations. Arcade advanced skills goes on to every sprite of a kind, functions, gravity and jumping, levels and power-ups. Microsoft's Beginner Skillmap (arcade.makecode.com/skillmaps) practises the same moves inside guided games.

Make a collecting game: the player moves around, treasure appears in random places, collecting it scores, and something changes when the score gets high enough (the background, the speed, a message). Your own player, treasure and setting.

Milestones:

• My player moves with the controller and the treasure appears somewhere new each time.
• Touching the treasure scores a point.
• Something changes when the score passes a number I chose, decided by an if.

All blocks from Arcade Foundations lessons 1 to 7. Students who want art can draw their own sprites in the image editor; set a time limit on drawing.

scene.setBackgroundColor(7)
let hero = sprites.create(img`
    . 2 2 .
    2 2 2 2
    2 2 2 2
    . 2 2 .
    `, SpriteKind.Player)
controller.moveSprite(hero)
hero.setStayInScreen(true)
let coin = sprites.create(img`
    . 5 5 .
    5 5 4 5
    5 4 5 5
    . 5 5 .
    `, SpriteKind.Food)
coin.setPosition(randint(10, 150), randint(10, 110))
sprites.onOverlap(SpriteKind.Player, SpriteKind.Food, function (sprite, otherSprite) {
    info.changeScoreBy(1)
    otherSprite.setPosition(randint(10, 150), randint(10, 110))
    if (info.score() >= 10) {
        scene.setBackgroundColor(9)
    }
})

Make a chase game: enemies follow the player around the screen, and the player has to survive, reach a goal or collect things to escape. How the enemies move, and how you win, are your choice.

Milestones:

• At least one enemy follows the player (it turns towards them, using if and else).
• Getting caught costs a life, once per catch.
• There is a way to win, and the game says so.

The usual bug is losing all lives at once: the enemy must be destroyed or moved away in the overlap, as in Score and lives. Ask students to say how the enemy decides which way to go before they build it.

scene.setBackgroundColor(1)
info.setLife(3)
let hero = sprites.create(img`
    . 8 8 .
    8 8 8 8
    8 8 8 8
    . 8 8 .
    `, SpriteKind.Player)
controller.moveSprite(hero)
hero.setStayInScreen(true)
let ghost = sprites.create(img`
    2 2 2 2
    2 f 2 f
    2 2 2 2
    2 . 2 .
    `, SpriteKind.Enemy)
ghost.setPosition(randint(0, 160), 0)
game.onUpdate(function () {
    if (ghost.x < hero.x) {
        ghost.vx = 30
    } else {
        ghost.vx = -30
    }
    if (ghost.y < hero.y) {
        ghost.vy = 30
    } else {
        ghost.vy = -30
    }
})
sprites.onOverlap(SpriteKind.Player, SpriteKind.Enemy, function (sprite, otherSprite) {
    info.changeLifeBy(-1)
    otherSprite.setPosition(randint(0, 160), 0)
})
info.startCountdown(30)
info.onCountdownEnd(function () {
    game.over(true)
})