MMO, server-side line of sight

Question

I am working on a simple tile-based multiplayer game. I am rather experienced programmer, but not so experienced game developer.

The players will see each other depending if there is a blocking object between them or not. The objects can be moved around, so the map is not static.

If A moves (or performs other action) and B sees that (LOS is not blocked) then B client will be notified and will update it's view. If B does not see A, then B will not be notified.

Question:

1. Should I notify client A about B's movement regardless of LOS, perform all the LOS checking on the client-side and update the view accordingly, or...
2. should I do all the LOS server-side and notify client A only in case of visible movement?

I know than, in principle, I should not trust client-side and not send anything to the client that is not necessary (client code can be hacked and show movement out of LOS). But, if there is a significant number of players at once, then I am afraid than the server will not cope with tracking all LOS for all the events and all the players.

How to cope with this problem? Is there some "standard" solution here? I know that it might be a premature optimization (I don't have this problem yet), but protocol and map data structure will depend on that.

P.S.

The client and the server will be open source, so hacking the client will be easy

Answer 1

Do the LOS and AOI (Area Of Interest) filtering on the server. Yes, any data you send the client can be hacked. OR extra programs can be inserted as a proxy between client and server to sniff excess data, like the old EverQuest viewer that lets players not only see far-away monsters but even what loot they would drop (which is a bit mind-boggling why that was pre-determined, but even with the loot bits it would be bad). It's also excessive bandwidth usage to tell clients about actors they can't possibly see or interact with.

Remember that you might also need some gameplay effects to be dependent on LOS down the road. The server is going to need to know LOS anyway in this case.

The server should be able to easily cope with calculating LOS for many players. First, you can use spatial partitioning and node graphs to quickly know if a player in node A is ever capable of seeing a player in node B or if the players are so far apart that they can never see each other. The actual LOS calculation can be done on greatly simplified meshes, too, as the server does not need every single triangle used for rendering to figure out LOS for gameplay and network purposes.

You can also move all LOS test into other threads relatively easily as most of the needed data is static (no synchronization needed) and a simple event queue can keep player positions updated between threads with no synchronizaton as well.

One thing to keep in mind is that you might want your LOS to err towards false-positives rather than false-negatives in most cases, especially for networking. If a player is just around a corner and still not visible, you might want to prime the client with some basic information so that there isn't any visibility lag when either play moves around the corner. Or you might want to err on the side of secrecy if ambushes and surprise are important to your gameplay. As always, networking realities are going to limit gameplay possibilities and gameplay is going to drive networking needs; part of the job of the networking engineer is to figure out this balance to the best extent and work with the gameplay engineers to make it work satisfactorily.

In general, especially for an MMO-style game without a lot of heavy shooter action, design towards all smarts being on the server and the client being as close to a dumb terminal as possible. All LOS checks, hit tests, movement, etc. should be server-side. The client might run some of these systems in parallel for prediction and lag-compensation purposes, but nothing the client does should be authoritative and the client should have zero information that the server doesn't explicitly want the player to have.

Answer 2

The best data sent is data not sent. This is basically information the client does not need; this is network bandwidth for useless data, and large-scale network bandwidth is costly.

Also consider that the processing taken up to calculate LOS would be (slightly) offset by not having to process and send all the additional network packets.

Edit: I suppose what I was trying to say was that, despite the added difficulty of handling LOS on the server, and any gameplay-related positives that would add, you should consider than not sending updates to the client for EVERY player/target, but rather only the ones they can perceive, is itself a big savings in bytes transmitted, which in a MMO type game results in lowered operating costs.