I was thinking about making multiplayer version of a game I am making with SDL and OpenGL. It would be a split-screen game.

Do you think it would be a good idea to have each part of the screen (game session) handled by different thread? Those threads would have no data to share except for pause and game over/victory events. Since the single player version is already written, I thought I could save a lot of development time by implementing it this way.


migrated from stackoverflow.com Aug 10 '12 at 15:40

This question came from our site for professional and enthusiast programmers.

  • \$\begingroup\$ I've flagged the gamedev mods to see if this question would work better on their site. \$\endgroup\$ – Kev Aug 9 '12 at 23:35
  • \$\begingroup\$ What do you mean by they don't share data? Are the players playing individual game? Like TrackMania? \$\endgroup\$ – kravemir Aug 11 '12 at 14:51
  • \$\begingroup\$ It's separate games of Tetris \$\endgroup\$ – Sunius Aug 12 '12 at 1:05
  • \$\begingroup\$ @Sunius: That doesn't fully answer the question though. Are they just racing each other for points, or do their actions affect the other players in some way? \$\endgroup\$ – Nicol Bolas Aug 13 '12 at 17:50

Do you think it would be a good idea to have each part of the screen (game session) handled by different thread?

When it comes to rendering: No!

OpenGL and multithreading don't mix well. It's best practice to keep all OpenGL operations to one single thread.

  • \$\begingroup\$ Mind elaborating what exactly doesn't mix well? \$\endgroup\$ – Sunius Aug 10 '12 at 9:49
  • 1
    \$\begingroup\$ Things that involve GUI tends to have thread affinity. Windows on Windows belong to particular threads, and so does the immediate context (D3D11). Legacy GL also had affinity, unsure about current-day. I'd suggest a solution that gathers input and draws things in the main GUI thread, and would simulate the game instances in separate threads or in sequence, synchronizing over whole frame states to use for rendering. \$\endgroup\$ – Lars Viklund Aug 10 '12 at 16:09
  • \$\begingroup\$ Yes, OpenGL rendering and multithreading don't mix well, but that doesn't mean that game logic can't be processed by different threads!!! \$\endgroup\$ – kravemir Aug 11 '12 at 18:57
  • \$\begingroup\$ @Miro: True. But it's Tetris; you can probably run 50+ on one thread at 30fps on a decent CPU. While writing in a scripting language. \$\endgroup\$ – Nicol Bolas Aug 13 '12 at 17:51

I thought I could save a lot of development time by implementing it this way.

If the single thread solution fits your needs in terms of performance, I'm pretty sure that using more than one thread will not save you development time.

If you come to conclusion that you need multithreading, consider making a thread pool. Here's a good discussion on multithreading in games.

You may also be interested in http://gamedev.stackexchange.com as this question is clearly related to game development.

  • \$\begingroup\$ So it would work if I place render requests in the queue for the main thread to render while doing all the other game logic in separate threads? \$\endgroup\$ – Sunius Aug 10 '12 at 9:51
  • 1
    \$\begingroup\$ @Sunius First, ask yourself a question if you really have to involve more than one thread in your game. It's always easier to work with just one thread. As for mth'ed games: Rendering, game logic and everything that is needed to show a single frame on screen should be divided into independent tasks and pushed to single job queue. Worker threads then are created to pull tasks from the queue and perform them in parallel manner. Although, it's a bit more complicated than it sounds. I suggest you have some advanced reading about multithreading in games, gamedev.se is a very good place to start. \$\endgroup\$ – Patryk Czachurski Aug 10 '12 at 10:58
  • \$\begingroup\$ I thought about it, and I think it's not really necessary, but it would be useful. How I have it set up at the moment is create game world object with constructor of screen coordinates, and execute the "play" function, which first of all does logic, then takes input and finally renders the screen at the position specified. I thought if I could create 4 threads and in each launch a different game world, that would simplify the multiplayer part and since the games are independent, it would not slow down because there is no data to share. \$\endgroup\$ – Sunius Aug 10 '12 at 15:54
  • 1
    \$\begingroup\$ Multi threading doesn't simplify anything. In your case, a single thread with four world objects would work. Or a single world instance with four "subspaces". If this is a competitive game, you want to keep the update loops synchronized for each player so that one doesn't end up with an unfair advantage due to timing differences. There will also surely be parts of your game where the players share a screen, like main menus, credits, pause, etc. drop the threading idea. \$\endgroup\$ – Sean Middleditch Aug 10 '12 at 15:58

No, you shouldn't.

There simply is no reason why you would want threads. Threads have two use-cases: performance and asynchronity. The performance isn't a problem and there is no reason to do it asynchronous.

Threads aren't to be taken lightly and don't simplify anything.

Splitscreen multiplayer only requires you to code a few things: a camera for each player, input managment for each player and On-Screen-Effects for each player seperate. Also the AI or other gameplay elements need to be aware that there are multiple players. This is trivial in comparison to what it would take to write a threaded solution.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.