Sign in to follow this  
harnt

Handling concurrent actions

Recommended Posts

harnt    122
I'm attempting to design a game in Java thats based off of the general tower defense type of game play, but with a lot more added into it. But, I recently ran into a block when figuring out how to do the towers working as separate entities (a tower can be firing concurrently at a different target than another tower, and at different rates of fire). Also, this presented a problem with the fact that targets can be moving independently of one another, at different movement rates. My initial idea was to thread them, giving the ability to sleep() per each thread(tower or target), but the possibility of lots of towers/targets at once seems like it would be a bit... much? If anyone could shed some insight as to how to best implement this, it would be greatly appreciated.

Share this post


Link to post
Share on other sites
ToohrVyk    1595
I would suggest to use an event-driven approach to simulate threading. For each tower, store the time at which is must fire again. When that time has come, notify the tower by calling a member function dedicated to that purpose. The function returns the next time when it must fire, which you store and resume waiting.

Share this post


Link to post
Share on other sites
harnt    122
Wouldn't that require a constant polling of whether or not it is time to shoot again, eating up cpu cycles?

While threads are sleeping, they don't use cpu cycles, I thought?

Share this post


Link to post
Share on other sites
Drigovas    509
Quote:
Original post by harnt
Wouldn't that require a constant polling of whether or not it is time to shoot again, eating up cpu cycles?
It would require you to constantly check to see if it's time for some event to occur, but if you use something like a priority queue, you can check once per frame against only those events that will be happening next [store the soonest events in the front of the queue]. This approach doesn't work nearly as well for things like actually finding a target to fire at, or moving the targets though [since these are things that'll be done very frequently], but for things that might only happen once every so often [like shooting], it works great.

Share this post


Link to post
Share on other sites
Omid Ghavami    1007
Quote:
Original post by harnt
Wouldn't that require a constant polling of whether or not it is time to shoot again, eating up cpu cycles?


Yes, but doing that is perfectly fine [smile]

Share this post


Link to post
Share on other sites
ToohrVyk    1595
Quote:
Original post by harnt
Wouldn't that require a constant polling of whether or not it is time to shoot again, eating up cpu cycles?


Not if you do things the smart way.

You can easily evaluate how long you have to wait until the next tower update (you simply compute the minimum update time of all towers in play), and you can then sleep until that time occurs.

The problem with threads is that they use memory (for their stacks), spend time being switched to and from (which is not instantaneous) and must also spend time acquiring locks on objects they need to interact with.

Share this post


Link to post
Share on other sites
harnt    122
Thank you for your replies, it has provided a great deal of help to my thought process.

It still seems like a polling of the towers would be quite intensive for when there are large quantities of towers shooting and units moving at the same time, wouldn't it?

It seems like there would be some way that I haven't thought of yet... Or is that just the nature of the beast?

If so, how do RTS games perform this kind of thing, because it would seem they would have a similar situation (towers shooting things, units moving around constantly, computer driven AI moving units, etc), yet it all seems to happen concurrently and doesn't seem to strain resources that much?

Once again, thank you for your input.

Share this post


Link to post
Share on other sites
ToohrVyk    1595
Quote:
Original post by harnt
It still seems like a polling of the towers would be quite intensive for when there are large quantities of towers shooting and units moving at the same time, wouldn't it?


Er. I do not want to sound harsh, but did you actually read my last message? There is no polling of the towers.

The program updates a tower (which is a necessary thing to be done regardless of the approach), determines the time when the next tower should be updated by computing the minimum update time (this can be done very quickly using, for instance, java.util.PriorityQueue<TowerUpdateEvent>) and then sleeps until that time happens.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this