-World (can be anything from a chessboard to a first person map)
-Objects (anything that is just subject to physics, such as bullets and vehicles)
-Agents (this can be either a human player input directly into the computer, or over the net, or a computer AI player)
-Graphics (really just an 'Agent' that only observes)
Kinda, sorta, not really .
World and objects are usually just data. They're stored in memory and don't take up CPU time.
Physics is generally on a separate thread(s), as it is CPU/GPU intensive.
In a game, input and graphics are deeply divided: On the motherboard the graphics is done on the GPU, which is generally on the northbridge and uses a huge amount of bandwidth, while the input generally goes through the southbridge and generally doesn't need much bandwidth. Usually it's good to have graphics on a separate thread.
With proper API's it should even be quite easy to configure a game at startup to however many cores are available (up to a maximum defined by the agents and objects).
This is true - you can generally detect how many cores/CPUs you have on a system, and using that info decide how many threads you want.
The problem with action games I see is that the objects really need to speak to each other at the register level, or at the very least the cache.
Or maybe it's time to re-think object level interaction. GPUs are moving towards having physics support, and nVidia now has physics APIs (thanks to their recent purchase of PhysX), which means they can take care of object interaction, and you don't have to. You just take care of the logic part if you want your game to do something interesting when certain objects interact. That can generally be done in a single thread separate from the physics.
Even then, a lot of online games, it seems the network traffic has to be blocking, i.e. the game does need to lag if the network packets lag.
Actually, one of the great things about multithreading is that you can turn blocking calls into non-blocking calls by performing the blocking call in a separate thread . I just did that for a recent homework assignment .
The thing with games is trying to figure out how objects are moving around and interacting while you're experiencing the lag. You can extrapolate movement a bit, but you have no idea what the other player is doing until you start receiving from that player again. And once you start receiving packets again, now you have to sync the game.
Most games take one of two paths: Either they simply "pause" the game when packets aren't received (just let it block), or if the game is using client/server the server decides what the current state of the game is (sync with the server when packets start flowing again).