Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualScourage

Posted 01 September 2013 - 09:58 AM

Bottom line: introducing multi-threading can cause you to spend a lot of time thinking about and developing things in a way that probably isn't very intuitive. If you don't absolutely need it and know what you're doing need it, then it may be better to spend time on the actual gameplay.

When I wrote my game engine, I needed it to scale with the number of cores, processors and machines. My general approach was to write my game as a set of serial tasks (update, network, physics, audio, render), but allow each step to spread out to use many worker threads when needed. Some of the systems were running their own internal threads and used the serial part to transfer queued messages (network, audio and renderer did this). I was able to show my system scaled almost linearly with the number of cores.

I spent a lot of time developing data structures that allowed for contention free processing without locking. Entity state, spatial data structures, profiling, event management all needed double buffering and special control structures to make things work properly. I spent even more time debugging this stuff.

If you really want to multithreaded your game ill be happy to discuss how I did it in more depth, but if you're on the fence, then you're probably better off not.

Cheers,

Bob

#1Scourage

Posted 01 September 2013 - 09:52 AM

Bottom line: introducing multi-threading can cause you to spend a lot of time thinking about and developing things in a way that probably isn't very intuitive. If you don't absolutely need it and know what you're doing need it, then it may be better to spend time on the actual gameplay.

When I wrote my game engine, I needed it to scale with the number of cores, processors and machines. My general approach was to write my game as a set of serial tasks (update, network, physics, audio, render), but allow each step to spread put to use many worker threads when needed. Some of the systems were running their own internal threads and used the serial part to transfer queued messages (network, audio and renderer did this).

I spent a lot of time developing data structures that allowed for contention free processing without locking. Entity state, spatial data structures, profiling, event management all needed double buffering and special control structures to make things work properly. I spent even more time debugging this stuff.

If you really want to multithreaded your game ill be happy to discuss how I did it in more depth, but if you're on the fence, then you're probably better off not.

Cheers,

Bob

PARTNERS