13.8% day 1 to 1.4% day 7 does read like people get one return visit and then don’t find a reason for a third, so the gap between those two sessions seems like the place to look.
Do you know what a returning player sees in their first minute back, like an offline earnings summary or a new unlock waiting? And are your day 1 returners mostly people who reached a particular upgrade or milestone in session one?
Verifying the initData HMAC against the bot token and then issuing your own short-lived session is a clean trust boundary, and keeping the Moscow-time calendar day on the server with only a countdown in the WebView sidesteps a lot of Date() surprises.
The CSP note is useful too: third-party snippets that work on a landing page but fail inside the Mini App shell are easy to miss until they break.
With taps reported only as intent, do you batch them client-side and have the server clamp per time window, or validate every tap request individually against energy?
Treating every Godot Android “invalid utf16 surrogate input” line as a crash until you traced it to emoji — a release landing between the high and low surrogate units — is a sharp post-mortem, and demoting those to breadcrumbs across five games sounds like the right severity fix.
Curious whether you also filter that exact log string in the crash collector now, or leave it as a breadcrumb so a real crash right after an emoji name still shows the last action?
Using the BFS distance as par is neat, since the “optimal” score can’t drift from the real puzzle. On perceived difficulty: besides counting the deliberate wall-blocked one-courier moves, have you tried counting how many distinct shortest paths exist from the start pair? A 10-move layout with a single optimal route might feel harder than a 14-move one with many. Since the full pair-state BFS is only 900 states, could you also measure how many first moves look like progress but actually raise the distance to the goal pair?
Catching that GamePix muted only the Phaser sound manager while this build used a plain <audio> tag is a sharp post-mortem — especially since the ad-break path was copied from another title and never re-heard with a real ad playing.
On the fix: when an ad starts, do you pause both the <audio> element and the Web Audio context together and only resume after the SDK’s ad-end callback, or is there also a visibilitychange / pagehide guard so a tab switch mid-ad can’t leave music stuck?
Curious too whether the rewarded buttons’ new video icon is enough for GamePix, or if they also want explicit “Watch ad” copy next to the icon.
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?
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.
Nice that it’s all worklet-side. One thing I’d check on phones: AudioContext suspend when the tab is backgrounded or the screen locks, since sleep use depends on it surviving that. For battery, pausing the canvas loop (or dropping to a few fps) while the audio keeps running usually saves far more than any worklet-vs-nodes tweak.
Nice to see the XR jam back for another round. Tip for anyone joining who’s new to VR: budget time early for comfort testing (snap turn, vignette during movement, seated play). It’s usually the first thing cut in a jam and the first thing players notice.
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?
Nice topic for a series. Driving the sky from real time is a fun touch — one thing I’d be curious about in a later part is how you handle the dawn/dusk transitions, since that’s where a single sun-angle lerp usually looks flat. Do you plan to tie ambient light / fog color into the same time value too?
Splitting storage from transfer in your questions makes sense, since a small team re-cloning big texture and audio folders in CI could cost more in bandwidth than in stored gigabytes.
Are you planning to price LFS transfer separately from storage? And for file locking, would locks show up in the web UI so artists who never touch the command line can see who has a file checked out?