This is a suggestion for one of our games. You may comment on and rate the suggestion here.
Game: all (Change)Type: all (Change)
< Back To List
The Suggestion...
Refreshing such a list would happen whenever their current top target dies, when they would move onto the next one. The distance should still be a factor, though, but the calculated priority could just be compared to the stored second best priority (even if it's outdated), reducing the amount of comparisons and distance calculation. The other factors could be whether the enemy is melee/ranged/magical and how much xp they are worth at level 1, and by tweaking them the AI could be much smarter than just blasting the nearest enemy.
Of course, if you already have a good implementation on looking up the distances and choosing the nearest target, I don't know if this would be worth it. It's probably not enough to make the game un-sluggish on busy screens alone, anyway. A smart AI doesn't really matter much in the hands of a smart player anyway, since you can already just unsummon a wizard and then reposition him - handpicking targets like that would be difficult with a less predictable targeting system.
Mostly I'm just interested in what the current system is, actually. :D
Comments
Well if they targets highest priority there could be many problems however it could be helpful.
it targets the nearest enemy currently.
I like the idea in principle but it's difficult to imagine an algorithm which always picks the "best" target, bearing in mind different players will have different ideas about what that is.
I had considered having the wizards look for grouped targets and blasting in the middle of them. But it would be annoying if you are trying to shepard a lot of units together. Also only appropriate when fighting weak units.
Maybe the best one would be the nearest target, but blast in front of it, rather than at it, resulting in the unit reeling away rather than towards.
I don't know really I have given this a lot of thought in the past but couldn't come up with something that is always and obviously better.
I like the idea in principle but it's difficult to imagine an algorithm which always picks the "best" target, bearing in mind different players will have different ideas about what that is.
I had considered having the wizards look for grouped targets and blasting in the middle of them. But it would be annoying if you are trying to shepard a lot of units together. Also only appropriate when fighting weak units.
Maybe the best one would be the nearest target, but blast in front of it, rather than at it, resulting in the unit reeling away rather than towards.
I don't know really I have given this a lot of thought in the past but couldn't come up with something that is always and obviously better.
Yeah, I know there was a lot of discussion about these things with Note. How does it exactly find out who is the closest, though? I'd imagine it to be fairly slow (or rather, possible to improve) to just calculate everyone's position every time the unit is looking for a target.. And I can't recall whether there was more to it, while feeling that there probably is.
Ok so here's the way I programmed it (from memory)
- to find a target look through all the teams that are enemies
- calculate the distance to each character (using pythagorus (=sqrts =slow)
- choose the nearest
- keep on that target until either he dies, you die, or you reel and come out of the reel
So it's slow but a couple of things make it reasonable
- the targets are only selected rarely
- sqrt can be stored in look up tables it's possible that shockwave (or c++ (or even the processor)) is already doing that.
I think note did some optimizations to this to make it faster.
The bigger problem for the speed of the game is bullet collision detection. An arrow needs to detect collisions with all enemies every frame - that's a lot of square rooting. I had an idea to only check collisions with enemies that where relatively near by after the first frame of collision detection, but I can't remember if I actually implemented that.
The energy mines were so intensive that I decided to make them check collisions with 1 member of the enemy team randomly each frame - I think I may have even reduced that to every three frames. So the collision on the energy mines is really unreliable but it 'feels' ok in the game, because, hey - they're land mines right?
The pulse bullets were so numerous I did a similar thing there - here it does feel bad though. When the bullet is travelling at speed it often passes through an enemy.
- to find a target look through all the teams that are enemies
- calculate the distance to each character (using pythagorus (=sqrts =slow)
- choose the nearest
- keep on that target until either he dies, you die, or you reel and come out of the reel
So it's slow but a couple of things make it reasonable
- the targets are only selected rarely
- sqrt can be stored in look up tables it's possible that shockwave (or c++ (or even the processor)) is already doing that.
I think note did some optimizations to this to make it faster.
The bigger problem for the speed of the game is bullet collision detection. An arrow needs to detect collisions with all enemies every frame - that's a lot of square rooting. I had an idea to only check collisions with enemies that where relatively near by after the first frame of collision detection, but I can't remember if I actually implemented that.
The energy mines were so intensive that I decided to make them check collisions with 1 member of the enemy team randomly each frame - I think I may have even reduced that to every three frames. So the collision on the energy mines is really unreliable but it 'feels' ok in the game, because, hey - they're land mines right?
The pulse bullets were so numerous I did a similar thing there - here it does feel bad though. When the bullet is travelling at speed it often passes through an enemy.
I actually like how pulse goes through it feels like it takes more skill that way.
Well that's true too :)
Besides, if you play the Danmaku map enough, trying to aim the Pulse will become second nature! :D
Perhaps splitting the room into parts (like 16 or 25 squares) and only checking the enemies in the same part or adjacent parts instead of them all for collisions could help. I think Note had something similar going on, but I don't remember him implementing it or anything.
Perhaps splitting the room into parts (like 16 or 25 squares) and only checking the enemies in the same part or adjacent parts instead of them all for collisions could help. I think Note had something similar going on, but I don't remember him implementing it or anything.
yes I had considered a sort of layered bucket system of collision detection but haven't had time to try it yet.
i did this once.
it turned out okay, but screens always ended too fast, amd i didn't like it. also, it was kinda slower to sort through who to attack.
Also, i think i optimized the heck out of targeting, bullet, and mines. i dont think i left much in the ways of square roots, either:P a square is just as effective.
the current data structure is a grid/bucket, and there might be one for every background tile.
it turned out okay, but screens always ended too fast, amd i didn't like it. also, it was kinda slower to sort through who to attack.
Also, i think i optimized the heck out of targeting, bullet, and mines. i dont think i left much in the ways of square roots, either:P a square is just as effective.
the current data structure is a grid/bucket, and there might be one for every background tile.
You must be logged in to add a comment.
Rating: 0.00 in 0 votes
Status: rate
Better targeting system