Hi
Im trying to make a realtime action game where you control an aircraft, fly and shoot and create units on the ground. So my idea is as following for the networking (up to 6 players)
1. At start of a match all clients sync their gametime so each one has the same.
2. When a player wants to do something, like firing a bullet or turn the airplane a command is sent to server with timestamp (currentTime+200ms). Servers sends this command to each client
3. Each client has a list with cued commands and constantly checks if any of these has hit its execution time: when they do that command is being carried out. This means each client will execute the same command at the same time.
For some questions:
a. What happens if some client recieves a command later for some reason so that command has to be executed after the correct time? In that case that clients world will start to differ from the rests...
b. How do i set a good "delay" (200ms was used as an example above)
c. If timing is important, like in counterstrike, such a delay is not very comfortable for the player. Any other good way to handle realtime action stuff?
d. Is it a good idea to babysit some important events like units being destroyed/ hit by projectiles? (let server alone monitor such events and broadcast to all) To avoid more severe desyncronization?
Thanks a lot (I use raknet and c++ by the way)
Erik
Realtime basics
a. What happens if some client recieves a command later for some reason so that command has to be executed after the correct time? In that case that clients world will start to differ from the rests...Either -- all players update in "lock step", where if one player gets behind, all other players pause to allow them to catch up (this is common in strategy games - see "1500 archers" for a classic example).
Or, that player would need to be able to rewind their game-state, apply the event in the past, then fast-forward back to the current time (this is common in action games).
b. How do i set a good "delay" (200ms was used as an example above)[/quote]In this model, slightly higher than the expected ping of your players.
c. If timing is important, like in counterstrike, such a delay is not very comfortable for the player. Any other good way to handle realtime action stuff?[/quote]Everything you wanted to know about counter-strike's networking.d. Is it a good idea to babysit some important events like units being destroyed/ hit by projectiles? (let server alone monitor such events and broadcast to all) To avoid more severe desyncronization?[/quote]The client/server paradigm can be very good for preventing cheating -- in this model the server alone would monitor pretty much everything, and broadcast to all.
Another way you can handle laggy information, is instead of insist that all clients start everything at exactly the same time and then increment objects position every frame by their velocity, send a starting position, starting time, and velocity for each object, then the update loop would just multiply the velocity time the current time minus the start time, so even if you get the info on that object late, it will still show up in the correct place when it does show up. The other advantage of moving object this way is that it's framerate independent.
The other advantage of moving object this way is that it's framerate independent.
Your simulation frame rate should be independent of your display frame rate anyway.
Yes, but if you send the client info on objects in terms of start position, start time, velocity, and acceleration (or in the case of planetary objects, start position, thing they orbit, and orbit speed), then you don't even need to have the clients use the same simulation rate. At least that's how we do it in our game.
Author
But will not this delay (lets say 150 or 200 ms) feel sloppy in a game where triggering shots is at least relativly time-dependant?
E
E
I think it depends on your game. If you were going to be talking about launching missiles, for example, then you could make the missile take half a second or more to "arm" before actually firing, which could soak up a lot of the lag you might encounter. Players would get used to that arming time and time their shots accordingly.
In my game, we don't send a message for each bullet fired, we send messages for "start firing" and "stop firing" including the rate of fire, so while you may perceive some lag for when the firing starts, everything is synced up pretty perfectly after that. I think the key is to figure out exactly how you want your game to play, and then pick the best networking scheme to fit that. The more twitchy your game is, the more involved the networking will have to be, I think.
In my game, we don't send a message for each bullet fired, we send messages for "start firing" and "stop firing" including the rate of fire, so while you may perceive some lag for when the firing starts, everything is synced up pretty perfectly after that. I think the key is to figure out exactly how you want your game to play, and then pick the best networking scheme to fit that. The more twitchy your game is, the more involved the networking will have to be, I think.
The more twitchy your game is, the more involved the networking will have to be, I think.
The advise "pick networking scheme based on game genre" is very good! However, twitch games don't need to be very involved, networking wise -- but they do tend to limit the number of players that can interact in any one arena. This is why a 128-player FPS server is so rare, for example.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
