I am new to game design.

For multithreading, is this the way its done?

class SomeGame

{

   data

   constructor

   threaded methods

}

In the constructor you call the methods to set the application's initial data state and play any intros that you need to and start the threaded methods.

In the data section you create lists for sound effects, songs, game objects, effects, and other game data.

The threaded methods are the individual processes with their own responsibilites. Sounds, Music, File I/O, User Interface, Camera, continuous calculations(like position calculations).

I'm an trying to understand the overall program structure. I know in XNA we have an update method and a draw method. Would it be practicle to spin off threaded methods so that we can have multiple updating methods like explained above? And, can we do away with the update then draw routine and instead spin off draw into its own thread that is either triggered or monitors the game data and renders the new scene as the data is updated?

in XNA for windows, is this possible:

class Game

{

// data

   list: game objects (could be multiple lists for different types)

   list: sound effects

   game time

   music file

   general lighting data

   other game state data...   

// Methods

   initialize method

   thread: dynamic load content

   thread: dynamic unload content

   thread: built-in Update( updates gametime)

               built-in Draw(empty or removed from the game loop)

   thread: user interface reader

   thread: sound effect player

   thread: music player

   thread: camera

   thread: NPC AIs

   thread: draw

   etc.

}

Would this be a good design and is it possible with XNA?

 

James Tyler

 

 

If you are new to game design, you shouldn't bother complicating things with multi-threaded programming.  Only do it if you find you need to (e.g. for performance reasons).  There is really no need for it otherwise.

In general, use separate threads only for things that are really separate and don't need much interacting with the rest of your code. 

The above doesn't seem complicated to me. I was just wondering if that's the way people make the general structure.

There are many, many ways to thread games using modern programming models.  A common way to do it for 2-4 cores is to just write the game to run sequentially.  Once the game works and is functionally complete, identify code that can be executed in parallel with minimal change to the code structure.  For instance, physics is a good candidate.  You can run the game's update/draw cycle in parallel to the physics processing code.  The only requirement here is that you sync the scene update and physics code each Update cycle and buffer the position/orientation of physics actors to prevent race conditions.  Once your game is functionally complete, you'll have a much better idea of what can easily be parallelized.

Now, the above approach does have it's shortcomings.  Namely, it's not scalable at all.  Beyond around four cores you're going to start running out of useful work for additional cores to do, and you'll need to re-architect the engine to be inherently parallel.  This is easier said and done and there is most definitely not a "right" way to do this.  One approach would be to develop the entire engine as a set of independent, atomic tasks.  Then you just schedule the tasks among your available cores.  Of course, this is easier said than done and no-one is going to be able to tell you how to do that efficiently.

I suggest looking at the ThreadPool class. It allows you to put delegates into a queue, and each delegate will be called by some thread. You get to set how many threads the pool uses (I suggest using 3 on the Xbox with XNA). Your job is then to break your game into callbacks where each callback is independent from other callbacks (but can spawn further dependent callbacks), and push the callbacks into the queue.

honestly ... you're making it way too complex by breaking off too many threads.  synchronization is going to kill you :-P  keep it simple, and do only the amount of multithreading that you need to achieve your goal

Tony:

The above doesn't seem complicated to me. I was just wondering if that's the way people make the general structure.

That is because you haven't tried it yet. Trust me, efficient and safe multithreading over multiple threads is probably one of the most difficult aspects of game programming.

if multithreading isn't done the right way, it'll make your program slower. so for now you should just stay with single threaded programs until you absolutely can't optimize it anymore for one core.

ShawMishrak:

There are many, many ways to thread games using modern programming models.  A common way to do it for 2-4 cores is to just write the game to run sequentially.  Once the game works and is functionally complete, identify code that can be executed in parallel with minimal change to the code structure.  For instance, physics is a good candidate.  You can run the game's update/draw cycle in parallel to the physics processing code.  The only requirement here is that you sync the scene update and physics code each Update cycle and buffer the position/orientation of physics actors to prevent race conditions.  Once your game is functionally complete, you'll have a much better idea of what can easily be parallelized.

Now, the above approach does have it's shortcomings.  Namely, it's not scalable at all.  Beyond around four cores you're going to start running out of useful work for additional cores to do, and you'll need to re-architect the engine to be inherently parallel.  This is easier said and done and there is most definitely not a "right" way to do this.  One approach would be to develop the entire engine as a set of independent, atomic tasks.  Then you just schedule the tasks among your available cores.  Of course, this is easier said than done and no-one is going to be able to tell you how to do that efficiently.

Even though it might be common to start by implementing a game using only one thread, it is far from optimal. I would advice the opposite; design for a multi-threaded engine right away, doing it the other way around is one of the most painful task I have ever encountered. Intel has good articles about different approaches for multi-threading design. I know Gamasutra has one rather good one as well.

A quite usual design is to put the renderer in its own thread, for example.

asmo:

Even though it might be common to start by implementing a game using only one thread, it is far from optimal. I would advice the opposite; design for a multi-threaded engine right away, doing it the other way around is one of the most painful task I have ever encountered. Intel has good articles about different approaches for multi-threading design. I know Gamasutra has one rather good one as well.

A quite usual design is to put the renderer in its own thread, for example.

You're right.  There are better ways to go about it, as I mention in the second paragraph, but you need to decide how much time you want to put into it.  If the game is relatively simple and does not perform any complex CPU processing, then multi-threading the entire engine may be a huge waste of time when you could be concentrating on gameplay features.  Multi-threading is not an easy topic, especially without prior experience.  There are many subleties that will expose themselves as weird, inconsistent bugs (if you're lucky!).  Most undergraduate CS programs in the US do not even touch proper multi-threading and parallel programming topics.  The OP mentions that he is new to game design.  To create a functional multi-threaded engine, you need a firm understanding of how game systems work together and how to extract parallelism among them.  That's why I would recommend staying away from parallel programming at the beginning and just concentrating on getting games to work.  Jumping straight into parallel programming (at least with today's programming models) without prior game design experience is like trying to learn to swim in the deep end of the pool.  You lose the ability to take small iterative steps in your designs.  It's much more "all or nothing" than learning game design sequentially and then taking the step to parallelism.

The knowledge learned from creating games and learning what works and what doesn't will be a great boon when it comes time to write a multi-threaded engine.  I cannot stress that enough.  Learn the basics first.  Now if you had said you were somewhat experienced in game design, then I would be more apt to recommend some "better" multi-threading approaches.

jwatte:

I suggest looking at the ThreadPool class. It allows you to put delegates into a queue, and each delegate will be called by some thread. You get to set how many threads the pool uses (I suggest using 3 on the Xbox with XNA). Your job is then to break your game into callbacks where each callback is independent from other callbacks (but can spawn further dependent callbacks), and push the callbacks into the queue.

Was ThreadPool ever "fixed" on the Xbox?  Last I heard, the scheduler used by ThreadPool did not handle load balancing.

I don't know. But I also don't know exactly why you'd need load balancing. The threads can map directly to cores. When a thread completes, it pulls the next task off the work queue, and executes it. It doesn't need to be more complicated than that from a games structure point of view. If the ThreadPool class doesn't actually perform this simple function, then you can write such a class yourself pretty easily.

Now, if you use the ThreadPool for asynchroni