Quote:Original post by Raduprv
I don't think that's really the case, because the random number generator can not be syncronized on all the machines, due to the fact that it's a deterministic state machine. Not all the clients view the same things (some units are hidden by the fog of war, for example) so then not all the clients do the same calculations at the same time, which results in the random number generator to produce totally different results.

Why couldn't you keep the random number generator in sync. All important data that depends on a random number, will just have to call a random number generator in same order on all machines (So all machines keep track of the entire game state locally), of course each machine will need to use the same seed. Any other random numbers (like smoke particle directions) can be handled by another random numer generator that's unique to each machine.

I can't answer for Warcraft 3 specifically but traditionally RTS games are based on input reflection and deterministic simulation. So, yes, you *can* write fog of war hacks (or find other ways to prevent it, such as "punk buster" or similar software). And you can only see the fogged areas, pathing still won't take the shrouded terrain into account and players won't be able to take direct actions against hidden actors.
It has some advantages too though, for instance such a model makes it impossible even to express an invalid commands (speed/wall hacks).

Input reflection has huge advantages considering that the number of units and their complexity does not affect the bandwidth requirements at all, only the number of players does. Unfortunately it also makes debugging a whole lot harder, and you pretty much have to use fixed point for the simulations.

Here's an old Gamasutra article describing how this technique was implemented in Age of Empires: Clicky

[Edited by - doynax on October 29, 2005 3:14:54 AM]

Quote:Original post by Raduprv
Well, I don't really see a big advantage in this model. Like I was saying, in a RTS the bandwidth is not really an issue unless you have more thanm say... 500 units at the same time. However, this reflection model requires all the units and buildings to be sent, at a point or another to all the clients.

Not unless you join the game late (or have a bug), which is rare to say the least..
Not having to think about limiting the size of the game state or the complexity of your units is not a small advantage.

Quote:Original post by Raduprv
The network model we use for our MMORPG sends only the nearby players, which effectively eliminates a lot of bandwidth.

Even so you can still 'see' all the units on a minimap, and you'll also have a lot more units on screen than in most game types. And the last thing you want is the game starting to lag during a rush attack with hundreds of units on screen (though it'll probably cause other problems instead..).
Additionally I assume that a MMORPG has much higher security requirements too.

Oh, and you get replays virtually for free which is a neat feature in an RTS game, especially if you broadcast them over the network as in WC3.

I mentioned all computers would have to track the game state. So that does open up exploits for fog of war (not a problem in a game with out fog of war). I was thinking with large numbers of units, where sending the state for each unit would use a lot bandwidth relative to sending only each players commands. Not really a problem with only 10 units or even a thousand simple units (with few players). But if you have a fancy physics system where you have you have to track what bits of exploded tank hit a wall and knock chunks out of it, your bandwidth needs get a lot higher.

The important thing is just sending each player commands is constant (or nearly) relative to the game complexity, and linear to the number of players. But you have to design your game so it doesn't get out of sync, or can handle getting out of sync. Which will eat some bandwidth, in the worst case sending the entire game state. Which from what I can tell, your suggestion does all the time.

It's harder (sometimes much harder) to design your engine to keep players in sync. For instance my tank example would be a real pain due to different floating point implementations unsyncing the physics. Could be fixed with fixed point math. Or maybe some kind of priority syncing system. For example the bit that hit a wall and the wall that got hit should be sent to each player keep games in sync. And any extra bandwidth to sync any less important bits.

Quote:Original post by Raduprv

Quote:Original post by doynax

Quote:Original post by Raduprv
Well, I don't really see a big advantage in this model. Like I was saying, in a RTS the bandwidth is not really an issue unless you have more thanm say... 500 units at the same time. However, this reflection model requires all the units and buildings to be sent, at a point or another to all the clients.

Not unless you join the game late (or have a bug), which is rare to say the least..
Not having to think about limiting the size of the game state or the complexity of your units is not a small advantage.

I think you missunderstood me. The clients HAVE to get all the units, weather or not you later join the game. Otherwise no players will see any unit.

Hmm.. Maybe you were talking about the other approach and not input reflection then?
Because there really isn't any need to send a game state, ever, unless you allow players to join late (which is a pretty stupid thing to do in an RTS) or load a networked game (also rare, considering the length of most matches). At least that's the way it worked in our game..
At the beginning of the the few units you have are all placed at predetermined positions. The only things you have to transmit are the game options, map name, etc.

Quote:Original post by Raduprv

Quote:
Oh, and you get replays virtually for free which is a neat feature in an RTS game, especially if you broadcast them over the network as in WC3.

True, but that's not a big issue anyway, it can eb easely done with any networking model.

Yes, but they're small enough to be broadcasted to hundreds of viewers without much networking overhead. When latency isn't an issue you don't have to send dummy packets to acknowledge frames and the packet overhead can be avoided by grouping together and compress multiple frames, making the stream *much* smaller.
And replays on disk would be huge unless you used such an approach (consider 10 kB/s or more for an hour), and unless your networking model forced you to write a deterministic engine anyway most games probably wouldn't bother to implement replays.
It's not exactly a big thing but more of a neat feature though.

I'd be interesting to know how common fog of war and similar hacks are for Warcraft 3..

[Edited by - doynax on October 29, 2005 4:07:18 AM]

Quote:Original post by Raduprv

Quote:Original post by doynax
Hmm.. Maybe you were talking about the other approach and not input reflection then?
Because there really isn't any need to send a game state, ever, unless you allow players to join late (which is a pretty stupid thing to do in an RTS) or load a networked game (also rare, considering the length of most matches). At least that's the way it worked in our game..
At the beginning of the the few units you have are all placed at predetermined positions. The only things you have to transmit are the game options, map name, etc.

In both systems, the units need to be sent, or if not the units themselves, at leas the mouse clicks that create those units (ie. click on the baracks, and click on a grunt).

Yes, but you don't actually send a "create unit command" instead it's all a constant stream of input regardless of what the player is actually doing. So a single packet pretty much only has to contain mouse coordinates and bitmask for the buttons, regardless of what kind of game you're playing.
Thus the amount of units is irrelevant (at least for the networking unit).

Quote:Original post by Raduprv
Besides, if the hashes are different, I guess all the units have to be resent?
Plus, I don't know how many WC3 games you played, but many of them suffer from server split bugs, which are, I believe, exactly this: the clients getting out of sync.

I've only played it casually on LANs myself, so I don't have much experience of the game.
In an ideal world you would have quashed all of these bugs of course. In the real world it should be a rare event.
Doesn't WC3 correct these bugs by resynchronizing and temporarily freezing the game then?

Quote:Original post by Raduprv
As for the replays, with your model you also have to send the map with the reply, becaus the client needs the script and map itself in order to be able to recreate the game.

Or require the player to have the map already, or redirect him to an external server where official maps can be downloaded to save bandwidth. But, yes, you're right.
Additionally you may want to save keyframes every few minutes or so to allow seeking in replays on disk.