Teacher guide: Arcade advanced skills

The idea in plain words

array of sprites of kind Enemy gives a list of every enemy in the game right now, and a for element loop (in Loops) runs its blocks once for each one, so one press can freeze or destroy them all.

A function (in Functions, under Advanced) is a named job: some blocks with a name, such as spawnBug. Making it does not run it; a call block runs it, once per call. A parameter is an input the call hands in, such as speed in spawnEnemy(speed), so one function can make a slow bug and a fast bug.

Students can also look at the Python view of their programs. The big idea: every event block (on overlap, on A pressed, on game update every) is a function, handed to the game to call when the event happens.

Why programmers use them

A game cannot give every alien its own name: a list lets one block deal with all of them. Functions name a job once (make an enemy, make a coin), so it can be used from anywhere and fixed in one place.

An everyday picture, and where it breaks

The list is the class roll: "everyone on the roll, stand up" works however many students there are today. A function is a recipe card: "make the sauce (see card 12)", and the parameter is "for 4 people" or "for 10".

Where they break: a roll is written once a term, but array of sprites of kind is a fresh roll every time it runs, so a new alien is on it straight away. And writing a recipe card does not cook anything until someone follows it, just as making a function does not run it until it is called.

Try it yourself (5 minutes)

1. In Every one of a kind, press B with a few aliens on the screen.
2. In Functions, delete the call in on start and run: nothing appears.
3. In Parameters, change the number in one call, not inside the function, and run again.

Questions students ask

• "Why does only one alien freeze?" The block is outside the for element loop, or it names a sprite, not the loop's value.
• "Why doesn't my function do anything?" Nothing calls it. Add a call block where the job should happen.
• "Where is the call block?" It appears in the Functions drawer once the function has been made.
• "Why are all my bugs the same speed?" The number is fixed inside the function. Use the parameter there, and put the numbers in the calls.

How it connects

The next units use them all: a jump inside an if, a level-up in the event where the score changes, and a startLevel function that reads a list of speeds.

The idea in plain words

Gravity is one more number on a sprite. vx and vy (velocity) are how far the engine moves it every frame; ay (acceleration) is how much the engine changes vy. With ay 300, vy grows by 300 every second, so a sprite falls faster and faster. A jump is a speed upwards: a negative vy, because y counts down the screen. Gravity slows the jump, stops it and brings the sprite back.

An empty Arcade screen has no ground, so a falling sprite drops out of sight. Students build a floor with an if in on game update: if the player's bottom (the y of its lowest edge) is below 100, put it back at 100 and set vy to 0. A jump should only happen from that floor, so the jump goes inside if bottom ≥ 100.

Why programmers use them

Gravity and a floor are the heart of platformers and runners.

An everyday picture, and where it breaks

Gravity is a ball thrown up in the playground: it slows, stops at the top and comes back faster.

Where it breaks: a real ball lands on the real ground. In Arcade nothing is solid until you say so, either with your own if or with tilemap walls.

Engine note: tilemaps

Real Arcade platformers use a tilemap: a world drawn from squares (tiles) in the tile editor. Wall tiles stop sprites by themselves (a floor without an if), and the camera can follow the player through a world bigger than the screen. This is why platformers suit Arcade so well. The course builds the floor by hand first so that a wall makes sense: it is the same if, done by the engine. Tilemaps live in a project's assets rather than in its code, so the lessons leave them for later.

Try it yourself (5 minutes)

1. In the Gravity lesson, run the falling ball and watch it speed up.
2. In Jump from the ground, press A again and again: the player flies. Then load the fixed version and try again.

Questions students ask

• "Why does my player fall through the floor?" There is no floor yet. Add the if in on game update.
• "Why can I fly?" Every press of A jumps, even in the air. Only jump when the bottom is on the floor.
• "Why is a jump negative?" y counts down the screen, so up is negative.

How it connects

Next unit adds levels to the runner. Will it work in Arcade? puts platformers near the top of the games Arcade suits, because of gravity and tilemaps. Skillmaps: Jungle Jump Platformer and Monster Truck Racer.

The idea in plain words

A level is a variable that changes by 1. The level-up is an if in the event where the score changes: if score ≥ goal, change level by 1 and move goal up, so the next level is further away. A splash shows the level, joined to the word Level with join (Text).

What changes per level goes in a list: speeds is 40, 70, 100, and speeds[level] (get value at) is the speed for this level. Places are counted from 0, so the level starts at 0 and the splash shows level + 1. A function startLevel clears the old enemies, splashes the level and sets up the new one. After the last level, the game ends with a win.

Why programmers use them

Levels keep players playing: each one a little faster or busier, with a new look, while the program stays the same and only a list changes.

An everyday picture, and where it breaks

Levels are a swimming programme: the same lesson each week, but the card for your level says how far and how fast.

Where it breaks: a swimmer moves up once. A game does not know it has already moved you up: an if in on game update keeps asking every frame, so if score ≥ 5 stays true and levels up again and again. Level up in the event where the score changes, and move the goal up.

Try it yourself (5 minutes)

1. In Level up, collect 5 coins and watch the splash and the second enemy.
2. In A list per level, change the first speed in the list and run: level 1 changes.

Questions students ask

• "Why does the level shoot up?" The level-up is in on game update, which runs every frame, or goal never moves. Move it to where the score changes.
• "Why does it say Level 0?" Lists count from 0; show level + 1 to players.
• "Why does the game break after the last level?" A list of 3 has places 0, 1 and 2. Win at level 3 before calling startLevel.

How it connects

Next unit, power-ups: true or false, and numbers that run out. Skillmap: Jungle Jump Platformer builds a level per map.

The idea in plain words

A variable can hold true or false (Logic). A power-up is three parts: a variable that remembers it (shield is true while it is on), an event that changes it (catching a star sets it to true), and a rule that uses it (if shield, a rock costs no life). It stays true until a block sets it back to false.

A power-up that runs out is a number counting down. For ammo, the A event asks if ammo > 0 first, then fires and changes ammo by -1, so the count never goes below zero. For time, a timer every second takes 1 off shieldTime while the shield is on, and at 0 sets the shield back to false.

Why programmers use them

Games remember what is happening now (powered up or not, shots left) in variables. Checking before using is how every limited thing works, from ammo to a bank balance.

An everyday picture, and where it breaks

A power-up is a "free entry" wristband at a fair: while you wear it, the ride rules change for you, and it comes off at closing time.

Where it breaks: the wristband only comes off if someone checks the time. In code, nothing sets the variable back unless a block does, and a check written in on start is asked once, before the game begins. The countdown must sit in a timer.

Try it yourself (5 minutes)

1. In True or false, catch a star: the shield never ends.
2. In Run out, press A five times with three shots: the count goes below zero. Then load the version that checks first.

Questions students ask

• "Why does my shield never switch off?" Nothing sets it back to false, or the countdown is in on start.
• "Why does A fire for ever?" The shot is outside if ammo > 0.
• "Why does A not fire?" ammo starts at 0. A star sets it.

How it connects

The final challenge, Power-ups, puts true or false, counting down and every sprite of a kind into one prize box. Skillmap: Save the Galaxy adds power-ups to a shooter.

The idea in plain words

The challenge grows the shield game from the Power-ups unit into a prize box: a star gives a shield (true or false, counted down), a blaster with limited ammo, a smart bomb (every sprite of a kind) or a power-up each student designs. It is built in three milestones with less help each time: most of the code, then an outline, then goals only. Nothing is new.

Will it work in Arcade? then asks which games the engine is built for, ending in a pitch card and a prototype. Power-ups and Will it work in Arcade? mark the course Challenge complete. The optional Your own game turns the pitch card into a finished game, with goals only.

Game rule or engine?

Every Arcade game splits into two kinds of work:

• The engine (what Arcade does for you, the same in every game): moves sprites by their velocity every frame, notices when two kinds overlap, shows the score, lives and countdown, ends the game at zero lives or time, keeps the high score, removes auto-destroy sprites.
• Game rules (what your blocks decide, different in every game): what a touch means, when a rock appears and how fast, whether the shield is on, how many shots are left, when the player wins.

Naming the split helps students debug (a rule they wrote is where the bug is) and helps them judge which games suit Arcade: a game whose hard part the engine already does is quick to build.

Why programmers use milestones

Real programs are combinations: state (variables), events, decisions, lists and named jobs 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

A power-up is a "free entry" wristband at a fair: while you wear it, the ride rules change for you, and it comes off at closing time.

Where it breaks: the wristband only comes off if someone checks the time. In code, a check written in on start is asked once, before the game begins, so the shield never switches off. The countdown must sit in a timer.

Try it yourself (5 minutes)

1. In Power-ups, catch two stars close together: the second resets the shield to 5 seconds.
2. Set prize to 1 while testing, so every star gives the blaster, and fire until the ammo runs out.

Questions students ask

• "Why does the bomb destroy only one rock?" The destroy is outside the for element loop.
• "Why does my shield never switch off?" The countdown is in on start, or the if for 0 is outside the timer.
• "Why does A not fire?" ammo starts at 0. A star with the blaster prize sets it.

Which games suit Arcade? (for teachers)

Will it work in Arcade? and Your own game ask students to judge their ideas against this table. The engine facts were written from knowledge of Arcade; spot-check them in the editor.

How it connects

This ends Arcade advanced skills. Next steps are Arcade's real tools: tilemaps (walls, floors and a camera that scrolls through a bigger world), animation and extensions, led by the teacher, or practised in Microsoft's skillmaps (arcade.makecode.com/skillmaps): Jungle Jump and Monster Truck Racer for platforms, Save the Galaxy for shooters, and the Game Maker Guide for students making their own. The same ideas (events, state, decisions, lists, functions) carry into games in text code later.

Make a shooting game with a twist of your own: waves of enemies arrive, the player fires at them, and a button or event does something to all of them at once (freeze them, slow them, clear the screen).

Milestones:

• Enemies keep arriving from random places, and the player can shoot them.
• Something happens to every enemy at once, with a for element loop over all of them.
• There is a way to lose, checked with if.

scene.setBackgroundColor(15)
info.setLife(3)
let ship = sprites.create(img`
    . . 9 . .
    . 9 9 9 .
    9 9 1 9 9
    `, SpriteKind.Player)
ship.setPosition(80, 110)
controller.moveSprite(ship, 100, 0)
controller.A.onEvent(ControllerButtonEvent.Pressed, function () {
    let shot = sprites.createProjectileFromSprite(img`
        5
        5
        `, ship, 0, -100)
})
controller.B.onEvent(ControllerButtonEvent.Pressed, function () {
    for (let alien of sprites.allOfKind(SpriteKind.Enemy)) {
        alien.vy = 0
    }
})
game.onUpdateInterval(1000, function () {
    let alien = sprites.create(img`
        . 7 . 7 .
        7 7 7 7 7
        7 f 7 f 7
        `, SpriteKind.Enemy)
    alien.setPosition(randint(10, 150), 0)
    alien.vy = 20
})
sprites.onOverlap(SpriteKind.Projectile, SpriteKind.Enemy, function (sprite, otherSprite) {
    sprite.destroy()
    otherSprite.destroy()
    info.changeScoreBy(1)
})
game.onUpdate(function () {
    for (let alien of sprites.allOfKind(SpriteKind.Enemy)) {
        if (alien.y > 120) {
            alien.destroy()
            info.changeLifeBy(-1)
        }
    }
})

Make a game with levels: each level is a little harder (faster, more enemies, a different map), the levels come from a list, and a function sets each one up. The kind of game is yours.

Milestones:

• My levels come from a list (speeds, counts or colours), read by level number.
• A function sets up a level, and I call it at the start and when a level is done.
• There are at least three levels, and each one is harder.
• Someone else played it and I changed one thing because of what they did.

Will it work in Arcade? is worth doing first: it steers students away from physics games Arcade cannot do well. Ask for a one-sentence pitch before coding.

let speeds = [30, 50, 70]
let level = 0
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)
function startLevel() {
    for (let old of sprites.allOfKind(SpriteKind.Enemy)) {
        old.destroy()
    }
    let rock = sprites.create(img`
        e e e
        e e e
        e e e
        `, SpriteKind.Enemy)
    rock.setPosition(randint(10, 150), 0)
    rock.vy = speeds[level]
    rock.setBounceOnWall(true)
    rock.vx = speeds[level]
}
sprites.onOverlap(SpriteKind.Player, SpriteKind.Enemy, function (sprite, otherSprite) {
    game.over(false)
})
game.onUpdateInterval(10000, function () {
    level = level + 1
    if (level < speeds.length) {
        game.splash("Level " + (level + 1))
        startLevel()
    } else {
        game.over(true)
    }
})
startLevel()