-3

Target Platform: Windows XP high school computers

Libraries Required: SFML, GLEW, ODE, Python (for embedding)

Planned Features that lead me to believe I may need multi-threading:

  1. Up to a hundred robots all interpreting python scripts in real time.
  2. All robots and their components in physical simulation with their environment.
  3. A detailed environment is generated in large sections around the player.
  4. May need to write files to hard drive while the game runs.
  5. (In addition to these features, the target platform worries me)

Do I need multi-threading for this project?

Rasman
  • 5,349
  • 1
  • 25
  • 38
Miles
  • 1,858
  • 1
  • 21
  • 34

2 Answers2

5

Do I need multi-threading for this project?

If your project needs you to perform lot of independent tasks simultaneously then multithreading is an good option.
Note the stress on independent & simultaneously, the base rule is:

More the need of synchronization less is the point of having Multithreading.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
  • 1
    So, I probably shouldn't multi-thread the physics apart from the logic if the physics directly affects the logic? Both would manipulate geometric data, so I could run into problems. Should I separate graphics from logic and physics, as my graphics programming friend suggests? – Miles May 17 '12 at 03:01
  • 2
    @MilesRufat-Latre: Yes, Indeed you should separate graphics from logic and physics, It is always advisable to have loosely coupled modules, it gives you more flexibility.You can use a neat design pattern like [MVC](http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller). Also,if there is a need of lot of synchronization between different tasks being executed in different threads(for ex: need to act on same global data etc) then you should consider reducing these to a minimum, try adhere to the base rule I mentioned above. – Alok Save May 17 '12 at 03:06
  • 1
    Ok. The only thing I don't need to synchronize with everything else is graphics. It may be possible to separate the robot's logic from the game logic. I'll look into it more. Thanks for the advice, this helps alot! EDIT: Darn! It won't let me accept your answer yet! 3 min remaining. – Miles May 17 '12 at 03:07
  • 3
    @MilesRufat-Latre: Do note that just because you need synchronization doesn't mean you should abandon multithreading completely.In any real time system it will be rather hard to have a system which wont need synchronization.There is a delicate balance, IMO there are no fixed rules to decide on that but you get there with practice and experience.Synchronization is like salt, some is always needed but too much of it spoils the soup. – Alok Save May 17 '12 at 03:09
  • 1
    I've read about MVC! I just didn't quite understand why it was so useful for multithreaded games until now! EDIT: Based on my prior (little) experience with multithreading, I can't split the window (and therefore graphics) thread from the messages thread. Is it okay to have the messages stored in the graphics thread and accessed from the logic thread? – Miles May 17 '12 at 03:10
  • 1
    @MilesRufat-Latre: You can and it would work but it wouldn't be the most efficient way. The more appropriate would be to split them as separate modules.You might want to give [SOLID](http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) design principles a look.There are no *correct* or *wrong* designs there are only *good* and *bad designs*. The better the design more scalable and flexible your software would be. – Alok Save May 17 '12 at 03:17
1

Trust me, you'll know it when your app will need multi-threading ;) the GUI will freeze and app won't be responsive. But like Als said, if you need to perform lots of tasks at the same time, it's a good option.

allaire
  • 5,995
  • 3
  • 41
  • 56
  • The project is a game, so it will either multithread or use a simple game loop. All of the tasks must be performed continuously, although some must be performed at a certain time relatively to others. – Miles May 17 '12 at 03:02