fujitsu wrote:Collision detection is client!!?? What collision detection do you mean?
GUI vs Game World. Obviously the server does not know where the windows are (and why should it know?) - so the client must scan what was clicked and when.
Collisions between game objects are obviously server side occurances.
Sorry for being ambigous.
Are you talking kilobytes, or kilobits?
Kilobytes. 80 kbps. Maybe 120 kbps or so.
Whatever you were talking about, we shouldn't need to transfer much data to the client. We simply need to give it details about the vertices, terrain, etc of the tile, and anything that is on the tile, along with an ID for reference with the server.
say we send 20x20 patch (about one screen)
21x21 vertex height * short int = 882 bytes
21x21 vertex data (indexed) * byte = 441 bytes
so you just sent 1 kB of data. Say we compress = with 50% ratio = 600 bytes = 662 bytes. And you didn't even started to send tile info. With 20 snapshots/second you already ate whole bandwidth avalible to you...
This actually gives a reason to give the client access to server data on a local host. To avoid sending millions of vertices we need to give the server and client access to geometry data - and doing that without client access on local machine would double memory requirements.
The client doesn't need all of the data about a tile that a server does, as the client doesn't do pathfinding or anything like that. It doesn't need all of the data about a station, because it will request it if and when it needs it, which it may not need to do very often at all.
Obviously - but as you see - the client at least needs data on geometry - to preserve bandwidth.
Also - the protocol needs to be asynchronous - ie - we send the client only the data that is neede for the viewport to display correctly. But - we need to make sure that we don't send much raw data, but mostly indices (like: train 32 broke, or train 36 moved 1 unit forward)
I also think that the bandwidth could be limited by just transfering what is needed, say by giving no data for a tile that hasn't changed since the last request. This would take the bandwidth down massively, and the client would only need the data for the current viewport.
Hmm - yes - I see we are on the same page
The only problem with this approach (that I can see), comes up when we notice that we really have to have a minimap. This means that the data for all of the tiles is going to have to be transferred to the client. We could always have the server do some of the minimap generation, or we could have a tiny amount of data for each tile retrieved, just enough to display the minimap. Otherwise, opening the minimap would create...............................lag.
Indeed. But we can keep the last minimap the client requested and just send an update to it. A diff would suffice.
I think two apps, or we are going to have problems with having to keep the multi- and single-player code working, and if we have seperate methods for each, we will have to test both multi- and single-player, whereas if we go with the method that has been accepted for most of this topic, we really only have to thoroughly test one method, for the other is effectively the same.
Yes - I also lean toward that solution. The problems however persist with local client and data redundancy.