aspose file tools*
The moose likes Threads and Synchronization and the fly likes Handle multiple things at once Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Handle multiple things at once" Watch "Handle multiple things at once" New topic
Author

Handle multiple things at once

Meshulam Silk
Greenhorn

Joined: Feb 12, 2012
Posts: 22
I know the title is stupid but I have no other way to describe my question. I don't even know if it belongs in this section...
Whatever here goes:

I have a simple pathfinding algorithm stored in an "entity" class which will start running when the "chasing" member is set to true. The algorithm works fine but the only problem is that while an entity is in chase mode the program waits for it to stop chasing and only then will it continue. This is annoying because it means I can't have two entities in chase mode at the same time.

Example:


What'll happen here is that test1 will start at (0, 0) and start moving towards test2 but test2 won't start moving towards test3 until test1 reaches it.
I was wondering if it's possible to get both test1 and test2 moving at the same time.
(An example that comes to mind: In Minecraft more than one zombie can chase you at a time. That's the effect I want to achieve).
I think this has something to do with threads but I barely know what they are.

The chasing algorithm goes something like this:


I left out quite a bit so if you don't know what's wrong tell me what's missing and I'll elaborate a bit further on how it works.
Thanks in advance
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3658
    
  15
You're right that you need to use threads. They are a relatively simple concept but can be difficult to implement.
This is as good a place as any to start.

And once you've read that, any other questions you have (and I'm sure there will be many) can be asked in the Threads and Synchronization forum


Joanne
Meshulam Silk
Greenhorn

Joined: Feb 12, 2012
Posts: 22
Joanne Neal wrote:You're right that you need to use threads. They are a relatively simple concept but can be difficult to implement.
This is as good a place as any to start.

And once you've read that, any other questions you have (and I'm sure there will be many) can be asked in the Threads and Synchronization forum


Thanks for the reply!
Like you said I find it hard to understand how to fit any thread related stuff in there. Do you know where else I might find info on this? Also can I just repost this on the threads and sync forum?
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11411
    
  16

How about I just move it over here for you.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3658
    
  15
Meshulam Silk wrote:Do you know where else I might find info on this?

Well if you've already managed to go through that tutorial I linked to, you might want to try one or two of the books that are recommended in the Bunkhouse
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2402
    
  28

If you are thinking about creating a Minecraft kind of game, having a thread for each character is not a good idea. First of all you will have too many threads. Secondly, you will have to synchronize the parts where one character interacts with the other, which will introduce bottlenecks
Meshulam Silk
Greenhorn

Joined: Feb 12, 2012
Posts: 22
fred rosenberger wrote:How about I just move it over here for you.

Thanks!

Joanne Neal wrote:
Meshulam Silk wrote:Do you know where else I might find info on this?

Well if you've already managed to go through that tutorial I linked to, you might want to try one or two of the books that are recommended in the Bunkhouse

I'll check it out thanks.

Jayesh A Lalwani wrote:If you are thinking about creating a Minecraft kind of game, having a thread for each character is not a good idea. First of all you will have too many threads. Secondly, you will have to synchronize the parts where one character interacts with the other, which will introduce bottlenecks

I didn't even know it was possible to make threads for each monster. I'm not planning on having that many ai's running at once. How would I go about making them threads?
If you think that's still not a good idea, what do you suggest?
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Meshulam Silk wrote:
Jayesh A Lalwani wrote:If you are thinking about creating a Minecraft kind of game, having a thread for each character is not a good idea. First of all you will have too many threads. Secondly, you will have to synchronize the parts where one character interacts with the other, which will introduce bottlenecks

I didn't even know it was possible to make threads for each monster. I'm not planning on having that many ai's running at once. How would I go about making them threads?
If you think that's still not a good idea, what do you suggest?


Before going into too many details, you should probably go over the tutorials previously linked. Before going over those tutorials details will sound more complicated than they are. The overall strategy would be to have just a few threads - one to interact with the user (paint the screen, and handle buttons, etc...) and one or just a few to handle the 'work'. Your monsters would periodically post commands to move into a single thread which then reads all the posted commands in order and executes them. There are timers and queues and other tools available to make that occur without a lot of work on your end, but the key is to learn about them - thus the tutorials and a good book as suggested previously.


Steve
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2402
    
  28

Meshulam Silk wrote:


I didn't even know it was possible to make threads for each monster. I'm not planning on having that many ai's running at once. How would I go about making them threads?

. I thought that's what you were trying to do. If you really want to do this (and don't do this) is make each entity a Runnable, and call the chase method from inside the run method. Then in your main class, create a Thread for each entity and start all the threads. Again don't do this, because your entity access other entity, and you will need to be worried about synchronization

Meshulam Silk wrote:

If you think that's still not a good idea, what do you suggest?


Its been a while since I did Game programming. You might get a better answer from a book on Game programmig. From what I remember, one technique you can do is have a tick function in the entity that just moves the entity by one step. Then in your main method call the tick method on all your entities. SOmething like this



This way, your main thread is moving all your entities by one step together. Keep doing it and do it fast enough, and it will appear that all entities are moving in parallel

Oh btw.. According to Java standards, your class names should start with upper case.
Meshulam Silk
Greenhorn

Joined: Feb 12, 2012
Posts: 22
Jayesh A Lalwani wrote:
Meshulam Silk wrote:


I didn't even know it was possible to make threads for each monster. I'm not planning on having that many ai's running at once. How would I go about making them threads?

. I thought that's what you were trying to do. If you really want to do this (and don't do this) is make each entity a Runnable, and call the chase method from inside the run method. Then in your main class, create a Thread for each entity and start all the threads. Again don't do this, because your entity access other entity, and you will need to be worried about synchronization

Meshulam Silk wrote:

If you think that's still not a good idea, what do you suggest?


Its been a while since I did Game programming. You might get a better answer from a book on Game programmig. From what I remember, one technique you can do is have a tick function in the entity that just moves the entity by one step. Then in your main method call the tick method on all your entities. SOmething like this



This way, your main thread is moving all your entities by one step together. Keep doing it and do it fast enough, and it will appear that all entities are moving in parallel

Oh btw.. According to Java standards, your class names should start with upper case.


Your code looks great but I didn't feel the while loop belonged in the main class mainly because I want entities to have different speeds but also because I feel it belonged in the entity class itself. Despite what you said I went ahead and made the entity class extend Thread just to see what I could do. In the run method I put the pathfinding algorithm and changed a couple of other things around. I ran it and everything worked fine! As for the synchronization issues, I have a render method which receives coordinates and an entity and only if that point is not occupied by a wall or another entity will it put our entity there. When I had two ai's chase me they got rendered into each other when they followed the same line so I read up a bit on synchronization, simply added the word "synchronized" to the render method and everything actually worked perfectly.

I understand if this method is not the best because of the potential number of threads, but it seems to be the simplest and sort of fits in with what I had in mind. Now I can add different behaviors to the ai's (such as "stroll" when not chasing). I might use the tick() idea for other things though as it looks pretty useful (I think it's what makes Minecraft work which has to mean it's good).

Thanks for the help (even I used the part of it I wasn't supposed to hehe)!
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2402
    
  28

The tick is a commonly used pattern that I got from a book long time ago. I forgot the exact name of the pattern. You can have each Entity have differrent speed by either altering the distance the entity would move, or by skipping ticks. So, if you have a character that meets 1 ft/s and another that moves 2ft/s and you tick every 100 ms, then within tick for first entity you change it's position by 0.1 ft and you move the second entity 0.2 ft. If you have things like, Entity A can fire 5 rounds/sec and entity 2 fires 10 rounds a second, you can have Entity A fire a round every other tick, and Entity B will fire a round every tick

Threads will work fine for small number of Entities with small number of interactions between them. Unfortunately, most games cannot make that assumption What are you doing? Making a Pacman game that runs on a 4 core machine?! Kind of an overkill won't you say? I think you should use threads to do other tasks that are time sensitive, like painting the UI, playing music etc like Steve said.


You might want to look at a game development book if you really want to get into it. There are a lot of strategies that you can use to optimize.
Meshulam Silk
Greenhorn

Joined: Feb 12, 2012
Posts: 22
Jayesh A Lalwani wrote:...
What are you doing? Making a Pacman game that runs on a 4 core machine?!
...


Actually, now that you mention it, I felt elaborating more on the game itself would confuse anyone that could help so I didn't.
The game I'm making actually very much is grid based (much like like Pacman haha) so moving entities a different amount of squares would look weird and would also let them "skip over" walls (black squares), unless I made sure they knew they were skipping over it, but even then it would still look weird.
So yeah. That also explains why I'm not planning on having a lot of entities running at once, and even then a "move" consists of coloring a square, and actually a couple of other things, but altogether it's not very graphically fancy or resource consuming so I can afford it.
I can imagine that if my game was in 3D it would crash before I launched it but in that case I'd use a different approach.

And I'll have a look into game dev books. Thanks for the tip (and everything else).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Handle multiple things at once