I'm making a tower defence game in Java!
It's my first game development.
I want to know how many threads Do I need to create in a game, to split logic..
I've made this one:

    1. Main App thread
      (adds component thread - add(screen))

      • 1.1.1 Thread (graphic updates)

      • 1.1.2 Bullets physic

      • 1.1.3 Mobs physic
      • 1.1.4 Towers physic

Is it normal to split this logic? enter image description here

  • 4
    \$\begingroup\$ Is there a reason you have to go with a multithread solution for something as simple as a tower defense game? \$\endgroup\$
    – user15805
    Jan 2, 2013 at 16:59
  • \$\begingroup\$ The idea of the game will be different.. more harder as I want.. \$\endgroup\$
    – Dezigo
    Jan 2, 2013 at 17:04
  • 1
    \$\begingroup\$ That can be done without requiring multiple threads... \$\endgroup\$ Jan 2, 2013 at 17:58

1 Answer 1


Normally, it's not that common to split up in-game logic based on entity types; this is primarily due to the fact that there needs to be interactions between different entities computed as a part of the game in most situations, and separating them into multiple threads makes synchronizing and ordering those interactions a living nightmare, as opposed to establishing a fixed sequence of events.

Say for example that a bullet needs to hit a mob; it needs to do a collision check against the current positions of the mob and the bullet. If this occurs on the mob thread, for example, the bullet's actual position could change due to a race condition, if the bullet thread took over. In the best case, this would result in bullets being slightly off-target; in the worst case, this could result in catastrophic memory shenanigans, if an object is intended to be released or destroyed, or a property is set to null or something.

If I were you, I'd make sure you keep interactions on one thread, and feed the results of the collision checking into the rendering thread. If you must break up processing by entity type, have a loop across all bullets, then all mobs, then all towers (or something along those lines) within each processing step; otherwise, make them all a common Entity interface, and just let subclass implementations update their own physics in order of iteration. There are a number of other paradigms that could be used for this, but I've seen this used fairly frequently.

  • \$\begingroup\$ Do I need to create iterations in one own thread just like: in while(); - mobs physic - towers physic - bullets physic - finally draw (mobs/bullets/towers) ? \$\endgroup\$
    – Dezigo
    Jan 2, 2013 at 17:20
  • \$\begingroup\$ It's up to you. That's how I would do it. \$\endgroup\$ Jan 2, 2013 at 17:57

You must log in to answer this question.

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