Splitting logic into threads in Java tower defence game

Question

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?

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.