South Korea's indie game event "2P GAME ARCADE" is running the "1.44MB GAME_DEV CONTEST," which requires entire games to fit within 1,474,560 bytes. Submissions opened on May 23, 2026, with a deadline of September 4. This isn't a contest about making a compressed archive look small—the count includes the extracted executable and any required runtime files. Yet 1,474,560 bytes is the full sector capacity of a 3.5-inch HD floppy disk, which is 16,896 bytes larger than the space typically available for files under standard DOS formatting. Beneath its retro appearance, the competition raises a genuine design question: how much work should be delegated to the engine, the file system, and the host OS?
Packing an Executable and Runtime into 1,474,560 Bytes
What the contest rules count is not the compressed size of the submission archive. The entire extracted folder must fit within 1,474,560 bytes, and this includes not just the executable but any necessary runtime as well. Compressing data within the game itself is allowed, but the final playable package as a whole must not exceed the limit. Browser-based games are excluded—the contest calls for standalone executable works.
No engine is specified, and both individuals and teams may enter. However, eligible entries must be original works newly created after the contest's official announcement. The rules are organized into eight items, and judging focuses on three points: whether the work is complete, whether it stays within the size limit, and whether it's fun as a game. The design isn't meant to reward technical demonstrations of size reduction alone.
Prize money is set at 720,000 won for the grand prize, 280,000 won for the gold prize, and 144,000 won for the silver prize. Winners of all three prizes will also receive a commemorative diskette containing their work. The organizers cite as their inspiration the "100Kbyte Game Contest" held in 1997 by Hitel's game development club.
2P GAME ARCADE is an indie game event built around themes of cooperation and competition. Notably, this contest's judging criteria don't list technical novelty or compression ratio as independent factors—"is it fun" is explicitly stated instead. Minimizing file size is both the goal and, at the same time, a constraint meant to serve the creation of play itself.
The 16,896-Byte Gap Between "1.44MB" and Usable File Space
The official 1,474,560-byte limit is numerically accurate. According to IBM's AIX documentation, a 1.44MB disk's structure consists of two sides, 80 cylinders, 18 sectors per track, and 512 bytes per sector. Multiplying these together gives 2 × 80 × 18 × 512 = 1,474,560 bytes.
However, actually using such a disk under DOS requires reserving space for management structures like the directory. A capacity table in "Learning to Use DOS," held by the Computer History Museum, lists the total capacity of a 1.44MB disk as 1,474,560 bytes, but the space available for files as 1,457,664 bytes.
| Metric | Capacity |
|---|---|
| Total capacity across all sectors | 1,474,560 bytes |
| Space usable for files under DOS | 1,457,664 bytes |
| Difference | 16,896 bytes |
In other words, a submission package that hits the limit exactly would not fit onto a single disk if saved as files under standard DOS formatting. The contest accepts entries via Google Forms and does not require writing to a physical disk or booting from one. "One floppy disk" here isn't a rule meant to faithfully replicate the standard distribution medium—it's a repurposing of the raw total capacity of the medium as a software development budget.
This number resonates as a nostalgic symbol precisely because the 3.5-inch format actually carried software during its era. According to the Computer History Museum, the 3.5-inch specification, based on Sony's design, was agreed upon industry-wide in 1982 and had replaced the 5.25-inch format by the mid-1990s. Floppy disks were the primary storage medium during the PC's growth period and were widely used for software distribution as well. The 2026 contest carries forward not the physical inconvenience of that era, but only its limited storage capacity, transplanted into a modern development environment.
Free Engine Choice, But What Needs Trimming Extends Beyond the Game Itself
The requirement to include the runtime forces developers to confront the weight of their development foundation before they even get to compressing images or audio. Whatever unused rendering, physics, text layout, or input/output functionality an engine carries remains in the binary, eating into the space available for actual game content. Even with free choice of engine, developers don't start from the same baseline.
Godot 4.5's official documentation explains that stripping debug symbols can shrink a binary by a factor of five to ten. Link-time optimization, size-optimized compilation, and custom builds with unused features removed are also available; disabling 3D functionality alone can reduce the compiled binary by roughly 15%. Even after all this trimming, there's no guarantee the result fits within 1,474,560 bytes—what the documentation reveals is simply that a general-purpose engine's feature set itself consumes space.
Unity 6 similarly uses UnityLinker to strip unused types, and can remove entire unreferenced AI or physics modules. raylib, on the other hand, positions itself as a dependency-free C99 library, designed so developers can select only the functionality they need from a small set of self-contained modules. The former starts from a large foundation and trims away the unnecessary; the latter builds up from small, chosen pieces. Neither guarantees eligibility on its own, but under this particular size limit, the choice of development tool becomes part of the work's design itself.
The Trade-off Demonstrated by .kkrieger's 96KB
The method of packing rich visuals into a tiny executable was vividly demonstrated by the experimental 2004 FPS ".kkrieger." According to the NFO distributed by .theprodukkt, the executable was 96KB—precisely 98,304 bytes. Rather than storing finished texture and mesh data, it recorded compact procedural generation instructions and regenerated the assets at runtime. In exchange for achieving density beyond what standard data compression could offer, the approach sacrificed some creative freedom and imposed loading time.
The capacity didn't vanish—it simply moved elsewhere. The work's stated system requirements include a CPU of 1.5GHz or faster, 512MB or more of memory, and DirectX 9.0b. The smaller you make the distributed file, the more you shift the burden onto post-launch computation and onto APIs already present on the machine. The code that Farbrausch later released publicly included a texture generator, a software synthesizer, and an executable compressor—revealing that the reduction was an integrated effort spanning everything from asset formats to production tools.
.kkrieger is neither an entry in this contest nor a precedent establishing rule compliance. Still, the idea of shifting storage capacity into computation time through procedural generation connects directly to the question this 1.44MB limit poses: how do you construct visuals and sound within such a space? How many fixed images do you keep? Do you store audio waveforms or synthesize them? Do you save stage data or build it from rules? The size constraint reaches all the way back to decisions about concept and expression.
A 20-Minute Gap in the Deadline, and an Undefined Execution Environment
Applicants should first note an inconsistency in the deadline times listed on the official page. The rules section states the deadline as 11:59 PM on September 4, while the schedule section lists 11:39 PM. The date is the same, but the times differ by 20 minutes—following the current wording, entries should be submitted before 11:39 PM to be safe.
On the technical side, the target OS and CPU architecture aren't specified in the published rules. While there's a requirement to bundle necessary runtimes, it's unclear how much of the OS's standard DLLs, graphics APIs, or drivers can be assumed to already exist on the host system. A work that leans heavily on host-provided functionality and a work that bundles libraries extensively will have different levels of self-containment, even at the same 1,474,560 bytes.
Judging criteria are narrowed to three points: completeness, size compliance, and fun. What's worth watching for when results are announced is how the organizers handle differences in execution environments, and in what format winning entries will be recorded onto the commemorative diskettes. Once that method is revealed, the technical scope implied by the phrase "one floppy disk" will finally be settled.