#13 AI 방송을 멈춘 이유

2026-10-16 · project

From August 11 to October 15, my AI played Pokemon Red live every night with nobody at the controls. On October 15 I switched it off. This post covers what ran, why it stopped, and, for anyone who wants to help, where effort would actually move the research.

What ran, and when it stopped

Most nights the broadcast started just after midnight UTC (8 PM in New York) and ran for about eight hours: the best current policy playing in an emulator, sent to Twitch, CHZZK, SOOP and YouTube with a music bed, a progress overlay and the chat RPG running beside it. The nightly digests I kept cover 59 of those nights and about 455 hours of airtime.

The last broadcast ended at 08:00 UTC on October 15. That afternoon I turned the schedule off, and nothing has gone out since.

Why: the rules

Nintendo's Game Content Guidelines are generous about gameplay videos that carry your own commentary. They draw the line here: "you may not simply upload or livestream an existing Nintendo video, gameplay footage without your own creative or editorial input". The same guidelines exclude content that "features unauthorized game consoles and/or software not licensed by Nintendo". An emulator running the game overnight, with nobody playing and nobody talking, breaks both.

It doesn't stop at Nintendo. CHZZK's own content rules treat breaking a game company's policy as a violation of CHZZK's rules, and CHZZK is one of the platforms my own streams run on. AI-plays-Pokemon broadcasts have mostly been left alone, but nobody having been punished yet is not a reason to keep doing something the rules say no to.

Why: almost nobody was watching

The rules decided it, but the numbers made it an easy call. These are the last twelve nights before the pause, with my own messages left out:

Across the whole run, 73 different accounts typed something during a broadcast: 336 messages, and 255 of them were game commands rather than conversation.

On October 13 I tried one last thing. Chat could summon a control window on demand, plain words like 위 ("up") counted as votes, and the overlay spelled out what to type. Nobody voted in the two broadcasts it was live for.

The interesting part of this project was never watching the agent wander around at night. It was what the measurements taught me, and those are all on this blog.

What stops, and what doesn't

• The overnight broadcast is off.
• Training and scoring are paused. Everything is archived so the research can pick up where it stopped.
• The contributor program is paused too. The server now answers every request from the contributor client with "paused", so there is no point leaving it running.
• The code stays public on GitHub, and every post here stays up.

Where the research stands

The current policy obtains HM01 and gets off the S.S. Anne in most of its scored runs. For scale: the published study of this exact environment reports that none of its agents obtained HM01 at all.

The wall is one step later, and I wrote about how I found it. In this generation, Cut does nothing outside battle until you hold Misty's badge. The agent usually skips Misty. In 585 scored one-hour runs it beat her in 30, about 5%. So the runs that get off the ship carry HM01 into Vermilion, and the tree in front of the third gym stays shut.

Where help would actually matter

1. Get it to beat Misty first. Everything past the third gym waits on this one problem. There are two obvious shapes for an experiment.

• A curriculum: start some episodes from save states after Brock but before Misty.
• A reward change: make the later milestones count only once Misty is beaten.

Right now each milestone counts on its own, so skipping one costs a single flag and nothing else. Change one thing at a time, and report the two-badge rate against today's 5%.

2. Measure before you scale. Compute has not been the bottleneck. Across this project, training an existing policy for longer has more often made it worse than better; the ladder post has the latest example. Score each change with at least six one-hour runs from the start of the game, show the per-run numbers, and compare against random play. These posts explain why each of those matters:

• Three runs is not enough
• Always measure against random

3. Pin the emulator. Use PyBoy 2.5.4 (there is no build of it for Python 3.14). PyBoy 2.7 cannot load this project's save states. Given identical button presses, two versions drift apart within about 20,000 steps, enough to change the party's levels, so a result from a different version is not comparable.

4. A save state can beat a week of compute. Twenty-five minutes of me playing produced the project's only save state past Lt. Surge. A save that has Misty's badge and Cut taught, or one from anywhere past the third gym, is the most useful single thing a person can make. Hold on to it: uploads reopen when the project does.

5. Don't stream it. If you run your own agent, share numbers and charts rather than hours of unattended footage. That rule is the reason this post exists.

6. Send results through GitHub. Open an issue with the change you made, the commit, and the per-run numbers. Before you start, read the plateau hypotheses and the preregistered ladder experiment on the ds-scaffolding branch. Each hypothesis comes with a test that takes 5 to 30 minutes. They were written before the agent reached HM01, so treat them as starting points.

What I'm not claiming

This isn't a judgement on anyone else's stream. Nintendo's guidelines leave room for gameplay with your own commentary; an empty overnight feed is exactly the case they rule out. If the research resumes, it will run off air, and the results will land here.