yeah that matches what I see, most of what we run at work is one app and one database, so the slow query log plus looking at the plan gets you like 90% of the way. I never really had the multi service case where otel pays off, I guess at some point it does, but for a small team it felt like a lot of plumbing to end up finding the same n+1 query lol

I’d add that most of the time nobody actually measured anything. at work we inherit slow sites all the time and the first guess is always “the stack”, then you profile it and it’s one query running per item in a loop or something like that. I had the same with my own side project, was sure I needed a bigger server and after measuring the problem was somewhere else completely. measuring first is boring but it’s cheaper than any rewrite I guess

thanks! short answer is no, a reload doesn’t fix it. when the browser source comes up mute the page is actually fine, the audiocontext is running and even a test tone from the debugger never reaches the obs meters, so it’s obs, not the game. reloading or toggling “control audio via obs” didn’t help, only a full obs restart does. funny part is it fails on alternate starts, I measured 12 in a row and it was mute, sound, mute, sound. so the watchdog reads the meters for a few seconds and if the peak is under -60 dBFS it treats it like a black screen and restarts obs. and yeah the dwell idea is good, I’ll steal that

on the fear part, in a healthy team the author still owns the change, the reviewer is a second pair of eyes not an insurance policy. what helped my people a lot was asking the author how they tested it and what happens if it goes wrong, if they can’t answer that’s your review comment right there. and if something breaks after you approved it, you fix it together and add a check so it doesn’t happen again, nobody serious blames the reviewer for that

Interesting idea, but in my case it would feel worse I think, each paint costs a charge, so undoing both means two people lose a charge and nobody gets the cell. I don’t think it happens much at our size anyway, two people on the exact same cell inside half a second is pretty rare. last write wins is a bit unfair but it’s simple, and since every write is stored you can always see who painted what

Same conclusion here from the other side, I have a small multiplayer browser game where everyone paints cells on one shared grid (node, postgres, SSE), the client applies the paint right away and the server either confirms it or answers with a 409/429 and the client puts the old cell back. the rejection part is the one that took me longest honestly, a mutation that is valid locally but the server says no (out of charges, same color already there, world paused) and you need a different message for each, otherwise people think it’s lag. conflicts are just last write wins per cell, but that works because every write is a row in an append only events table, so nothing is really lost and you can replay or undo. and on reconnect I don’t try to merge anything, the client asks for the whole state again, at that size it’s cheaper than being clever.

for a multiplayer browser game I ended up skipping websockets and using SSE for everything that goes server to client, and plain POST requests for the actions. it’s just http so the reverse proxy, cookies and reconnects work without doing anything special, and EventSource reconnects by itself. one gotcha if you use express with compression middleware, exclude the SSE route or the events get buffered and arrive in chunks. websockets make more sense if the client sends a lot, mine mostly listens

For me the evidence was the server logs, filtering by user agent. my main page is basically a canvas game, so the html has almost nothing for a crawler, and I was surprised to see googlebot not only rendering it but opening the SSE stream like a real player (I noticed because bots were showing up as online players lol). what actually got indexed were the plain server rendered pages I made for each thing worth sharing, with title, og image and json-ld, listed in the sitemap. so I didn’t change the app rendering, I just gave crawlers simpler pages to read.

hey Tower, late follow up but you were right and it’s done. the ? button now has a SEE THE RULES button right under the welcome, it’s a plain manual with 8 short questions and the real numbers, and those numbers come straight from the game code so they can’t go stale when I change something. thanks for actually playing and saying you had no idea what was happening, that one comment changed more than any stat I was looking at

thanks, it’s the first number I look at every morning lol. one thing I learned this week is that you have to clean it before trusting it, a crawler from some chinese cloud providers was keeping the cookie and coming back, it was 6 of the 7 “visitors” one day. so the real number is smaller than it looked, but at least now it’s honest

thanks, means a lot after how the last thread went lol. honestly it’s still early to say if it worked, the number I’m watching now is how many people who paint on their first day come back another day, if that one moves I’ll know the card and the siege clock did something.

both, kind of. the part that actually erases stuff is plain game AI, rules and a budget: it finds groups of 25+ connected pixels, announces a siege on one, closes a ring around it, and if people don’t keep the ring lit it eats the work. all deterministic code. on top of that, every 15 min a small LLM (gemini flash lite through openrouter) gets the state of the board and picks which of the legal moves to make, which work to siege and when, and the code clamps whatever it answers, it can’t break the rules. it also writes a one line reason that goes in a war log on the site, that’s the only generated text players see. everything she says in the game and on the stream comes from a bank of lines I wrote by hand, and nothing on the canvas is generated, it’s all people painting. if the LLM is off, a fixed set of rules plays instead

thanks, this is pretty much where it went after that post. the end of a visit now shows a small card with what you lit, what she took back and how much of it is still standing, and the siege got a visible clock, the ring closes first and the assault comes 30 min later so you can see it coming while you’re still there. and whatever you paint in your first two hours she can’t touch for 24h, so when you come back there’s still something of yours. too early to know if it works, the numbers are still tiny, but “reads as a challenge instead” is exactly what I was trying to get to

Hello Tower, I will try to create a page where the mechanics of it, the machine, are clearly explained. Now I try to explain it here: She thinks every 10 seconds. She is reconquering based on a budget, but it is enhanced if people draw more. Every 15m the LLM chooses a larger target to turn off its lights. She advances along her border but if a player reconquers she can go after him with more determination. It must be taken into account that a painted light has a protection of 72 hours, only a declared fence can with it. I hope I have explained a little more to you. Anyway, I’m going to try to implement that more clearly in the game. If you have any more questions, tell me and I’ll answer you.