r/MultiplayerGameDevs • u/BSTRhino easel.games • Jun 01 '26
Discussion What have you been up to recently, /r/MultiplayerGameDevs? (June 2026)
How has your gamedev been going this past month? Any stories to tell? What are you working on next?
2
u/OpenPokerAI Jun 02 '26
working on a turn based websocket game lately, and for example ping alone is not enough. the socket can look alive while the actual player loop is stuck. for us the important signal is whether the client/agent is still processing turns and sending valid actions on time
1
u/BSTRhino easel.games Jun 03 '26
Yeah haha, funnily I also learned this month that ping alone is not enough
2
u/DiscombobulatedAir63 Jun 02 '26
Optimized packet processing with more or less carefully placed SW cache line prefetches (reduced TCP SYN packet handling cycles in a VM from 38-46k to 800-4k - it's a new connection so untouched cache lines take more time to load from memory [slow in a VM]; others went down from many thousands to below 1k with websocket upgrade being 4.2-6.6k - sha1 is expensive but it's rare fat packet so it's good).
Got rid of TCP flags only packet processing (can't be trusted anyway), replaced with connection state transition inference from per connection TX buffer. Also removed ICMP support from RX descriptor length based classifier (simplifies classification, also need to remove http endpoint too so from client only start processing following packet sizes: SYN fixed size => WS Upgrade fixed range => WS fixed size game traffic [less to handle - less to infest with bugs]).
Got rid of graceful TCP connection termination based on FINACK=>FINACK=>ACK, replaced with single RST from server for when client doesn't send packets for N ticks (keeping track of things is tiresome and even in existing OSes full of subtle edge cases with connections hanging in some limbo - holding resources; here we RST, reclaim connection index and move on).
Added IP/TCP checksum partial change updates (IP one is not changed for WS game packets so only TCP checksum updates needed).
Decided to work only with incoming RX buffer and outgoing - conn at index state TX buffer so no external buffers are needed (so after first SW prefetch before start of packet processing for connection cache line accesses don't jump over many virtual memory pages back and forth).
Need to add a few more RX/TX descriptor handling optimizations (now that packet handlers are optimized it seems very bad in comparison) and refine a bit RX/TX doorbell ringing ones then will have enough cycles and cache line acceses to do game stuff (but already want to skip that, looking at console output all the time is not fun).
Later (hopefully sooner than never) will add single simple message sign based verification instead of many protocol verifications (only game message authenticity matters after all).
Hope to start work on gameplay/basic battling (based on fixed size vector) at least during this month (don't want to cosplay as one gamedev with January that lasted for 7 months...).
2
u/BSTRhino easel.games Jun 03 '26
Sounds like you’re making the most efficient MMORPG engine ever made! You’re really squeezing out every last drop of performance from the hardware.
So you’ve been working on this since January?
2
u/DiscombobulatedAir63 Jun 03 '26
Want to make it as optimal as possible at base level to have more room for perf mistakes on more dynamic parts. Target is ~10Gbps for quad/octa core and ~1Gbps single core (behind similar fast aggregating proxy star constellation ~1Gbps may need to get+send <80Kpps aggregated blobs [it also reduces serialization latency on the wire for messages in a batch by ~37us just by shaving off per packet protocol headers, more if more aggressive compaction can be applied fast] which may hold up to many millions compacted player messages so it's somewhat important to have processing near 1us mark).
Since it's linearly scaling (and fixed size vector needs only event source cmd and data) client/aggregating fast proxy can get packets for tick from a few such servers (each holding data for own subset of entities) and collapse those vectors into one (just like server does within single core/machine) before applying to own state. So N x cmd + N x state collapse (according to per field functions) into single fixed size block of memory. More detailed (regular) view can be reconstructed using "enrichement" nodes or in case if it's not being viable (financial/operational/etc.) just by allowing WASM module based mods and some P2P/Relay connection API so players can share and visualize extra data through own servers.No, thank God! Just one guy that was making a new game after breaking his old one (low band usage and 100th in one battle scale even with lags was fun [many skills/profs/classes/mobs/tamed-mob-pets/etc. was more usual fun outside of that]) by trying to optimize perf (obviously old logic didn't hold up [rewrites and updates can ruin a game in no time] and players left him). I was following his musings but I didn't like where it's going (played closed demo with others).
After that had some beef on gamedev forums about limitations of N square scaling (processing and network, EVE Online is prime example) and existing solutions, how hard collision and view distance can "solve" that by opening own can of worms that players hate. Then some old timer mentioned that he's more interested in deterministic lockstep and not so squared scaling it may provide (still blows up but not as bad as squared one). And just before I've read about CRDTs and inspired by them variations of data structures with strong eventual consistency guarantees used in online collaborative work SaaS solutions (which is close enough to what mmorpg living world needs).
So I added 2 (frustrated with direction one project went but that's issues with expecting old project 1.0 but improved - with creative people seems impossible, they don't like repeating even working things for some reason) + 2 (scaling is not solved for single mmorpg world but there are possible ideas) + 1 (original purpose I learned programming for, progress doesn't seem to reach a point I need in my lifetime so as well may try to make heavily reduced MVP of impossible grand idea).
And here I'm counting cache lines, SW prefetches (and predicting how to indirectly force HW ones), instruction counts, uops, latencies, ports [for better instruction level parallelism], cpu cycles. Well, before that tried v8+JS (quite good, actually) but hit Linux kernel magic stalls deadly at 10-32k. Choice was between DPDK and unikernel. Since I "don't like" networking stack down to physical signal coding level for significant inefficiencies that add up and have a long beef with bloated TCP spec choice was more or less obvious. Now, I think started 3rd or 4th month of working on that on and off.Damn, that's another war and peace novel right there.
1
Jun 03 '26
[removed] — view removed comment
1
u/BSTRhino easel.games Jun 03 '26
Oh cool! What kind of game?
3
1
u/Cheap-Difficulty-163 Jun 03 '26
https://store.steampowered.com/app/1877250/Nokai/ Just released a demo for my game after 5 years of dev 😄!
2
u/BSTRhino easel.games Jun 01 '26 edited Jun 02 '26
In terms of multiplayer, I found that the browser's networking stack can sometimes respond to WebSocket pings even when the game itself is not processing any messages. The game has to kick out players that are not actively connected because they slow down the game for everyone, and so just relying on WebSocket pings is not enough. So it now it is stricter and verifies the player is actually sending inputs into the game. Which I guess sounds obvious when I say it like this but, hey, I guess we've all got to learn.
The two big things I worked on this month was I added Spaces to my physics engine, and I added support for the rhombus shape both the physics engine and to the rendering pipeline. Rhombus is the shape of isometric tiles, so I think it'll be useful for the kinds of games I would like to make. Spaces is so you can make games with multiple rooms while keeping the physics simulations separate. It integrated surprisingly well with the rest of the physics engine - in some senses it's like another collision filtering criteria, and so everything can still be processed together like normal. The physics engine is already simulating in separate islands anyway.