   How Different Genres Do It?
  I recently started learning how to code network stuff.  So far, I've made a chat program, styled like an old 70s computer program or something (it's fun to play with :-D), and I'm currently working on an artillery game.  For the artillery game, I'm using a lock-step system, and keeping all important gameplay stuff deterministic.  I've pretty much finished the networking side of this game, so I feel I've learned some things.  (And before anyone asks, the reason I'm doing this game the way that I am is because the terrain system in the game is comprised of many thousands of particles, so I can't send all of that across the network!)Anyway, from what I've been reading, there are two main categories of networking for games: what I'm doing, and the "send everyone all the information quickly and unreliably and just handle it properly" method.  Is this correct?And now the meat of my question: I am really interested in reading about how other games have done this.  Specifically, I'm interested in how the different genres generally do things.  For instance, from my reading, it sounds like every RTS uses a lock-step setup.  FPS's use the pump-events setup (is there an official term for this?).  What do action RPG's like Diablo use?   
  You might find this article on Quake 3 networking useful.RTS games generally use lock-step because of the volume of information (much like your artillery game) due to the large number of units and their interactions. Also, late joining (which is hard to implement in lockstep) isn't usually required in an RTS game, but it's much more important for a FPS game.Most other genres will use something along the lines of the Q3 article, usually because late-joining is required, and because lockstep doesn't tend to scale very well when you get above four players. There are lots of variations within this though, usually depending on how much or little each client actually simulates and how much it relies on the master server telling it. A common tweek is to calculate the user's movement and physics locally (so they feel nice and responsive).   ;  I imagine that many RPGs use a "desired position" setup, where they draw remote players at some time lag, moving towards the last known position of the entity. That is, they send entity position updates, but less often than Quake, and they display entities with delay, so that they don't have to forward extrapolate.Btw: the Forum FAQ has some more links, including the link to the Quake 3 article.;  Thanks for the replies, guys.  It sounds like I had the right basic idea, in thinking that there are two major, general ways of doing it.  Once I'm done with this artillery game, I'd like to start playing around with an idea for a Diablo-clone I've had.  I've been thinking it through, and I think I can make it work pretty well using something close to the Q3 method (well, just close to the "send lots of updates all the time and screw what order they are in" method)   