As a hobbyist game dev of ~1 year what I really want is a "multiplayer: the hard way" guide so I can learn how to do multiplayer on my own. My mental model of how multiplayer games actually work is basically full of holes and question marks. I haven't found that something yet.<p>I've been focusing on single player experiences because I haven't found that comprehensive guide that explains the nuts and bolts of multiplayer for video games. If I knew more then I could pull in more of my software engineering knowledge.<p>I fear that there is more incentive to create projects like this to hide that knowledge away from game developers than to thoroughly explain how to build one's own multiplayer solution.<p>I post this here in case someone knows of such a comprehensive guide for multiplayer.
Until proven otherwise, I'm a firm believer that all good, modern multiplayer games basically rehash the original 1999 client-server, server authoritative architecture design of QuakeWorld. You'll get a lot of young amateurs claiming otherwise or that game multiplayer networking is too nuanced than that, but I think that's a load of bunk.<p>I think the opposite is true, most <i>good</i> multiplayer networking uses this model, and deviations from it are the niche. You may even have large player base models that shard on top of using this design, but the original premise takes hold, and there are entire generations of young hobbyists who I think probably refuse to believe this in large part because most of them aren't doing sophisticated enough networking to say otherwise, and as soon as they even try, they'll be reinventing the wheel.<p>The nature of multiplayer games forces you to make architectural decisions that will always essentially look like a client-server, server authoritative model.<p>Why? Because you can't allow cheating, and you will always want some degree of prediction. Even if you didn't care about either of these you can simply choose to not opt-into those limitations.<p>But you get too many armchair network experts who have never opened a socket on HN saying that even things like serializing game data is too nuanced. Yeah, OK.<p>I'm sure there are alternative models that do exist, but it's been less than 25 years since that design took hold, and most significant real-time video games have used something exactly like it or similar.<p>Even RuneScape had serialized game event RPC that was reverse engineered over many years. Every game has something like that. You will always need to at least serialize something.
The first thing I demand to know about any software dependency that is competing for my attention is what programming languages it supports. If I don't see that on the first page, you've failed to provide a reason to look at the second one.<p>There's no point wasting time getting excited about your brilliant new product if I can't quickly verify that it will fit into the tech stack I'm operating in.
I find it interesting that I keep seeing these document-driven approaches to game development. You can also see this in some of the more advanced online DnD engines out there. Documents and update streams are simple but super powerful. I think Firebase is also similar?<p>What's not explained is how a real-time game would handle prediction and latency. On the local network the Among Us clone is probably alright, but could have both input lag and unusual movement with any latency. From what I can tell there's an onTick that is moving the players on the server, but no local prediction or synchronization that usually makes these run well. Maybe I'm overthinking things -- most TVs have 50ms~ delays on standard settings and we adapt. This could have less.
Just a note - the "Getting started" button on <a href="https://hathora.dev/" rel="nofollow">https://hathora.dev/</a> does not seem to do anything for me.
Related:<p><i>Show HN: Hathora – Multiplayer Game Development Made Easy</i> - <a href="https://news.ycombinator.com/item?id=30442072" rel="nofollow">https://news.ycombinator.com/item?id=30442072</a> - Feb 2022 (35 comments)