Ribbie is a browser-based baseball gamecast that converts live MLB play data into an 8-bit styled animation. It shows the field, players, scoreboard, stadium art, day and night changes, and between-inning interstitials in near real time. The maker framed it as an early project and asked for feedback, and the response was overwhelmingly enthusiastic. Even people who do not follow baseball said the format was charming and easy to leave on in the background.
The useful consensus was that the product works best as ambient viewing, not as a replacement for TV. Baseball is slow enough that a pixel-art reconstruction can track the action without feeling absurd, but that same slowness creates long dead periods. That pushed people toward a clear product direction: add sound effects, event summaries, instant replays, and a simple way to catch up on missed plays. Several people wanted a back button or highlights mode more than a timeline scrubber. Others asked for browser-tab updates, more zoom on the active play, and smoother pacing when multiple pitch events arrive in a batch so the experience feels less like nothing happening and then everything rushing at once.
Two practical issues kept coming up. First, live data often appears to be ahead of TV and radio, which makes the site good for monitoring but bad for anyone trying to watch alongside a delayed broadcast unless there is a sync offset. Second, MLB data rights are a real business risk. People pointed to old examples of MLB aggressively policing play-by-play reuse and to copyright language on MLB-related feeds that appears to limit use to individual, non-commercial access. That did not stop the excitement around the project, but it did shape the most grounded read on it: this is a strong proof of taste and execution, and if it grows, data licensing and feed terms will matter as much as the frontend.
If you build ambient sports or status displays, the winning use case is not replacing the main broadcast but giving fans a low-attention second screen they can leave on while working. The bigger constraint is not graphics, it is access to reliable live data and the platform risk that comes with depending on unofficial or restricted feeds.
Strongly positive. People loved the concept, nostalgia, and craft, while the main caveats were the AI-generated pixel art, the need for audio and replay features to make slow baseball more engaging, and concern that MLB could shut down a project built on live game data.
Key insights
01
Best as a background companion
The strongest product framing was to stop treating this like an alternate broadcast and treat it like ambient sports UI. Baseball's pace gives the animation enough time to work, but not enough action to hold full attention on its own. That makes Ribbie most compelling on a TV during work, on a call, or in a muted room where radio or live TV would be distracting.
Design the next features for glanceability, not immersion. Prioritize alerts, summaries, and low-attention cues over anything that assumes people are staring at the screen continuously.
People did not ask for a deep timeline editor. They asked for a fast way to recover what they just missed. A back button for the last play, between-inning recap cards, and a rapid highlights mode fit the way baseball is consumed here. They also solve the current burstiness, where delayed feed updates can make several pitches play back too quickly in a row.
Build a lightweight event history first. A last-play stack and highlight recap will likely do more for retention than a full replay interface.
Without sound, long stretches of baseball turn into dead air and users drift away. People specifically wanted simple event-driven effects for balls, strikes, outs, and home runs. Live broadcast audio was described as ideal, but hard to embed, and AI voice commentary sounded too costly for a free side project. That leaves classic game-like sound design as the obvious next step.
Add cheap, deterministic audio before chasing commentary. A tight sound event system will increase session time and make background use work much better.
Several people noticed the animation was a pitch or more ahead of radio, over-the-air TV, or streaming video. That flips the normal expectation. Ribbie is not lagging behind the broadcast, it can become the spoiler. For a fan trying to follow along with another feed, that is a feature only if there is an adjustable delay.
Expose a user-set sync offset. If you do not, the product will be great for standalone monitoring and annoying for anyone pairing it with TV or radio.
The sharpest caution was not technical. It was legal. People recalled MLB going after earlier play-by-play sites and pointed to MLB feed terms that appear to limit use to individual, non-commercial consumption. Plaintextsports.com was mentioned as an example of a long-running free service, but nobody treated that as durable protection. The takeaway was blunt: if this gets traction, the hardest problem may be permission, not engineering.
Do not build a business plan on top of an unofficial feed. If you want this to survive growth, start thinking early about licensing, fallback providers, or a hobby-only ceiling.
People liked the idea of applying the same treatment to soccer, football, golf, or tennis, but the comments landed on why baseball is such a good fit. Pitches and plays are discrete events with natural pauses, so you can reconstruct the game without simulating continuous motion. For faster sports, you either need much richer positional data or you are effectively building a game engine. ESPN's public-ish APIs were mentioned as a way to prototype other sports, but not as proof the experience would translate well.
If you expand beyond baseball, choose sports with event-based flow first. Golf and tennis are better bets than soccer or basketball unless you have far deeper tracking data.
The AI-generated pixel art drew the clearest criticism, and it was specific. People called out anti-aliasing, smeared edges, inconsistent palettes, and the difference between pixel art and images that only imitate it. Suggestions focused on deterministic downsampling, palette reduction, proper pixel fonts, and eventually commissioning handmade sprites. That critique actually sharpened the product case, because the concept already works and the visuals are one of the few obvious ways to raise quality fast.
Treat visual consistency as core product work, not polish. A more disciplined pixel pipeline will improve trust and distinctiveness as much as adding another feature.
One pushback rejected the assumption that every interface has to shrink onto a phone. For a product aimed at TVs, desktops, and passive viewing, forcing a cramped mobile layout can dilute the experience. That cuts against the otherwise common request for larger mobile text and denser small-screen support.
Be explicit about primary surfaces. If desktop and TV are the real targets, optimize those first and let mobile be secondary instead of compromising the whole interface.
One commenter argued the split reaction to AI-heavy projects is driven less by quality than by whether people already like the outcome. In this framing, the same community that dismisses some LLM-built work as slop will forgive heavy AI use when the result feels joyful and well executed. That does not answer the art-quality critique, but it does explain why the thread stayed warm despite the maker openly saying Claude and Codex were used heavily.
If you use AI in a consumer-facing project, the output quality will matter more than ideological purity. Expect criticism, but focus on whether the end product feels coherent and useful.