If you know more than others as a professional multiplayer game developer, that's great, but in that case the thing to do is to share some of what you know, so others can learn. If you don't want to do that, that's fine, but in that case please don't post. Putdowns and swipes only degrade the discussion.
I could post anything objectively true in this thread like "the sky is blue", and some idiot will post a one sentence response that in fact it's not. This idiot likes to be the last person getting snark in responding to a completely reasonable statement of fact or opinion by an expert in the space.
What I do differently is that yes, I do reply to the snark with a rebuttal. Is this rebuttal snarky? Potentially, but is it earned? Definitely.
You're moderator so let me speak to you that way. If you don't let people rebut bullshit in this comment section, you'll just end up with a bunch of uninformed discourse, where the final word is made by some idiot, who doesn't even make multiplayer games and everyone ends up thinking the sky is fucking green. This has real world consequence when future game developers try to build games on poorly made technology, which ruins game studios and people's lives.
Then again, it's hacker news, and what do a bunch of wannabe startup guys know about making games in the first place. Unskilled and unaware of it. Moderate away sir!
https://news.ycombinator.com/newsguidelines.html
Btw, it's quite common for commenters to underestimate the provocation in their own posts and overestimate the provocation in other people's posts. Those two factors can multiply into quite a skew in perception (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...). I wonder whether this might be a bit of a factor here, if you really don't see how aggressively your comments were coming across.
In the future, I don't feel that writing anything more here on this topic is a worthwhile use of my time.
You're just being asked not to be a jerk to people on a messageboard. It's the same thing being asked of everyone else so that we can have a decent messageboard and it's not difficult.
As to how to store the game state in memory, it's usually not something that needs much thinking: it's simply done the same way (or similar) as the game's client code. After all, netcode is mostly about efficient state replication and this saves CPU time when replicating it across clients - and gives more CPU time for minimizing bandwidth (like delta encoding, quantization, etc). If you want, you can utilize some techniques like ECS to optimize for CPU cache locality, but it affect gameplay code a lot and would need to get the whole team onboard.
Also, I just noticed the username "gafferongames" - Glenn's blog[1] has been a must-read for netcode engineers. It helped me a lot when I started working on netcode in the 2010s
1) AFAIR, the ECS patterns family[0] originally came from MMORPG world, and boiled down to designing your game state to work well with relational databases;
2) Around 6 years ago, while toying with yet another (see [0]) take on ECS for a simple game, and wondering how to query stuff efficiently, it dawned on me that the code I'm writing is basically implementing spacial indices and other such concepts from relational DB world. At that point, I thought to myself, "why continue wasting time Greenspunning[1] a database for the internal state, when I could use a real one?", and followed by "you know what I really need next? An in-memory SQLite database to store all my runtime game state!".
I didn't get very far with my experiment due to constraints of adult life, but I did prove that I can build a basic Roguelike skeleton (2D tile map, entities, walls, collisions) while storing all state in SQLite, and have it run at 60 FPS with half of the frame time to spare for other things, on moderately powerful machine (as of 6 years ago), all without too much optimization (Common Lisp with FFI bindings to libsqlite3 + a simple RLU cache in front of queries).
So it's not at all a stupid idea, IMO :). I would test it further if I had the time.
--
[0] - The term means different things to different people. I've seen at least three distinct gamedev design patterns claiming the name ECS for themselves, all conceptually incompatible with each other. More, if you also consider "whatever Unity/Unreal/Godot/... calls ECS".
Is it simply to be able to persist the game state?