4
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ I've flagged the gamedev mods to see if this question would work better on their site. \$\endgroup\$
    – Kev
    Aug 9, 2012 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, 2012 at 14:51
  • \$\begingroup\$ It's separate games of Tetris \$\endgroup\$
    – Sunius
    Aug 12, 2012 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, 2012 at 17:50

3 Answers 3

Reset to default
8
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ Mind elaborating what exactly doesn't mix well? \$\endgroup\$
    – Sunius
    Aug 10, 2012 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, 2012 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, 2012 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, 2012 at 17:51
2
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\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, 2012 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\$
    – Pythagoras of Samos
    Aug 10, 2012 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, 2012 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, 2012 at 15:58
2
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .