All right, I am actually going to be attempting to include multiplayer.
The initial networking attempt had the server running the simulation and sending clients data about specific entities which had changed each tick. I did end up successfully implementing an initial version of this for Conway's Game of Life like I said in the last post, but it just strikes me as a nightmare for a number of reasons.
For starters, your game design is now constrained by bandwidth, because you're streaming data about the state of your simulation to each client. You also cannot actually wait to get this data from the server, you need to show the player something immediately otherwise they're going to see an unacceptable delay with every action. So now you're having to decide what gets simulated on the server and what gets simulated on the client, and often times it's both. It's just really hard to keep all the data in sync like this, I'm thinking there'd be at least three states which would need to be synced at any given time (server state, client state, and then rendering state built from that data). I also don't see a great way to go about this in a generic way -- It seems like no matter how I'd go about writing the code, networking is something that would need to be on my mind, and it's just not something I want to think about.
So I'm going to be trying lockstep networking, where each client simulates the game on their local machine, sending the inputs to the server which then forwards those inputs to the clients. This has its own set of problems (writing cross platform deterministic code, or in other words having repeatable simulations, is not trivial), but it has the advantage of vastly simplifying the amount of required network code. It can be made pretty generic, so I can write the network layer once and then not have to think about it anymore. Bandwidth shouldn't be a concern because the amount of data required per packet is small. It also actually maps well with the way the current projects are built, so porting it over becomes much more straight forward.
The main downside here, other than cross platform deterministic code being a pain to write, is that this opens you up to hackers. If everything is being simulated on the server and you're only being sent the relevant data to draw your frames (as in the original method), then there is no opportunity for the player to do something like map hack, because that data doesn't reside on their machine. I figure having this type of thing be possible is better than having no multiplayer at all, plus if I'm at the point where someone has bothered to write a hack for one of my projects, then the game is probably reasonably popular and I've already won.
I have a lockstep networking implementation working for Conway's Game of Life, but it's missing a few things that an actual game would need. I need to add some relatively easy things client names, calculating ping, and client-side prediction where if someone is holding down the key that makes them move left, the client should assume that the key continues to be held down until it is told otherwise from the server. I also need to implement rollback networking, so if the client does not hear from the server, it continues stepping the simulation but stores all data for the tick which it knows is in sync with the server. When the client next hears from the server it does a check of the inputs compared to the inputs it played out in the simulation, and if there is a mismatch it needs to revert the game state to the last state in sync and then update the state with the proper inputs until it is up to date.
That last one is what I am working on now. Definitely doable but it makes me slightly sad thinking about the ways in which I could mess this up.
