Worm And Apple Game

How to Build Worm And Apple Game

Most people who ask about this are trying to make their own version rather than find an existing one. The classic snake-style game has been ported everywhere, but building it yourself is usually what people actually want. Here is how it works in practice.

The core loop is simple enough that you can sketch it out in an afternoon. You need a grid, a worm made of segments, an apple, and four inputs. Direction changes happen on arrow keys or swipe gestures. Every frame, the head moves one cell in the current direction, then the rest of the body follows by copying each segment's previous position. When the head lands on an apple tile, you add a new segment at the tail and spawn a new apple somewhere on the grid that is not currently occupied by the worm. For the grid itself, 20 by 20 is a comfortable starting size. Anything smaller feels cramped and anything larger makes the game drag unless you speed up the tick rate. The tick rate is where most people get stuck deciding what to use. A fixed interval between 100 and 150 milliseconds works for beginners. As the worm grows you can decrease that interval slightly to increase difficulty, but keep it above 60 milliseconds or the game becomes unplayable for anyone without reflexes tuned to something inhuman. Rendering is the next fork in the road. You can use a canvas element and draw filled rectangles for each segment. Or you can use DOM nodes and CSS grid. The canvas approach is faster and cleaner for anything beyond a prototype. DOM nodes are easier to style and debug but start choking around 30 by 30 grids with more than twenty segments because you are managing a lot of individual elements. I switched to canvas after my first version lagged noticeably on a mid-range laptop.

Input handling deserves more attention than it gets. On desktop you listen for keydown events and map arrow keys and WASD. On mobile you need touch gesture detection. A simple swipe recognizer comparing the touch start and end coordinates works for basic left-right-up-down input. But if you add swipe detection you also have to prevent the page from scrolling while the game is active. Setting touch-action to none on the game container and calling preventDefault on touch events stops the browser from fighting you. I ran into this on an older Android device where every swipe also triggered a page scroll, making the game nearly unusable without that fix.

What Most Guides Leave Out

The original Nokia version had a specific trick that modern clones often miss. The worm could pass through walls by wrapping to the opposite side. This is not just nostalgia, it is a meaningful difficulty dial. Wall collisions limit replay value on larger grids because players memorize safe zones. Wrapping keeps the gameplay fluid and forces the player to focus on self-collision, which is the actual hard part of the game.

Self-collision detection is where the math gets slightly interesting. You do not need a full pathfinding algorithm. For each move, check whether the new head position equals any existing body segment position excluding the tail, because the tail will move away that same frame. Comparing coordinates directly is faster than any spatial partitioning for the grid sizes this game uses. A simple loop over the segments array is plenty.

Download and Existing Versions

If you want to play rather than build, there are countless implementations online. Search for Worm And Apple Game and you will find browser-based versions on sites like Poki, CrazyGames, and various GitHub repositories with open-source source code. Many are simple enough that you can fork them and modify the grid size or speed without touching anything complicated.

If you want the source to study, the JavaScript canvas implementations on GitHub are usually the most straightforward. Python pygame versions exist too and are good if you want to learn the logic without browser quirks. The tradeoff is that pygame requires a local environment setup while browser games run instantly.

When This Approach Fails

The grid-based movement model breaks down if you want smooth diagonal movement or curved paths. The entire game is built on discrete tile transitions. Once you introduce sub-tile movement, you need proper collision detection between circles and rectangles, and the simplicity that makes this game easy to build goes away. If that is what you want, you are better off looking at a different game template entirely rather than trying to retrofit this one.

The grid also limits how large you can scale the board before performance becomes a real concern. On mobile browsers, rendering more than a thousand individual rectangles per frame at 60fps can cause noticeable stutter on older devices. I tested this on a three-year-old tablet and the frame rate dropped significantly past a 40 by 40 grid with sixty segments on screen. Staying under 25 by 25 keeps everything smooth across most hardware.