Get AI summaries of any video or article — Sign up free
Santa Run Game in MIT App Inventor (Full Tutorial) | MIT App Inventor game | App Inventor Santa game thumbnail

Santa Run Game in MIT App Inventor (Full Tutorial) | MIT App Inventor game | App Inventor Santa game

Obsidian Soft·
5 min read

Based on Obsidian Soft's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Trim sprite PNGs to remove transparent padding so collision detection matches what players see.

Briefing

A Santa Run game built in MIT App Inventor turns a simple side-scrolling mechanic into a playable avoidance challenge: Santa must jump over incoming candies, and any collision ends the run. The core design hinges on three timed systems—one for Santa’s running animation, one for candy movement, and one for score updates—plus a jump routine triggered by screen touches.

The tutorial starts with assets and a practical fix for collision accuracy. Santa sprites are downloaded from OpenGameArt, then trimmed to remove extra transparent pixels using an online “trim” tool. That cropping matters because App Inventor collision detection can behave as if the sprite’s invisible padding is still part of the hitbox. The background is kept intentionally simple (white snow and a blue sky) to sell the illusion of motion without needing to scroll the scene.

In the MIT App Inventor setup, a portrait screen is created with a canvas for drawing, a Start button, and three Clock sensors: a run timer (50 ms) to cycle Santa through 11 running costumes, a jump timer (800 ms) to control the up-and-down arc, and a score timer (200 ms) to increment and redraw the score. Two image sprites are placed on the canvas: Center Sprite (Santa) and Candy Sprite. Santa’s sprite is sized larger (114×80) and uses the idle image plus run1 through run11 PNGs; the candy sprite is smaller (30×30) and uses a single candy image. Candy is positioned to the right side of the canvas, while Santa starts on the left.

Gameplay begins when the Start button is pressed. Santa’s running animation is enabled by turning on the run timer, and candy movement starts by setting a positive speed so it travels left. When candy reaches the left edge (detected via EdgeReached), it snaps back to its starting position so the stream continues indefinitely until a collision occurs.

Jumping is handled by a touch event on the canvas. Touching the screen triggers a custom jump procedure: Santa’s speed and heading are adjusted to move upward, a “jump up” flag is set to true, and the jump timer is enabled. When the jump timer fires, the logic checks that flag: if Santa is still going up, the heading flips downward (270 degrees) and the flag is cleared; otherwise, the jump ends by resetting speed to zero, disabling the jump timer, and returning Santa to his original Y position.

The game ends in the SantaSprite “collided with” event when Santa hits the candy sprite. At that moment, candy speed is set to zero and the run timer is disabled so the character stops moving. The score system resets on Start, increments every 200 ms, and redraws the score text centered on the canvas. On collision, the tutorial also redraws a “Game Over” message below the final score, using the same canvas drawing functions so the result updates immediately.

Cornell Notes

The Santa Run game in MIT App Inventor is built around timed animation and simple physics: Santa runs in place using 11 costume frames, candy moves left continuously, and screen touches trigger a timed jump. Collision detection is made reliable by trimming sprite images to remove transparent padding that would otherwise create false “misses.” The Start button enables the run timer and candy motion, while the jump timer controls the up/down arc using a jump flag. Score is updated every 200 ms by incrementing a global score variable and redrawing text on the canvas. A collision between Santa and candy stops movement and displays “Game Over.”

Why does trimming transparent pixels from sprites matter for collision detection in this game?

App Inventor collision checks can effectively include transparent padding around images. If Santa’s or candy’s PNGs keep extra transparent pixels, the collision may register too late—making it look like Santa’s center never actually touches the candy before the game ends. The tutorial trims each running costume and the idle image so only the visible sprite area remains, improving the accuracy of the “collided with” event.

How does the run animation work without moving Santa across the screen?

Santa stays in a fixed X position while a run timer cycles through costume frames. A global “costume count” starts at 1, and every 50 ms the run timer increments it. When the count exceeds 11, it resets to 1. Each tick updates Santa’s picture to a filename built from the count (e.g., run1.png, run2.png … run11.png).

What triggers Santa’s jump, and how is the jump duration controlled?

A canvas touch event triggers a custom “jump” procedure. That procedure sets Santa’s speed and heading to move upward and sets a boolean flag (jump up) to true, then enables the jump timer. The jump timer fires after 800 ms; when it fires, logic checks the jump up flag to decide whether to switch to the downward heading or to end the jump by resetting speed and disabling the timer.

How does the candy keep moving continuously even though it reaches the edge?

Candy movement starts when Start is pressed by setting Candy Sprite speed to a positive value (18). An EdgeReached event detects when the candy touches the left side (edge equals Min −3 to −3). When that happens, the candy’s X position is reset back to its starting location so the stream continues.

How is the score displayed and updated during gameplay?

The score timer runs every 200 ms. Each tick increments a global score variable by 1, then calls a “write score” procedure that clears the canvas and redraws text: “Score: <value>”. The text is positioned using canvas width/height math so it stays centered. On collision, the run timer is disabled and the canvas is redrawn with a “Game Over” message below the final score.

What exactly ends the game when Santa hits a candy?

In the SantaSprite “collided with” event, the logic checks whether the other component is Candy Sprite. If so, it sets Candy Sprite speed to 0 and disables the run timer (so Santa stops running). The score is redrawn and a “Game Over” message appears on the canvas.

Review Questions

  1. How do the run timer and the costume count variable combine to select the correct Santa running frame?
  2. What role does the jump up boolean flag play when the jump timer fires?
  3. Which specific events stop gameplay, and what properties are changed in those events?

Key Points

  1. 1

    Trim sprite PNGs to remove transparent padding so collision detection matches what players see.

  2. 2

    Use three Clock sensors: 50 ms for Santa’s running frames, 800 ms for jump timing, and 200 ms for score updates.

  3. 3

    Cycle Santa’s run animation by updating the sprite picture to run1.png through run11.png based on a global costume count.

  4. 4

    Move candy left using speed and reset its position when EdgeReached detects contact with the left boundary.

  5. 5

    Trigger jumping from a canvas touch event and control the up/down motion using a jump timer plus a jump-up flag.

  6. 6

    End the game on SantaSprite collision with Candy Sprite by stopping candy movement and disabling the run timer.

  7. 7

    Redraw score and “Game Over” text by clearing the canvas and using Canvas.DrawText with centered coordinates.

Highlights

Collision accuracy improves dramatically after trimming transparent pixels from all Santa running frames—otherwise the hitbox can behave as if the sprite is larger than it looks.
Santa’s “running” is animation-only: he stays in place while a 50 ms timer swaps 11 costume images.
Jumping uses a two-phase timer: the first jump-timer tick flips direction and clears the jump flag; the second phase ends the jump by resetting speed and disabling the timer.
Candy never stops moving because EdgeReached resets its X position whenever it hits the left boundary.

Topics