Bus-Commute Game Testing: An Honest Methodology

I've mentioned my bus commute as a testing context in maybe a dozen game reviews on this site. People have noticed and asked what I actually mean by it. So this is the post explaining the methodology, such as it is, and why I think it's a more rigorous way to evaluate browser games than the studio-quiet-room testing developers tend to default to.

Bus I ride goes from East Vancouver to downtown and back. The route is about forty-five minutes each way depending on traffic. I do this commute four days a week. That's roughly six hours of phone-game time per week, split across eight commute sessions. I review games on this site partly because the commute gives me consistent testing opportunities, and partly because the studio I worked at as community manager taught me to value real-world test conditions over ideal ones.

What the bus tests

Bus is a hostile testing environment for browser games. Several things make it harder than studio testing.

Movement. The bus is vibrating, accelerating, decelerating, and turning constantly. Your hands aren't steady. Your eyes aren't steady. A game that requires precise input or rapid visual scanning is going to feel different on a moving bus than at a desk.

Lighting variation. Glare through bus windows changes constantly. Direct sunlight wipes out a phone screen's visibility for a few seconds. Tunnels remove all ambient light and reveal whether your phone brightness is reasonable. The same game that looks fine at a desk often becomes unreadable on the bus during specific lighting conditions.

Audio constraint. I don't wear headphones on the bus because I want to hear announcements and pay attention to my stop. Most games on the bus get tested with audio off or barely audible. This reveals which games are visually self-sufficient and which ones use audio cues as critical gameplay information.

Attention dispersion. I'm also watching the route, listening for announcements, thinking about my day, occasionally looking up to check the people around me. A game that needs my full attention to be enjoyable is going to feel less playable on the bus than one that I can attend to partially.

Short-session pressure. The bus ride is finite. I don't want to start a game I won't be able to pause smoothly when my stop approaches. Save-and-resume behaviour is critical. Games that lock you into long sessions without natural break points are wrong for this context.

Why this matters for browser games

Most browser-game development happens in a quiet room on a desktop monitor with a keyboard and mouse and high-quality speakers. The developer's testing environment is essentially the best possible case for their game. Of course it feels good in those conditions.

Real players play in worse conditions. On the bus. In bed before sleeping. Waiting for an appointment. During a slow afternoon at work. The play environment is noisy, interrupted, partial-attention, often on a phone. A game that's only good in ideal conditions has a smaller real audience than a game that works in worse conditions too.

Bus commute is a useful proxy for these real conditions. It's not the only adverse condition, but it covers most of the relevant variables. A game that plays well on my bus rides probably plays well in most real-world contexts. A game that struggles on the bus is going to struggle for a lot of players, not just me.

Specific things I notice

Touch hit-area size. Games designed for desktop with mouse-aim tend to have small interactive elements. On a moving bus my finger misses these constantly. Games designed mobile-first have larger hit areas because the designer anticipated touch use. The difference is immediately visible to anyone playing on a bus.

Visual clarity at small sizes. My phone is a Samsung Galaxy A52, a mid-range Android from 2021 that I refuse to upgrade because the keyboard layout suits me. Its screen is 6.5 inches. Some games look fine on this screen. Others have UI elements that I can't read without bringing the phone within twenty centimetres of my face, which is fine in private but uncomfortable on a public bus.

Mid-session interruption handling. Sometimes I look up to check my stop and look back at the game thirty seconds later. The game's behaviour during my distraction matters. If it kept going and I died because of inattention, that's a frustrating session. If it paused or held state gracefully, that's a thoughtful design.

Save granularity. If I have to leave the bus mid-game, what happens? Some games save automatically and let me resume exactly where I was. Some lose all progress at the previous checkpoint. Some don't save at all because they're high-score arcade games. Each is okay for different game types, but the developer should have thought about it explicitly.

What I rate higher because of bus testing

Games that respect partial attention. Pixel Runner on this site is the canonical example. One-button mechanic. Clear visual obstacle telegraphing. No audio dependency. Quick respawn loop. I rated this game five stars partly because of how well it works in suboptimal conditions.

Games that pause naturally on tab-blur. If I switch to look up directions in another app, I want the game to know I've left. Good games do this. Some don't, and you come back to having died for no good reason.

Games with reasonable touch-area size. I shouldn't have to squint to play. Anything designed mobile-first has thought about this. Anything ported from desktop usually hasn't.

Games with informative passive states. If I look down at my phone after thirty seconds of inattention, the game should tell me what's happening in a glance. Some games are clear about state. Others require you to mentally reload context every time you look back.

What I rate lower because of bus testing

Games requiring sustained focus across long sessions. Some adventure games on this site are good games that I have rated three or three-and-a-half stars because the format doesn't suit short-burst play. The Crystal Caves Metroidvania got five stars from me despite being long, because it has tight save points and clear visual state that survives a bus-stop interruption.

Games with audio-dependent gameplay. Rhythm games. Stealth games where audio cues are critical. Anything where you need to hear what's happening. These get lower ratings from me because I can't play them in my main testing context, and lots of players probably can't either.

Games with small touch targets. If I miss the button half the time on a moving bus, the game has failed to anticipate my use case. Touch design should accommodate imprecise input.

Is this a fair way to evaluate games?

I think so. The alternative is evaluating in conditions that aren't representative of how most players use these games. Browser games are played by people on buses and trains and during work breaks and in bed at night. They're not played by tournament-quality desktop sessions in soundproofed rooms.

If a game wants to be the kind of thing you play on a couch with full attention, fine. Rate it on that basis. But it should be clear that's the design intent. Most browser games don't communicate that intent explicitly, so they get tested against the broader use case. If they fail, the rating reflects that.

Bus is a strict reviewer. Strict reviewers make better catalogues. That's the case I'd make for this method as a real evaluation approach rather than a quirky personal habit.