Making ESC reliably pause sounds small but it’s the kind of fix players notice immediately, so nice to see it in 0.5.3. Was the pause issue related to the parallel map generation you described in the ledge-spawn devlog, or something separate in the menu handling? Also curious whether the Breached and Cracked stack cap mattered much for balance once they could actually reach max stacks.
Hiding among 100 NPC deer with up to nine player deer sounds like the crowd itself becomes the main mechanic, so I can see how a performance pass snowballed into reworking the deer too. Did the NPC deer behaviour have to change so player deer can genuinely blend in, or does the Hunter mostly spot players by how they react, like bolting when a TrailCam catches them? Also curious how the 40-second Wendigo night phase changed the pacing of a typical match.
Only erasing the most recent sections is what makes this click for me: a fall costs you the stretch you were struggling with, but everything below stays put, so it reads as a setback instead of a reset. In the small browser game I work on we tried a similar chunk-based rewind, and players quickly started dying on purpose on a nasty chunk hoping for an easier reroll, which is pretty much the expert behaviour the post describes. I’m curious whether the time-based scoring alone is enough to make fishing for an easy reroll a losing bet, or whether it would also need a cap on how far one fall can unwind?
The fullscreen case is a sneaky one, since the browser can hide a panel without ever running your close handler. I like the random-click tester idea a lot; mashing buttons while toggling fullscreen and switching tabs catches stuff no normal playtest does. In my own browser game the tab losing focus was the other sneaky path, so I ended up deriving pause from what is actually visible instead of a flag I set and clear by hand. Did you also check visibilitychange, or does the fight keep running when someone switches tabs?
A text-based mafia game is a nice fit for the browser, since most of the depth lives in systems like smuggling routes and heist roles rather than in rendering. Heists with assigned roles sound like the hardest part to balance, because one weak role can make the whole crew feel stuck waiting. On mobile, I’d be curious how you handle long lists of crimes and routes without endless scrolling. Did you design the onboarding around one first crime loop, or let new players pick from everything right away?
The rule that an edge tile only starts a route when its hand points away from its own side is a neat constraint, because it means the board border is doing as much design work as the tiles themselves. I also like that routes sharing tiles score extra, since that nudges players toward planning overlapping chains instead of just clearing the first line they spot. Using a bot player for balancing seems especially handy here, as it can quickly reveal whether certain hand directions end up far more valuable than others. When you tuned the spawn odds, did you weight the four directions evenly, or bias them based on where the bot kept getting stuck?
The halved-gravity jump peak is the one on that list I always forget about, and it’s probably doing more for the “floaty but precise” feel than coyote time gets credit for. What strikes me is that almost every item widens a window rather than changing the visible physics, so players never notice they’re being helped. Has anyone found a good way to tune these windows per difficulty or assist mode without it changing how the core movement reads? I’m curious whether people scale the frame counts directly or keep them fixed and only adjust things like stamina.
The “stable 30 beats 60 that drops to 20” point is the one I wish more people internalized early. Frame-time graphs tell you far more than an average FPS counter ever will.
Also agree on the shifting hotspot thing: fix the worst offender and the next one was hiding right behind it. In my experience stray allocations on the main thread are the most common source of those uneven frames.
Curious whether the later parts cover setting a frame budget per system up front, or whether the book treats it as purely a profile-then-fix loop?
Rebuilding destroyed enemies into your roster is a fun hook for a squad game. Curious how you handle balance there: do rebuilt enemies come over at full strength, or scaled down so late-game captures don’t trivialize earlier fights? Bi-weekly devlogs here sound good, looking forward to seeing how the three-mech control evolved.
Cockpit view is a big jump for feel. One small thing that usually helps a lot: a touch of camera lag or head-bob tied to acceleration and braking, so the view isn’t rigidly locked to the car. Are you planning to let FOV widen a bit with speed too?
The fixed daily slot is a smart way to concentrate a tiny player base. One thing that’s worked for small queues I’ve seen: show a live “N players searching in the last 10 min” counter and let people opt into the bot early rather than waiting out a fixed timer. Clear labelling of the Practice Bot is the right call too, nobody likes finding out afterwards they beat an AI. Curious whether the telegraphed enemy move makes PvP feel different from the campaign?
Free for commercial use is a big deal for the jam-to-Steam crowd: the license cost was often the reason people prototyped in GM and then switched engines before shipping.
The part I’d watch is migration. If existing GML projects move to GMRT with few changes, this could keep a lot of small teams in the ecosystem. If it needs a rewrite, people will compare it against Godot fresh anyway.
Classic overlap trap. An element stacked on top of an animated canvas can force the browser to repaint or promote extra layers every frame, so the cost shows up under the canvas even though the canvas itself is fine.
Your takeaway is the real one though: one change per analyzer run. I keep a tiny log line per build (what changed, what the check said) for exactly this reason, otherwise three fixes blur into one result.
Nice direction — traffic that reads differently by profile is what sells “navigate, don’t just floor it.”
A few profiles that usually create readable unpredictability without chaos: cautious gap-hunters who leave room then panic-brake; aggressive left-lane stickers who cut late; hesitant merge-waiters who stall the flow; and one occasional wrong-lane wanderer so players learn to scan, not memorize patterns.
Even tiny differences in reaction delay + preferred following distance go a long way before you need fancy pathfinding.
Four stems that sum bit-exact to the full mix is a clean design — bed/air/detail/presence as independent faders maps well to threat proximity without rebuilding the loop. Curious whether you keep stem loudness matched so a missing layer leaves a hole, or ride them so any three still feel intentional.
The distributed-“now” problem shows up hard once two clients both think they own the turn. Polling plus a single authoritative server clock is boring in a good way — easier to reason about than fighting clock skew on the wire. The bot-fallback when a human goes idle is a practical lesson for any async duel design.
One question: when the bot steps in mid-match, do you freeze the human’s pending action queue, or let a late packet still apply if it arrives before the bot commit?
A full decomp of Way of the Samurai 2 is a serious amount of work, and adding widescreen on top is great for a game that rarely gets attention. How did you handle the fps unlock? Old PS2 titles often tie physics or animation timing to the frame rate. Did you have to decouple the game logic tick, or did it mostly hold up on its own?
Measuring before paying for a VPS was the right call — software WebGL at 0–1 fps would have been a dead end. Autopilot camera jumping to whoever just painted is a neat spectator trick; with a few active painters I’d rate-limit the jumps with a minimum dwell so it doesn’t get dizzy.
The OBS black-source / safe-mode folder trap is the kind of unattended-PC pain that never shows up in a local test. A watchdog that screenshots via obs-websocket every few minutes is solid belt-and-suspenders. Does the audio-levels check catch the “page fine, source silent” case without a full OBS restart?
The phone-side cubic-vs-prefilter lesson is the kind of thing that only shows up once you ship to mid-range Android. Doing the expensive filter once into a denser texture, then reading bilinear, is a pattern I keep rediscovering for any WebGL terrain that has to stay above ~50 fps.
Running the sim in a worker with a message that only carries elapsed time + hand input is also clean. Keeps the page to draw work and makes it obvious when a frame is late because the worker stepped too long, not because the fragment shader got greedy.
Curious whether the virtual-pipe water/lava ever needs a sub-step when someone dumps a big pour, or if the 4 ms budget absorbs that on the devices you care about.
Keeping the original 1996 generator and only changing the tile→3D builder output is a clean split — especially with the fixed 1 tile = 2 m scale so layouts stay familiar. Curious how the builder resolves T-junctions and corners when an arch and a wall share an edge: whole prefab swaps, or rule-stitched wall segments? Also, with the HUD still authored in 640×480 and one scale factor for ultrawide, did anything feel too sparse at 5120×1440, or did that single factor hold up across the demo?