I’m using AABB for collision between player and enemies. Now, when the player has a weapon such as a sword, this is an extra sprite, thus when pressing attack, player
hits with the sword - what is a way to handle this collision, just do the same as between player and enemy but now treat this as a sword to enemy collision?
When player hits an enemy with sword, is it best to make the enemy bounce away as not to get hit straight away again, just trying to think what AI could be used in this situation?
First, yes, the collision detection would just look to the sword object and the enemy objects to determine if there was a collision. The basic idea is that each loop you will compare all collidable objects with all other collidable objects.
Then, in terms of collision handling, theres a few ways about that… splitting the objects apart is one method, flags and timers could also be used (as in if (hit && timer not complete) start timer). Ultimately, it goes to what effect you want to create when an enemy is hit, and could vary greatly.
In a more general sense, the way I went about that when I recently had a similar problem was to make all the objects with a set of flags that would say what the object is itself and what objects it could collide with, and that would be used to sort the collisions. From there, when 2 objects collide I would call the response from both objects.
In terms of AI, you might want the AI to respond by running away when hit, or any other type of response.
Theres not really a right way, and without more information I couldn’t give anything more specific than this.
I’ve added a simple sword as an extra sprite just offset to where the player object is and do a collision check on the
sword to enemy. Sword is used each time player hits left mouse button as long as they have selected this, I’d like to play animation here where the sword goes from say
30 degrees down to 160 degrees - guess just rotate the sprite and use a thread or timer event here?
One thing I don’t want to be doing is collision check on all the enemies within the game when they are not actually in view, this is easily handled, but still a loop is involved
to check which enemies are in view - some spatial partioning (parent and child nodes) could be used here but at the moment, still full 60fps with vsync enabled.
No problem, even though I don’t feel like I was able to help that much.
[quote]I’ve added a simple sword as an extra sprite just offset to where the player object is and do a collision check on the
sword to enemy.
[/quote]
That’s a relatively common technique.
You’ll have a choice to make here; you could create a fixture with a static sword image and move the fixture for the attack, OR, you could create a static fixture and have the sword attack animation displayed.
In the end, you are right, you will then test collision between the sword fixture and the enemies (and anything else the sword can collide with, like destructible terrain)
[quote]Sword is used each time player hits left mouse button as long as they have selected this, I’d like to play animation here where the sword goes from say
30 degrees down to 160 degrees - guess just rotate the sprite and use a thread or timer event here?
[/quote]
I really don’t think that a thread would be necessary… you will be looping through the objects as it is, and you should already be tracking the frame time as it is, so you can use that for timing.
[quote]One thing I don’t want to be doing is collision check on all the enemies within the game when they are not actually in view, this is easily handled, but still a loop is involved
to check which enemies are in view - some spatial partioning (parent and child nodes) could be used here but at the moment, still full 60fps with vsync enabled.
[/quote]
Yes, and you will be looping through the objects each frame no matter how you slice it…
you will have a choice though; either manually going through all the objects
ie:
player update
if (player attack) sword update
enemy update
etc…
OR you could set up your objects such that each object derives from a base object, in the end you will likely prefer this method because then you can simply have your game loop like:
checkInput
for (gameobjects) gameobjects.update()
render
At the start, there simply will not be enough objects around to actually slow things down at all… but yes, filtering collisions for quick outs if there’s no chance for collisions that frame is relatively simple. If you are on a desktop, you might have thousands of objects on the screen before you notice slowdown. These aren’t Nintendo days where the system could only handle a handful of objects before issues come up.
