What if you were paid?
I get paid a bit too much to switch jobs. Plus, this is what passes for me for a hobby. I've thought a lot about MMO design, and while I code like a gibbon trying to hit the right key that releases the banana snack, my design skills are better than average (maybe four standard deviations better than average, to be honest). Its an interesting mental exercise to apply them to something real. Honestly though if you wanted to pay someone to implement an MMO you'd actually be able to play before the Apocalypse, someone like Codewalker would probably be ten times faster than me.
The truth is players always think they know what's going on in their games and how they would make them better, and even in these threads a lot of people have commented on how easy it would be to do certain tasks. But there's a huge difference between thinking and doing. Until you've done it, you really don't know what you're talking about. As recently as a week ago I didn't really think I had the time to even start an exercise like this, but this weekend I was thinking about it and decided even if for five minutes a day I'd see where my design notions go.
If I was trying to make a game for others to play, I'd start with a framework. But I want to think about the systems from the ground up. That's why I stopped where I did. Seems silly to stop at a server that does nothing and a client that does almost nothing, but actually two feet out of the starting gate I've hit my first design nexus. I'm leaning towards UDP, which means I have more control over how reliability and flow control work, but that also means I have to consider packet loss. I could build guaranteed delivery on top of UDP, but that almost defeats the purpose of going UDP. Drop detection and state recovery make more sense, but that then interacts with the design choice to run an input state engine for each client server-side or client-side. Server-side state engines mean drop recovery will interact weirdly with client-side prediction, if I decide to implement prediction. Client-side state engines make more sense for prediction and reduce server-side load, but they also mean more network traffic.
All of this would be easy enough to resolve, if it wasn't for the fact that they interact with time, and how the client and the server will track time. Which means I need to think about time and how I want to design clocking, before I implement the networking system I want to work with that kind of clocking, which is important to how I design the protocols for client-side event messaging. It all has to fit together. In some ways I think CoH is much better at this than most players realize. But in other areas, I think I could do better. But until you actually try, its all speculation. And because I want to think this through, I'm not referencing how other games do this as much as possible (which is to say, I know what I know, but I want to find original solutions to these problems and not copy pre-existing solutions).
All of this really comes down to synchronization, and how asynchronously can a game run and still pretend to be synchronous. And that's probably something that takes experience to really know. Which means guessing, and implementing something that can evolve from that first probably wild guess. The interesting design problem to me is how to make a modular scheduler that isn't welded to the rest of the world server event handlers, if that's even possible.
Yes, this is in fact what passes for a semi-casual mental exercise for me. In my professional life, I've been thinking about what it would take to completely reimplement VMware Horizon from scratch. Because that thing was written by baboons. Who relies on ADRS? It falls out of sync whenever you breathe hard around it. There's no task manager at all. The object database is always generating orphans. Its impossible to make multi-tenant. Pools keep losing their snapshot state. Every time I have to reboot every single connection server because of a sync failure that causes them to kill off their server listeners I want to punch something. Compared to that, this is all just for fun.
