distributed dynamic terrain modelling

Started by
1 comment, last by khanage 20 years, 8 months ago
Hey Folks, I''m working on project that deals with distributed dynamic terrain modelling in games. In simple terms, say you have a multiplayer game and there is a change in environment in one players screen (for example blowing a hole in the ground, creating tracks when tanks move over soil), you have to distribute this event dynamically to other players so that when they are in the same vacinity they see the change as well. I''d like to ask if anyone knows or has references of how to do this and how to encapsulate these changes over a network. What i''m thinking is Objects (entities) in the environment and their attributes(flags) are stored into a terrain database. When a change occurs, the appropriate the flags are broadcasted and changed on other players databases and it calls a rendering module to display the changes. I''m not sure how to game encapsulate this info over a network. Hope someone can help, Thanks, Khanage
Advertisement
I''d use enumerated message type codes, to determine whether you are adding something, modifying the state of something, etc.

Each message type would be followed by parameters, depending on the type. Parameters like object''s ID, state, orientation, position, etc.

Server-based: send message to server who routes it to opponents.
Peer-based: send same message to each peer or use a tree or ring topology to relay messages to the peers.

That''s what I''d do... not sure it that is the "right answer" though.
-solo (my site)
I think that most of the effects you have described are generated as a result of something else happening. In most cases you just broadcast the causal event and let the client generate the effect that comes from it. So when a tank moves, your network system (client or server) notifies the client that Tank A has moved to Location B and the client renders tracks along the appropriate vector on the terrain. This should cut down alot on your server load and on your bandwidth requirements.

The only drawback is that people may hack the client to prevent tire tracks or holes in the terrain. However, removing tire tracks on the client side isn''t beneficial (in fact, it might hide a critical clue that enemies are around) to the client (except for performance reasons) and denying the presence of a hole won''t fly if the server validates all movement that would be disallowed by a large hole.

So I would say just broadcast the causal events and let the clients do the modeling that comes from them. You don''t want to be sending a packet that says "put a hole that is 3x3 at coordinate x". Instead, you want to say "a bomb of magnitude 10 has been dropped on coordinate x" so that the client can generate the appropriate explosion effect and a large hole. Meanwhile, the server also generates the hole in the appropriate location and validates any movement through that location (slows the units down or disallows movement over a road that no longer exists). That way if the client missed the bomb packet or was hacked to prevent the hole, it still doesn''t get away with anything.

Sending a heightmap or newly generated terrain texture to all your clients would not be a good thing to do in real time.

This topic is closed to new replies.

Advertisement