Adding a Day and Night Cycle to an Online Scratch Game

A day and night cycle is the first ambient effect most new makers want, and the first one that quietly teaches real timing logic. For an online Scratch game that runs in a browser tab, the effect has to be light, loop forever, and survive a player who leaves the page open for an hour. I built one for a small farming toy last winter, got it wrong twice, and came out understanding timers far better than any tutorial had managed to explain. This is the honest version of how it went, including the parts that broke.

One clock variable to rule the sky

The whole cycle hangs on a single number. I made a variable called time-of-day and let it run from zero to twenty-four, then back to zero. A forever loop nudges it up by a small step every few ticks, and every visual in the scene reads from that one number. Resisting the urge to scatter timing logic across five sprites was the real lesson. When one variable owns the clock, you can speed up the day for testing by changing a single step value, and nothing else in the project has to know or care how fast the sun is moving.

Tinting the backdrop without redrawing it

My first instinct was to draw four separate backdrops for dawn, noon, dusk and night, which looked fine and scaled terribly. The better route in Scratch is a full-screen sprite set to a dark colour, its ghost effect tied to the clock so it fades in as night approaches and out as morning comes. One sprite, one effect, smooth transitions, and no backdrop swap that jerks the scene. The ghost effect runs from zero to one hundred, so mapping the clock onto that range is a short bit of arithmetic that gives you a sky that breathes instead of snapping.

Why the loop must be frame-independent

Here is where I got burned. I tied the clock step to a fixed number of loop iterations, and on a fast machine the day raced by while on a slow laptop it crawled. Browser Scratch does not promise a steady frame rate, so counting loops is counting sand. The fix was to drive the clock off the built-in timer, which measures real seconds, and derive the time-of-day from that. Suddenly the cycle ran at the same pace on every device, which matters enormously for an online game where you have no idea what hardware a visitor brings.

Letting gameplay react to the hour

A cycle that only changes the sky is wallpaper. The project got interesting once sprites started reading the clock too. Shop signs lit up after dusk, a few critters only appeared at night, and a sleepy cat animation triggered past a certain hour. Each of these is a simple if-check against the one clock variable, and because every sprite reads the same source of truth, they all agree on what time it is. That agreement is the quiet payoff of the single-variable design I nearly abandoned.

Saving the hour across a session

Players close tabs. For an online toy that respects a visitor, I wanted the time to persist within a session rather than resetting to high noon on every reload. Scratch cloud variables can carry a number between visits, with the known caveat that they update slowly and only hold limited data. I stored a rounded hour, not the precise clock, so a returning player lands roughly where they left. It is not perfect persistence, and pretending otherwise would be dishonest, but it is enough to make the world feel continuous.

Testing the ugly edge cases

The bugs that matter live at the seams. What happens at exactly midnight when the clock wraps from twenty-four back to zero? Does the tint flicker? Does a night-only sprite flash on and off right at the boundary? I added a tiny buffer around the wrap so transitions never land on the exact edge, and I sped the clock up a hundredfold during testing so a full day passed in seconds and I could watch every seam dozens of times in a minute. Testing slow things fast is a trick worth keeping.

What the cycle really taught

By the end, the day and night effect was the least interesting thing I had built. The lasting gain was understanding that time in a game is just a number you agree on, that real seconds beat loop counts, and that one honest source of truth beats five clever ones. Those ideas carry into timers, cooldowns, animations and spawning long after the pretty sky stops impressing anyone. A first ambient effect is really a first lesson in keeping a system coherent, and that lesson is the thing worth finishing the project for.

Frequently asked questions

Do I need cloud variables for the cycle to work? No. The cycle runs entirely on a local timer and a clock variable, so it works offline in the editor and online in a shared project alike. Cloud variables only come in if you want the hour to persist between visits, and even then they are a nice-to-have rather than a requirement.

Why not just swap backdrops for each time of day? You can, and for a tiny project it is fine, but swapping backdrops snaps the scene between states and multiplies the art you have to draw. A single tinting sprite driven by the ghost effect gives smooth transitions from one sprite, which scales far better as the game grows and keeps the editor tidy.

How fast should a full day run in a casual game? It depends on the mood, but ten to twenty real minutes for a full cycle feels pleasant in most casual online games. Faster than that turns the sky into a strobe, and much slower means many players never see night at all. Make the cycle length a variable so you can tune it without touching anything else.

Finish the small thing

A day and night cycle is a modest effect that hides a solid lesson about timing. Build it on one clock variable, drive that clock off real seconds, let the rest of the game read from it, and test the wrap at speed. The sky is the reward players see, but the coherent timer underneath is the reward you keep.