Why Game Engines Overwhelm Beginners, and MakeCode Arcade Doesn’t

Most popular game engines are built to ship games, not to teach how games work. Their design priorities reflect that. They aim for flexibility, scale, and expressive power, so experienced developers can build almost anything. In a production context, that flexibility is essential. In a learning context, it often gets in the way.

Unfortunately, for beginners, especially those with little or no programming experience, modern engines ask for too many decisions too early. Before a learner has a clear sense of how a game behaves, they are already dealing with project setup, engine structure, update functions and asset management. Effective learning tools tend to narrow the focus and shorten the feedback loop. They make it easy to change something and see the result immediately. This sense of iteration is especially important for young learners.

This is the gap that MakeCode Arcade was designed to address. Instead of starting with programming mechanics or engine structure, it starts with the building blocks of games themselves, and builds outward from there. This article takes a deep look at MakeCode Arcade; its origin, worldwide adoption and how it can be used to make game.

What Is MakeCode Arcade?

MakeCode Arcade is a game development tool designed as a learning environment first. Its screen resolution, color palette, and input model are fixed, which narrows the focus of the learner. Within a couple of hours, users will form a concrete understanding of how games operate.

The platform emerged from Microsoft’s broader work on MakeCode, an educational platform originally created to support the BBC micro:bit. That project focused on making programming approachable. Arcade extends the same philosophy into game development, shifting the focus from programming mechanics to how games behave as systems.

From Circuit to Classroom: How the micro:bit Makes Coding RealCan a circuit board make coding feel real? The Micro:bit brings code into students’ hands, turning abstract logic into motion, light, and sound at low cost.TechnodabblerAlex Denault

The micro:bit, as first covered on Technodabbler

MakeCode Arcade first appeared publicly in 2019 and reached general availability in early 2020. From the beginning, it was built as a browser-based tool that required no installation and no user account. This made Arcade easy to deploy in classrooms, workshops, and clubs, even on modest or shared hardware, and removed many of the logistical barriers that usually slow down educational software adoption.

Early on, Microsoft worked closely with educators and hardware partners, rather than positioning Arcade as a consumer-facing game engine. Devices like the KittenBot Meowbit and Adafruit PyBadge appeared quickly, giving students a way to run their games on dedicated handhelds instead of only in a browser. This helped establish Arcade as something tangible, rather than a purely on-screen exercise.

The Kittenbot Meowbit, one of the early handheld device that could run MakeCode Arcade games.

Adoption followed a strongly educational path. Arcade has been used in middle and high school classrooms, after-school coding clubs, summer camps, and national education programs. Code Ninjas integrated MakeCode Arcade into its curriculum as an introduction to game development before students transition to engines like Unity or Godot. Microsoft Stores ran in-person Arcade game design camps where students built games over multiple sessions and then shared and played them together.

    ArcadeCon 2025 – MakeCode Arcade
  

    Talks, workshops, and recordings from the MakeCode Arcade community event.
  

    arcade.makecode.com
  

ArcadeCon 2025 was a virtual event geared at educators, providing everything needed to create a MakeCode Arcade curriculum. The link include videos to all the sessions.

International uptake followed a similar pattern. In Europe, Arcade spread through micro:bit-based education programs, especially after the release of the micro:bit V2 made it capable of running Arcade games with snap-on console shields. In parts of Asia, hardware partners such as KittenBot, Elecfreaks, and Seeed Studio localized devices and teaching materials, helping Arcade appear in classrooms in China, Taiwan, Hong Kong, and beyond. Translated documentation and browser-based access further reduced friction across regions with very different technical constraints.

Arcade was built as an open ecosystem rather than a closed product. Hardware makers are encouraged to build compatible devices, educators are free to develop their own curricula, and students can share games through simple links without distribution platforms or accounts.

What Are the Components of a Game?

To understand why MakeCode Arcade works as a beginner game engine, it helps to look at a simple complete game. The example here is intentionally small: Avoid the Snake. The player moves a character around the screen, avoiding a snake that moves continuously. The goal is to survive until a countdown timer reaches zero.

Play Avoid the Snake directly from the browser. Click on the simulator, press Spacebar to start and use the directional keys to avoid the snake.

Starting With the Player

Every game begins with a player. In a 2D game, the player is represented as a sprite, a visible object that exists in the game world and responds to input

The setup of a sprite will include its looks and position. In the case of the player, its movement is bound to the directional pad.

In MakeCode Arcade, creating the player sprite is as simple as adding a block. A second block positions the player on the screen, a third keeps the character on the screen and the fourth allows the player to control the player with the directional pad. That four block is particularly impressive, as player movement based on velocity can get complicated fast. In total, that is four block to create the player and handle its movement in the game.

Adding an Opponent

Introducing the snake follows the same pattern. A new sprite is created, placed on the screen, and given motion. A second block sets its position, a third for velocity and two additional blocks to keep the snake bouncing around the screen.

The Snake sprite will need to bounce around the screen. This is achieved by giving the snake a velocity and instructions to both stay on the screen and bounce on the wall.

The snake moves continuously, creating pressure on the player without specialized logic. It changes direction automatically then it hits the wall, creating a perception of chasing the player. The difficulty of the game can be increase by giving the Snake more velocity. That said, the game might have challenge, but no consequences.

Event: Making Interaction Meaningful

By definition, a game must have a win and a lose condition. MakeCode Arcade makes these concept accessibly by providing components such as life points and countdown timers. In our case, reaching zero on the countdown triggers a win, and reaching zero life triggers a lose. When events are represented as event blocks, which store either a "win" and a "lose" block, both showing the corresponding splash screen when they occur.

These convenient events, along with pre-designed splash screen, make programming the end-game trivial.

Still missing is the interaction when the snake collides with the players. MakeCode Arcade handles this with an event block that triggers on both sprite collides. The inner blocks within that event are instantly executed. In this case, a collision triggers the lose of a life, resets the position of the snake, shake the screen and plays a particular sound effect if they survive.

When the Player sprite collides with another sprite, things happens. This event is customized to trigger only on certain "kinds" of sprites (enemy, food, etc.).

By providing event blocks, MakeCode Arcade avoid the complexities of traditional event loops. Although such a loop can be coded in Arcade, its absence simplifies the build process.

A Complete Game, Quickly

Its important to note that this walkthrough is not a tutorial. There are numerous of those on Youtube. Instead, the goal is to discuss the accessibility provided by the abstraction. In well under an hour, someone with no prior game development experience can assemble a complete game like Avoid the Snake, iterate on its behavior, and run it as a playable game, either in the browser or on supported hardware.

The full code for Avoid the Snake. With the MakeCode Arcade editor, this diagram can be seamlessly be transformed to Javascript or Python.

Once the learner is familiar with all the visual construct, the can switch to either Javascript or Python to continue the evolution of their game. Event blocks are transformed into callback, and control block are transformed into if/for/while statements. The iteration continues, with new levels and challenges. A developer comfortable with the different constructs in MakeCode Arcade can then look to switch to a more mature game engine.

Scratch or Arcade?

One look at MakeCode Arcade draw instant compare with Scratch, the MIT developed visual programming language. It supports animation, storytelling, interactive art, and games within the same environment. That flexibility encourages exploration across many types of projects.

In Scratch, actions and controls are defined on a per sprite basis. In this case, for the player sprite, we define the movement logic.

One notable structural difference is how logic is organized. In Scratch, scripts are attached to individual sprites. Movement controls live inside the player sprite. Enemy behavior lives inside the snake sprite. Collision handling must also be written inside one of those sprites as a conditional check. Scratch does not provide a dedicated collision event that fires automatically when two sprites overlap. Instead, collision is typically implemented by repeatedly checking whether one sprite is touching another after movement occurs. This shifts the responsibility to the learner to manage timing and order of execution. In simple projects this works, but as behavior grows more complex, movement often needs to be broken into smaller steps to ensure collisions are detected reliably. The result is workable, but the structure becomes harder to reason about.

We store the control logic in the Snake sprite. This include "collision detection", and win/lose conditions.

Other conveniences are also handled differently. Scratch does not provide built-in velocity management for sprites in the same way. Movement is usually expressed as repeated position changes inside loops, which means speed and direction are managed manually. Concepts such as life counters, countdown timers, and win or loss screens are not first-class primitives either. They must be constructed from variables, conditional checks, and broadcast messages. This offers flexibility, but it also increases the amount of structural work required before the game feels complete. In MakeCode Arcade, these concerns are surfaced directly as part of the engine’s model. The learner works with the structure of the game rather than constructing that structure from lower-level pieces.

From Browser to Hardware: Kitronik Arcade

MakeCode Arcade is unusual among game engines because hardware is a primary consideration in the specification. Arcade defines a reference device model: a 160x120 color screen, a directional pad, two primary buttons labeled A and B, and a couple of utility buttons. The hardware specification is publicly documented, allowing manufacturers to build compatible devices that run the same games without modification.

The MakeCode Arcade standard defines a screen size of 160x120 pixels.

One of the more accessible implementations is the Kitronik Arcade for micro:bit. Rather than embedding its own processor, the Kitronik Arcade uses the BBC micro:bit v2 as its computing core. The micro:bit plugs directly into the unit and acts as the CPU, while the Arcade board provides the LCD screen, directional pad, A and B buttons, speaker, and power supplied by three AA batteries.

The Kitronik Arcade is powered by 3AA batteries, providing power to both the LCD screen and the micro:bit

This modular design keeps costs manageable and aligns with classroom realities. Schools that already use micro:bit boards can extend them into handheld game consoles without purchasing an entirely new platform. It also reinforces the idea that the same code running in the browser is now running on a physical microcontroller.

The edge connectors allow the game to reach out into the physical world, with LED and servos.

Beyond its built-in controls, the Kitronik Arcade exposes the micro:bit edge connector. This allows external devices and sensors to be attached, extending the game model beyond the screen. Buttons, LEDs, servos, or other components can interact with the game logic. For learners already familiar with micro:bit projects, this creates a bridge between embedded computing and interactive game design.

Teaching Structure Before Syntax

Popular game engines optimize for power and flexibility. Those qualities are essential in production environments, but they introduce friction when learning. Beginners benefit from tools that narrow the problem space and make feedback immediate.

MakeCode Arcade succeeds because it preserves the core structure of a 2D game while removing distractions that do not contribute to that understanding. These concepts are present from the first project and remain consistent as learners transition from blocks to JavaScript or Python. In that sense, Arcade help prepare learners for professional engine. In that sense, the value of a beginner game engine is not measured by how closely it mimics professional software, but by how clearly it onboard beginners to game development.

If you want to learn more about how these concepts were implemented on real hardware, the Game Boy Advance is a natural next step. It provided dedicated support for sprites and tilemaps, much like the model MakeCode Arcade presents in software. The tooling is more demanding, but the mental structure remains the same.

                        Learn more