I would like to get information on this too. As long as it does not get to technical.

I'm not a games developer, I'm a real time embedded and also C# developer.

Conceptually though if I was to design a game there are a few ways I could take advantage of multi core processors.

Like you say 1 way is for the AI to be continually assessing it's situation and updating behaviours in a background thread.  This could potentially be more than 1 thread.  An imediate or combat AI for enemies in the vicinity who would have more advanced senses and behavour, then other threads could handle world level AI.  Depending on the game you could add even more realism and complexity by giving each enemy it's own thread although it would be some task to make the AI work together.  In a game such as Sins each AI could have their own thread.

In a roaming level environment I could use a thread that handles the loading and freeing of assets as the player moves around a level.

Any large algorithms to do with physics, line of sight, pathing etc could belong in their own thread but this is all stuff that needs to be synchronised so while you are taking advantage of multi core systems you are adding inefficiency to your processing, large complexity to the design and non multi core systems would suffer.

Like I said, I'm not a games developer but I can't really see how keep adding cores to the processor really helps games a great deal.  To take advantage of all the extra power is going to up development costs a LOT.  It ups your potential but it's not like the good old days of processors just getting faster.

The question should not be 'what can we do with the extra cores' but 'how much benefit can we get from it, for the effort it takes'.

As mentioned before, making multithreaded software safe/stable is hard, and it takes a lot of extra work to make it work. The more threads the more problems.

GPU's are sort of multi-core in their set-up but it doesn't require much special work from the developer to make use if that because it is dealt with by the driver. The best way to get multi-core usage used widely is to create drivers that process general code in parallel. This puts the effort on the hardware designer, and frees up the resources for the game developer.

I think Intel is going down that path with their next GPU.

Source, the engine behind Valve's games, is multithreaded, and I believe they have some articles about it.

There are a couple major ways to break it down:

• Place large systems such as the game loop, sound, graphics, physics, etc in separate threads. The disadvantage is that some systems may take up a large portion of a core and use full advantage of the core, while others don't. This makes the load on the cores uneven and is unlikely to take full advantage of all of the cores.
  
• The other way is to divide a single but large computation across multiple cores. This is often done for physics and graphics, as they are very easy to make parallel. This is easier to scale evenly across all cores.

By the way, I'm a student: Computer Science major, hoping to graduate in a year.

Well, I highly recommend going back. The payoff of getting that degree is well worth the costs .

I've done some multithreading - I wrote some threaded code for an open source project, and for one of my homework assignments I'm using threading. The low level stuff can be pretty tough, but increasingly there are more techniques and tools that can used to abstract that away a bit.

You're absolutely right - and you'd be surprised how many applications are heavily threaded, and just how many threads they have!

Thanks Cobra, I wasn't home so I couldn't check out exact figures. But your findings more or less confirm what I expected.

It can be good practice generally to offload certain subsystems into their own thread.  User interfaces for example, so they don't have that sticky feel to them while the program is busy.  Many graphics frameworks handle it that way be default.

But multithreading can be very hard.  It almost always makes things more difficult to debug, and it adds a whole new class of potential errors.  It really depends on your problem.  The first threaded application I wrote had a MessageHandler class which other threads had to register themselves with to get a Queue <Message> postBox which it could get something from whenever it was free.  This turned into a horrible mess of switch-case statements.

On the other end of the spectrum, some problems are just made for it.  If you can design the program so that threads don't need to communicate, it is very simple to get it all working.  A good general strategy is to separate objects into immutable parts which can safely be passed around to all threads, and an instance which is the thread, and in which all dynamic data is generated. Sometimes you get lucky with the task you're solving and can take such an approach, sometimes not.

Supreme Commander is so far the only game I've played where you can really see the benefit of multithreading.  I believe their approach was to use it for unit AI and physics.

I find that with .NET and C#, event-based messageing is a lot easier. At least I didn't break my fingers doing it in my server apps I wrote.

I was taking a Bachelor Honors Degree in Computer Games Development though, and was working heavily in C++. If you have some multi-threading notes I could yoink, PM me

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.

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.

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.

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).

This dataflow model is stressing out the PCIX bus.  Before, you were sending data in real-time to the video card; now you are depending on two-way traffic, and you need a handshake.  Plus, a lot of the high bandwidth on a PCIX line assumes pipelineable data; this would now no longer be true.  Assuming the bus is the bottleneck--and it probably is--that is worse than where we started. OTOH, if the hardware guys integrate a GPU onto the SOC, we may be onto something.  That would be a very innovative and interesting problem to solve--that involves 4 cores and 2 GPU's on a single SOC, sharing a single L1/L2 cache and with some pretty interesting bus arbitration logic.  Not an easy engineering problem.

Right, I understand.  But the problem is, for a lot of online games the network calls *SHOULD* be blocking.  If I swing my sword at a guy, I need to know where the other guy is first.  So threading it would actually be the wrong thing to do.  A good rule of thumb is, if you can use a UDP protocol, thread it.  If you have to have a socket, don't.

Any word on the core usage of the newest Supreme Commander/Demigod engine? I know a dual-core machine is ideal with this technology - if I may diverge momentarily with this query I would be interested to know if GPG/Ironclad have begun tapping a 3rd or 4th core for upcoming products. I`ve got a Q9650 myself. Otherwise continue on folks... 

It's what you do with old PCI, PCI-X, and AGP buses that support half duplex. You send data in large bursts so you're not spending a lot of time with only a few bits of data in a one way pipe.

PCI-E, on the other hand, is full duplex.

. . . and I'm not proposing it. nVidia is doing it already. Their latest upgrade installed PhysX support in their drivers for their DirectX 10 video cards, and they have a whole section of their website dedicated to CUDA.

You're joking, right? My video card has 64 stream processors, and their high end cards have 200+ stream processors. Double or triple that if you're doing SLI. Anything that can be easily be split into parallel tasks will get a boost no CPU can currently match, even with SIMD and even accounting for bus issues.

nVidia has a demo demonstrating their physics as well - a fluid demo that simulates 60000+ particles simultaneously. Something like that can certainly be split into many parallel tasks that can run on their streaming processors.

. . . which the hardware and OS do for you, as far as I know. PCI-E already defines those protocols including the transaction layer, so the person designing the game doesn't have to worry about it.