Hi. This post will refer quite a lot to Box2D, you can check out my first post for the course to see more about what we’re using it for, or go to http://box2d.org to read more on your own.
This week we have.. worked more on the second enemy. Last week we felt somewhat done with the behaviour of it, but implementing it in the real project proved to be quite hard. Due to github not working for us, we’ve all worked in very different versions of the project, and so our lead began to write a new structure for us to all work in some week ago. It all seemed fine but apparently the collision had stopped working, so we had to fix that. What went wrong there was that the iterations needed for the box2D world to work had been set in the class’ constructor, not the update, meaning the sprites ran around fine, but the box2D bodies they were attached do did nothing at all.
Then came the second problem, the behaviour of our first enemy wasn’t working correctly either. It moved around, but the rotation (which the velocity uses) was incorrect, so it didn’t move or rotate towards the player. This was solved like this:
I honestly don’t really remember what was wrong, but I think we had put cos/sin in the wrong place,
So, after fixing our first enemy, we finally got back to the second one. What makes this one different is that it zigzags and shoots, so it’s pretty much the opposite of our first enemy. As of right now, the states (passive, aggro and attacking)trigger exactly like the “warrior”.
^ the distance is sqrtf(enemypos.x – playerpos.x * enemypos.x – playerpos.x) + (enemypos.y – playerpos.y * enemypos.y – playerpos.y).
When we get the collision between objects and bullets to work (we don’t do that with box2D because their “contact listener” was something we didn’t understand) the new enemy will only be triggered to aggro when shot by the player. The enemy does zigzag now though, and it changes its movement depending on where it is in relevance to the player. So basically it uses the player as the (0,0) and checks if it’s own x/y-position is lower/higher to see in which corner it currently is.
The code in the above picture checks if the enemy is lower to the right or above to the left of the player. The coordination system in box2D is upside-down, so X is still in the right direction, but Y isn’t. Which is why it looks like the >= and <= are wrong. It’s not the neatest solution to the zigzaging, but it works!
J.Majlov 
Hi!
I think most groups have had problems with Github, it does not seem so user friendly or forgiving if you do the commits, pushes and pulls wrong.
I think it is interesting that you chose to have an enemy that zigzags, most seem to prefer having enemies that just either runs straight at you, stands still and shoots when aggroed or just keep as certain distance.
What I can see from the code you have posted it looks like they changes direction when at a certain threshold. Have you considered having some randomness to where that happens? That way it would be even harder for the player to predict what will happen and maybe it will make the enemies feel more unpredictable? But if you don’t want randomness for your game I think it is neat as it is 😉
What will be the difference between the Morkers Aggro state and Attacking state? I assume that it will be zigzagging in both Aggro and Attack states. So the only difference will be that in Attacking it will attack? Couldn’t you just check the distance and so it is a clear path to the player to see if it will attack? Then you would not really need the Aggro state.
It was a good post. I had no problem reading or following what you ment (I think).
//Andrée