The world outside your screen didn't exist.

If you grew up in the 80s, you lived in fear of two things: nuclear war between the United States and the Soviet Union, and that one bird in Ninja Gaiden that knocks you into the pit every single time.

Here’s the thing about that bird: it wasn’t waiting for you. It didn’t exist until you could see it.

On early consoles, the world you saw on screen was essentially all that existed in memory. There was no background simulation, no persistent world state being tracked off-camera. The NES had 2 KB of RAM. That’s not a typo. Two kilobytes, total, for everything: your position, enemy state, score, timers, the level layout, all of it. Keeping track of anything you weren’t actively looking at was a luxury the hardware couldn’t afford.

Side-scrolling games didn’t actually scroll through a continuous world. They scrolled a viewport across a small active zone, typically one or two screens wide, and continuously cycled tile and enemy data through it as you moved. New tiles were pulled from ROM into that active window as they scrolled into view. Anything that scrolled too far off the left edge got overwritten. It wasn’t streaming in the modern sense. There was no buffer and no lookahead. The world was built one column of tiles at a time, right at the edge of the screen, just fast enough to stay ahead of where you were looking.

Enemy spawns worked the same way. They weren’t persistent objects with positions and state — they were triggers bound to scroll position. The game didn’t track “there is a bird at coordinate X.” It tracked “when the viewport reaches position X, create a bird.” Which means if you scrolled back left and came forward again, the trigger fired again. The bird respawned because you crossed the trigger for it again.

This is the actual explanation for a lot of what got labeled “Nintendo Hard.” Enemies that respawn the moment you back up aren’t a design choice about difficulty. They’re a consequence of spawn logic that has no concept of “already defeated.” The game can’t mark that bird as dead and preserve that information off-screen, because off-screen state doesn’t exist. Retreating and re-engaging was punished not because the designers wanted you to suffer, but because the system had no way to remember that you’d already been there.

The NES’s Picture Processing Unit compounded this. The PPU could handle 64 sprites on screen, but only 8 per horizontal scanline before hardware flickering kicked in. Developers had to be careful not just about how many enemies existed in memory, but how many were visible simultaneously and where they were on screen. An enemy sitting just off the left edge of the viewport wasn’t just logically culled, it was often literally deallocated, its sprite slot reclaimed for something else.

Later consoles broke this constraint incrementally. The SNES had 128 KB of RAM, 64 times more than the NES, and could hold state for entire screens worth of enemies, which is why Super Metroid’s rooms feel persistent and why enemies you’ve killed stay dead while you’re still nearby. By the time Doom hit the PC in 1993, computers had enough RAM to store the entire level and the state of all objects and monsters in memory simultaneously. Nothing blinked in or out of existence based on where the camera was pointing. The concept of an “active zone” was gone.

That transition is easy to take for granted now. Modern open-world games can simulate entire ecosystems running continuously in the background, enemies patrolling routes you’ll never see, and weather systems ticking forward while you’re on the other side of the map. But that continuity has a long history of being faked, incrementally, as each generation of hardware bought developers a little more room to remember what was happening just out of frame.