Game Development 7 min read

Understanding Data Constraints and Tile-Based Graphics in NES/Famicom (FC) Game Development

The article explores how early 1980s game programmers managed extremely limited memory for graphics, audio, and code by using techniques such as tile-based rendering, simple audio synthesis, and data size estimation, highlighting the stark contrast with modern development resources.

Architect's Guide
Architect's Guide
Architect's Guide
Understanding Data Constraints and Tile-Based Graphics in NES/Famicom (FC) Game Development

我们对“数据量”无法直观认识

Unless you are an expert, most people cannot intuitively estimate what constitutes a large or small amount of data; for example, an 800‑character essay is about 1.6 KB in GBK encoding or 2.4 KB in UTF‑8.

A single‑character Word document, however, occupies 10,956 bytes, plus an additional 1,332 bytes due to disk formatting requirements.

In reality, popular products and technologies are closely tied to their historical context; for instance, a 15‑inch laptop feels small today, yet families in the early 1990s gathered around 14‑18‑inch CRT televisions.

When material abundance grows, inevitable “waste” changes perception thresholds, making size estimation chaotic.

FC 时代的图形技术

Early ROM chips were expensive and large‑capacity disks were immature, so increasing game size was difficult; developers therefore used data structures suitable for the era.

The Nintendo Famicom (FC) had a resolution of 256×240, only 2 KB of video RAM, yet still needed full‑screen scrolling; promotional text is omitted.

Consequently, the hardware provided a method to maximize video RAM usage: tiles.

By assembling scenes from a limited set of tiles, storage requirements were dramatically reduced.

Further explanations can be found in popular science videos, e.g., the linked Bilibili video.

音频容量和代码容量

Modern audio formats store raw waveforms, offering high fidelity but consuming large space—typically kilobytes to megabytes per track.

In the 8‑bit era, audio was generated by dedicated chips, such as the Ricoh 2A03 used in the FC.

The audio chip could synthesize limited timbres; many FC game soundtracks sound similar because of this restriction.

These chips could play multiple audio tracks (though not true chords), enabling complex music like that in Contra, Salamander, and Ninja Gaiden through alternating tracks.

Each note only needs to record timbre, frequency, and pitch, forming a simple “score” akin to a numeric sheet.

This simplified notation requires minimal data, and most game music loops, further reducing size.

代码也是类似的

FC games lacked a separate “engine layer”; the console itself provided hardware support for tiles, palettes, music, and sound effects, saving substantial low‑level code.

Programmers had to study documentation, think within hardware constraints, and be proficient in assembly to avoid wasting code space.

Thus, code could be written extremely compactly.

Overall, a 128 KB game was commonplace 30 years ago but would be considered “black‑tech” today.

Technological revolutions cause non‑linear changes in metrics, rendering our memories and intuitions obsolete.

Game developmentData Optimizationaudio chipretro gamingtile graphicsMemory Constraints
Architect's Guide
Written by

Architect's Guide

Dedicated to sharing programmer-architect skills—Java backend, system, microservice, and distributed architectures—to help you become a senior architect.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.