Japanese game-dev blogs this week converged on a theme that doesn’t get enough attention in English-language tutorials: the unglamorous plumbing that keeps a game feeling solid once the fun mechanics are in place. Three posts in particular are worth digging into, because each one exposes a failure mode that’s easy to hit and annoying to diagnose.
The Y-velocity bug everyone eventually writes
A Unity developer working on their first 2D platformer ran into the classic “jump feels floaty, falling takes forever” problem. The instinct is to blame Gravity Scale, and that’s exactly where the author started — tweaking gravity values with no effect. The actual bug was in their own movement code: every frame, they wrote rb.linearVelocity = new Vector2(horizontalInput * moveSpeed, 0), which unconditionally zeroed the Y component. Since horizontal movement and jump input are typically processed in the same Update/FixedUpdate pass, this meant gravity’s contribution to vertical velocity got wiped out immediately after Unity’s physics step applied it. The fix is simply to preserve the existing Y velocity when setting horizontal velocity — read rb.linearVelocity.y first and reuse it, rather than hardcoding zero.
This is a great example of a bug that’s invisible in the code review sense (nothing throws, nothing looks obviously wrong) but glaring the moment you play. It’s also a good reminder that in any physics-driven movement system, you should be explicit about which axes your gameplay code owns versus which axes the physics engine owns. Mixing “set velocity directly” input handling with an engine that’s also integrating forces every fixed step is a recipe for exactly this kind of silent overwrite.
Pausing is harder than it looks
A solo developer building a game for a 2025 unityroom game jam ran into a different kind of state-management pain: pause logic. What starts as “just set Time.timeScale to 0” quickly falls apart once you have overlapping systems that need to pause independently — a tutorial overlay, a dialogue box, an options menu, background music — each with different rules about what should freeze and in what order. The author’s response was to generalize the ad-hoc pause code from their jam game into a reusable library, Priority Pause System, published as a Unity Package Manager package.
The core idea, as the name suggests, is treating pause requests as prioritized, stackable states rather than a single boolean flag. This is a pattern worth knowing even if you never touch this specific library: instead of one isPaused bool that every system checks and fights over, you want something closer to a stack or priority queue of “who is requesting a pause and why,” so that closing a dialogue doesn’t accidentally unpause a menu that was opened on top of it. Any game with nested UI states — inventory over pause menu over dialogue, for instance — benefits from this kind of structured approach instead of scattered Time.timeScale calls.
Keeping the illusion intact in a CLI game
On the opposite end of the visual spectrum, a Python developer wrote about building a CLI/CUI text adventure — no graphics, no physics, just text and player input. The interesting design problem here isn’t rendering, it’s immersion under failure conditions. A raw Python traceback dumped into the terminal instantly breaks whatever narrative spell a text adventure has cast, in a way that’s arguably worse than a crash in a graphical game, because the terminal itself becomes part of the diegetic space. The article frames this as needing both “meta” presentational touches and genuinely robust exception handling so that unexpected input or edge cases degrade gracefully into in-fiction messages rather than stack traces.
This is a useful lesson for anyone building tools-as-games or narrative CLI experiences: exception handling isn’t just about preventing crashes, it’s a presentation-layer concern. Wrapping input parsing, save/load, and game-state transitions in handlers that translate technical failures into flavor text (“the door refuses to budge” instead of KeyError) is cheap to add and disproportionately effective at maintaining tone.
Quick hits
A two-part series on browser-based 3D games is worth a look if you’re curious how WebGL/WebGPU pipelines actually get 3D assets — models, textures — compressed and cached in a browser rather than just rendered; it’s a solid primer for anyone assuming “the GPU renders it” is the whole story. Separately, a two-years-later retrospective on a niche personal project (a pose-reference/dessin-doll site) is a candid reminder that shipping is the easy part; the real test of an indie project is whether it’s still online and used two years on, something the author notes is rarer than most “I launched my side project” posts would suggest.