Yes, we can pretty much do whatever we want with the terrain, and adding weapon deformation of the terrain would be rather easy... for single player. However, there is no synchronization of the terrain data between clients at the moment, so it would break the current multiplayer code. Should not be incredibly difficult to add, but it would no doubt open a can of bugs, and we have too many other, more important issues to deal with right now...cruise wrote: Can't you already adjust the heightfields of the map in debug mode or something? What sort of issues with pathing would that generate doing it on the fly with a weapon hit?
Just Interesting Question.
Re: Just Interesting Question.
"Make a man a fire, you keep him warm for a day. Set a man on fire, you keep him warm for the rest of his life."
Re: Just Interesting Question.
Makes sense - why would you sync the terrain when it isn't changing?
How accurate is the positioning one stuff like explosions between clients? ie. does a client know:
1) this weapon impacted this location
or
2) this unit took this damage & draw this f/x here?
Or perhaps something in between?
If it's the first, then each client should be able to work it out, assuming the effect is done deterministically, without having to send any data across the network.
And yes, I agree other stuff comes first, just figure I'd ask
How accurate is the positioning one stuff like explosions between clients? ie. does a client know:
1) this weapon impacted this location
or
2) this unit took this damage & draw this f/x here?
Or perhaps something in between?
If it's the first, then each client should be able to work it out, assuming the effect is done deterministically, without having to send any data across the network.
And yes, I agree other stuff comes first, just figure I'd ask
[ cruise / casual-tempest.net / transference.org ]
Re: Just Interesting Question.
if the answer to cruise' last question is "no", and "hand holding" is needed, then here's an idea for standardization of transfer of map data (protocol/code simplicity):
since almost all conceivable terrain deformations will affect at least four tiles (at least 9 points), it would be optimal to send them as a rectangular mesh instead of sending one packet per point. maps could also be completely transmitted this way if we aim for more client/server separation, since map data like unit starting positions and gateways would be completely useless.
server notifies the client with something like the following when terrain has deformed (obviously this would be implemented via a binary protocol):
x1, x2, y1, and y2 are bounding coordinates for the rectangular mesh
if the client already has that data, such as in the case of a map file, or has been given that data, and the checksum of the local data matches the server's checksum, then the client doesn't need the data. the checksum cannot be of a whole file, as in the case of map files, but only of the terrain height and type data contained inside. regardless of the value of IS_COMPRESSED, the checksum will apply only to the uncompressed form of that data.
if the client needs the data, the server would send:
where height0 is the height of the point at (x1, y1), height1 is the height of the point at (x2, y1), and heightN is the height of the point at (x2, y2). type0 is an integer id of the terrain type for the tile bounded by (x1, y1) and (x2, y2), type1 is the tile bounded by (x2, y1) and (x3, y1). for both height and type values, values should be sent to the client ordered by row. DATALEN isn't really useful unless compressed -- if not compressed, it can be set to 0. there should always be more height data than type data.
when a client joins a game, the server should send the original map as a deformation notification (client could then download the full map if need be). maps could be cached with the checksum as the filename -- if a file by that name exists, verify the checksum and load. after receiving or loading the initial map data, if we allow games to be joined while in progress for any reason (either a player or spectator), the server then would send each changed area as a seperate notification.
since almost all conceivable terrain deformations will affect at least four tiles (at least 9 points), it would be optimal to send them as a rectangular mesh instead of sending one packet per point. maps could also be completely transmitted this way if we aim for more client/server separation, since map data like unit starting positions and gateways would be completely useless.
server notifies the client with something like the following when terrain has deformed (obviously this would be implemented via a binary protocol):
Code: Select all
TERRAIN_MESH IS_COMPRESSED CHECKSUM x1 y1 x2 y2
if the client already has that data, such as in the case of a map file, or has been given that data, and the checksum of the local data matches the server's checksum, then the client doesn't need the data. the checksum cannot be of a whole file, as in the case of map files, but only of the terrain height and type data contained inside. regardless of the value of IS_COMPRESSED, the checksum will apply only to the uncompressed form of that data.
if the client needs the data, the server would send:
Code: Select all
DATALEN
height0 height1 ...heightN
type0 type1 ...typeM
when a client joins a game, the server should send the original map as a deformation notification (client could then download the full map if need be). maps could be cached with the checksum as the filename -- if a file by that name exists, verify the checksum and load. after receiving or loading the initial map data, if we allow games to be joined while in progress for any reason (either a player or spectator), the server then would send each changed area as a seperate notification.