I'm making a multiplayer ascii game and want the networking to be as simple as possible (going for production speed on this one). I'm wondering how scalable tcp,lock step, peer to peer networking would be. How many players could I get working like this. WC3 did lock step and supported 10 people over the net so I'm thinking I can do at least that on LAN. Everything will be determinant except the players so my update packets will be small. However I'm guessing this will only work on LAN because going over the net would be too much work. Thanks for any info!
[Edited by - M4573R on September 15, 2010 1:47:14 PM]
How scalable is lock step peer to peer
Yes, lockstep can have bottleneck issues, but it depends on what you are doing.
Two questions are critical:
First, what is your time step? Every frame? x steps per second? y seconds per step? The tighter the loop, the worse it will scale.
Second, what is your node connectivity? P2P full mesh? P2P partial mesh? Does your matchmaker structure the system for maximum connectivity, or is it unstructured?
Lockstep for each frame will be very slow. Even the real-world latency between two machines may be too great for those who use high-refresh monitors. Any P2P hops will put it over the top.
Lockstep for something updating every 250ms (quarter second) may be viable. If machines are interconnected as a nearly fully-connected mesh or have degraded toward a star topology, you may be okay. In those configurations where everything is reachable within 2-3 hops you've still got plenty of room for latency. But a loosely connected mesh (tending toward a ring or line) will likely have too many hops as you add nodes.
Lockstep for something every second or more would not be much of an issue, unless your P2P mesh is a line or ring rather than an interconnected mesh.
Two questions are critical:
First, what is your time step? Every frame? x steps per second? y seconds per step? The tighter the loop, the worse it will scale.
Second, what is your node connectivity? P2P full mesh? P2P partial mesh? Does your matchmaker structure the system for maximum connectivity, or is it unstructured?
Lockstep for each frame will be very slow. Even the real-world latency between two machines may be too great for those who use high-refresh monitors. Any P2P hops will put it over the top.
Lockstep for something updating every 250ms (quarter second) may be viable. If machines are interconnected as a nearly fully-connected mesh or have degraded toward a star topology, you may be okay. In those configurations where everything is reachable within 2-3 hops you've still got plenty of room for latency. But a loosely connected mesh (tending toward a ring or line) will likely have too many hops as you add nodes.
Lockstep for something every second or more would not be much of an issue, unless your P2P mesh is a line or ring rather than an interconnected mesh.
The least scalable part of your suggestion is "peer-to-peer." Most RTS games that use lock-step simulation use a server of some sort; everybody sends commands to the server for some future step; the server collates commands and forwards to everyone; everone executes the commands. The "server" is generally the user that is hosting the game. True peer-to-peer causes N-squared connections, which scales very poorly, and uses more upstream bandwidth than necessary.
The second least scalable part is the "lock-step" bit. The reason is that, for a simulation to truly be lock-step, you need to have all the information that is needed to make a decision, when you make that decision. That usually devolves to needing all the game state for all the players. This means that, when you have 100 players on a map, each client needs to have the full game state for all players. (The reason ends up being long-range affects, such as sniper rifles, missiles, radar, etc, based on game mechanics)
Still, an input-synchronous networking model is almost always more efficient than a state-spamming model. You can be input-synchronous without being lock-step, if you accept that users will get corrections now and then in the cases where their input was sent based on a world view that had gotten invalidated. (Say, you hadn't yet heard about the event that someone far away sniped you, so you couldn't really pick up the weapon from the ground)
The second least scalable part is the "lock-step" bit. The reason is that, for a simulation to truly be lock-step, you need to have all the information that is needed to make a decision, when you make that decision. That usually devolves to needing all the game state for all the players. This means that, when you have 100 players on a map, each client needs to have the full game state for all players. (The reason ends up being long-range affects, such as sniper rifles, missiles, radar, etc, based on game mechanics)
Still, an input-synchronous networking model is almost always more efficient than a state-spamming model. You can be input-synchronous without being lock-step, if you accept that users will get corrections now and then in the cases where their input was sent based on a world view that had gotten invalidated. (Say, you hadn't yet heard about the event that someone far away sniped you, so you couldn't really pick up the weapon from the ground)
Author
The reason for the lock step is the nature of ascii games. Movement will be very coarse and I want the players to be completely synchronous. Consoles windows are limited to 30fps refresh rate I think, but I imagine that could even be reduced to 15 with no problems. Storing state across all machines is fine, it just means the game code won't differ much when playing in networked mode. (Speed is certainly not an issue :D in a text based game) I'm trying to go for simplicity and ease. As far as the network goes, it will be a home network with just a router and 3-4 computers. It sounds like internet is totally out of the question. I was curious though how far this could be pushed if I felt adventurous. If 3-4 is the max, then that's fine, the game isn't suppose to be complicated.
Why is internet out of the question? There are "nethack servers" you can telnet into to play NetHack. You just have to accept whatever the latency is.
The main question is what you do when one of the players hasn't issued a command yet, and the "turn tick" comes. Do you count that as a "pass"?
The main question is what you do when one of the players hasn't issued a command yet, and the "turn tick" comes. Do you count that as a "pass"?
Author
If a command hasn't come in yet, and I count it as a pass, then what happens to the client that sent the command? If he moves, he'll be out of sync, but how does he know not to move? Something could happen like in wc3 where the game pauses everyone until they've caught up.
Clients only execute commands as they come back from the server. Hence, there is latency.
The "yes, sir!" acknowledgment animation in your typical RTS is there to hide that latency.
The "yes, sir!" acknowledgment animation in your typical RTS is there to hide that latency.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
