Project Zomboid #HG

Server-Client

First off the code-base was developed without a server-client architecture. Despite on the face of it, this being the worst way to develop a game intended to be multiplayer, it was a necessary way. A judgement call made because the rate of development of a game with multiplayer from the get-go is much slower. I mean by a factor of 2 or 3, really.

It's not just about adding a feature, it's about adding a feature in both a client, which deals only with the basics of character movement, drawing the graphics, and various other client-side things to optimize from lag, and a server, that deals with the world at large and does all the important stuff that needs to be shared between all players and protected from interference with hacks, results of combat, or zombie positions. Not only that, but allowing them to send efficient messages between the two to keep them both syncronised.

This is a whole extra layer of work required for any feature, and imagine what our unfortunate delays would have been like then.

So being alpha-funded, and requiring as quick progress as possible, it was necessary to condemn ourselves with a really tough job with the multiplayer, for the sake of keeping things moving.

This means the entire concept of the game world is all interconnected between client things and server things, sharing all the same data completely. It will (and has already begun when anything new is being added or when systems have been replaced / updated in our RC3 clean-up operation) need completely reorganizing, splitting into server and client. This will be a long-winded job. Thankfully with the new release system it will not interfere with updates. But this will take a good long while.

Client -> Server consistency

Every decision made that's important to the game will be on the server, but needs transmitting to clients in such a way that all of them remain consistent. If a client manages to get food in their inventory through some weird fluke of timing that the server doesn't know they have, and then they eat it, then either the server has to ignore that food or it could lead to a hunger hack for example. The clients must always stay in sync to the server and obey it's view of reality. Which is tough, because:

Lag prevention

Then this will be the next big hurdle to overcome. We may have 500 zombies in one area. All those zombies are walking about in random directions, colliding with stuff. Either we process this ALL on the server, and send every zombie's position and direction to every client every frame, or we 'predict' the zombies position on the client, and just periodically update when they turn or otherwise do something unexpected. Problem here comes, in moments of high lag we have to make sure that the zombies on the clients aren't further away from the zombies on the servers, making the client player's character get damage from zombies before they've even got to them. This was the big problem in our initial multiplayer (botch) test a long while ago. The more you put on the client, the more those zombies could be modified by a hack to allow the player to gain an advantage. The more it's on the server, the laggier it can be. So this will be a tough one to solve, and again may take some time.

Security

This too, is a big consequence of how we made the game. With such an open modding support, making it easy to modify for the process of hacks. So we have to have server side lua which processes and client side lua that has less power for UI elements and such. Even so, the truth is Zomboid is by its very nature more open to potential hacking (in the sense of ESP style stuff, since the clients NEED to know where characters are if they are close by, and that will undoubtedly be exploitable.

As such...

Servers

We're looking to get some kind of co-op in first, but to be honest that all depends on how the server-client splitting stuff works, and whether having a server that is also the client will be possible (it would of course be possible, but that raises the level the server->client stuff has to be split dramatically and thus will take a lot more time)

However, when it comes to servers, we're obviously going to concentrate on private servers, with options for open to all, or a whitelist to give players control over who is allowed on the server, so suspected wrongdoers can be punished as soon as they are found out. Hopefully this will mitigate the slightly larger threat of hacking.

Finally...

Server performance

Clients will only need to stream in the area surrounding the player. Servers will need to be aware of the area surrounding every player. Often these will overlap, but that still means a huge area of the map will need loading. Unless we reduce the number of zombies dependent on player number, which would be down instead of up, and that makes no sense, then we could have literally 10,000 zombies loaded up. The ideal would be to process these more on the client, but that's leaving ourselves open for big hacks, so some way of handling much more data without silly memory footprint is important. Especially if playing the game on the same machine as the server. Thankfully multi-threading will help here. This is a tough one too though.

So it'll take some time, and also we won't be working solidly on it, as there will still be single-player features being added, and bug fixes and so on.

All that said and done, we thought the streaming system would be a mammoth, gargantuan task. It turned out it wasn't, so who knows if we hit a roll it might go a lot quicker than we expect. But no promises on that, by any stretch.

But come RC3 we'll be on the case.