Cool Flash Games — Retro Arcade & Browser Game Guides
Retro arcade archive · Browser game guides · The Flash era & beyond
← Back to Game Guides Design

Preloaders and Loading Bars: The Forgotten Interface of Flash Games

Before a single sprite moved on screen, every Flash game asked players to sit through a loading bar first — a few seconds of blank waiting that developers turned into a surprisingly rich, and often surprisingly annoying, design space of its own.

Flash games shipped as a single compiled file, and on a dial-up or early broadband connection that file could take anywhere from a few seconds to over a minute to fully download before the game could begin. Rather than leaving players staring at a blank browser window during that gap, ActionScript exposed a straightforward mechanism — checking how many bytes of the file had downloaded against the file's total size — that developers could use to build a custom loading screen. What they built with that mechanism varied enormously, and the variation says a lot about the priorities of Flash-era web development.

The mechanics behind the bar

In ActionScript 2, a preloader typically checked the root movie clip's getBytesLoaded() against getBytesTotal() on every frame, converting the ratio into a percentage that drove a growing rectangle or a numeric readout. ActionScript 3 formalized the same idea through the LoaderInfo class and its bytesLoaded and bytesTotal properties, giving developers a slightly more reliable API for the same underlying task. Either way, the preloader itself had to be extremely lightweight, since it needed to be visible and functional before the rest of the file had actually finished downloading — a preloader that was itself too heavy defeated its own purpose.

This constraint shaped what preloaders could look like. Most were simple: a rectangle that filled left to right, a percentage counter, sometimes a looping animation cheap enough in file size to run before the main asset library had arrived. The best ones matched the visual identity of the game that followed closely enough that the wait felt like part of the experience rather than an interruption before it.

Branding, ads, and the "click to continue" gate

Because the preloader was the first thing every single player saw, it became valuable real estate almost immediately. Sponsored games frequently used the loading screen to display the sponsoring portal's logo prominently, sometimes for the entire duration of the load and sometimes held on screen briefly even after loading had technically finished, guaranteeing an impression regardless of whether the player ultimately liked the game. Ad networks built specifically for the Flash ecosystem, such as Mochimedia's MochiAds, offered developers a pre-packaged advertisement to display during the loading period in exchange for a share of ad revenue, turning otherwise dead waiting time into a monetizable slot inserted into virtually every participating game.

A related pattern was the "click to play" gate that appeared once loading had finished: a button players had to actively click before the game would start, rather than the game beginning automatically the instant it was ready. This served a real technical purpose in some cases, since Flash's sound could not always begin playing without a direct user interaction due to autoplay restrictions in later browser versions, but it was also frequently used simply to hold a final ad impression or sponsor logo on screen for a few extra seconds before releasing the player into the game itself.

When the preloader became part of the game's identity

Some developers treated the loading screen as a genuine extension of the game's presentation rather than a necessary interruption before it. A loading bar rendered as a filling gas tank for a racing game, a growing plant for a farming game, or a charging weapon for a shooter gave the wait thematic continuity instead of breaking it. These touches cost little in file size but signaled a level of craft that separated games built with real design attention from games assembled quickly to fill out a portal's back catalog. Players rarely praised a good preloader directly, but a jarring or overly aggressive one — particularly one that gated an unskippable ad behind a slow countdown — was noticed and complained about in portal comment sections often enough that developers had clear incentive to keep the friction low.

Why the format disappeared without much notice

HTML5 games generally load their assets through a less monolithic pipeline than a single compiled swf, and modern web development practice around loading states borrows more from general web performance guidance, including patterns documented in resources like the web.dev performance documentation maintained for the broader web platform, than from the specific preloader conventions Flash developers built. The custom-branded loading bar, tuned by hand to match a specific game's aesthetic and often carrying a sponsor's logo, was a distinctly Flash-era interface convention. It quietly disappeared from browser gaming without much of a send-off, even though nearly everyone who played Flash games in that period can still picture exactly what one looked like.