Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
Is there a reason you have to go with a multithread solution for something as simple as a tower defense game? – user15805 Jan 2 '13 at 16:59
The idea of the game will be different.. more harder as I want.. – Dezigo Jan 2 '13 at 17:04
That can be done without requiring multiple threads... – Shotgun Ninja Jan 2 '13 at 17:58
up vote 7 down vote accepted

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.

share|improve this answer
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) ? – Dezigo Jan 2 '13 at 17:20
It's up to you. That's how I would do it. – Shotgun Ninja Jan 2 '13 at 17:57
OK. thank you!. – Dezigo Jan 2 '13 at 23:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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