Artifact of the week: Implementing Morker

Hello there!

Last week we made a prototype of the morker that was able to shoot bullets towards the player and move to each side to make it harder to hit it.

So this week our task was to implement it in the main project that we have started to get together after some struggles with github.  Even though we already knew what we wanted the morker to do and how we could do it in the prototype, it was another thing to do in the real project. So we started with the basics and took the code from our melee enemy, the warrior. They both have three states; passive, aggro and attacking. So we only had to change what the states themselves consisted of and when they were switched in between each other.

The passive/idle state was pretty much the same. The condition to go into the aggro state is not done yet. It is supposed to get into aggro state when it is hit, but because we do not have collision between projectiles and units yet in this project it is still the same condition as the warrior(aggro range). So last is the attacking, that is where they differ greatly since one is melee and one is ranged. So what we did was to take the same function to make the warrior move towards the player, but we placed it on the projectile we created instead and did not update it. If  we did that it would have been a homing missile what was not exactly what we were going for.

Next thing was to make the morker to zig zag to not be so easy to hit. The reason we  want it to  zig zag is so that it will be more of a threat when it is being aggroed. It can only be aggroed by taking damage so if you are able to manage your shots you will not have to worry about them. So we used the if statements that i wrote about in the last post. My co-programmer Jokke figured out how we would be able to get the morkers to move in different directions depending on where the player was. It was as usually not a ground breaking way to do things but it did work nicely, we just used some if statements to check whether the player was to the left or right to the enemy and at the same time if it was below or above him.

So that is it for this time, take care and i’ll see you in class =)

Blogg of the week: Alpha

Hello, this week hasn’t been that successful so I do not have a finished artifact to write about. So I figured that I would write about what I have been doing instead.

I have been working with Box2D, which is a physics engine that we use for collision. Last week I worked with getting collision to work. Collision is working by itself Box2D so it is more about being able to use it, and getting used to the structure. It probably isn’t that hard to learn, but since I haven’t programmed before I started this school it took a bit of time and some help to get things running.

So for this week we were supposed to make so that you can detect when objects collide. This is made by a “contact listener” in Box2D and the idea is simply to make it detect collisions so that you can then state what should happen. The contact listener have four steps. The first one is “Begin contact event” which checks when two object overlaps. The second one is “End contact event”. This is called when the collision ceases. Next is “Pre-solve event”, this is called after collision detection, but before collision resolution. This gives you a chance to disable the contact based on the current configuration. Lastly we have the convenient enough “Post-solve event”. The post solve event is where you can gather collision impulse results. If you don’t care about the impulses, you should probably just implement the pre-solve event.

It looked really strait forward so we thought we could continue to use Box2D even though we initially used it to be able to make smoothly made walls. But we could not figure out how to actually use it. We got all the above written and shown parts of a contact listener but we did not know how to actually use it. Documentation was not that great and often it was written in flash or java so we gave up on it after a while and thought it was simpler to just use regular collision. So as I am writing this we  are almost done with the collision and the alpha with help from our technical artist: Oscar Mohlin and my group member in my last project Sebastian Rosenblad. Since our lead programmer has more important things to do as we had some problem with syncing our project it is great that we can get help from these guys.  I think i might look up the contact listener later since it seems really good, but right now we just need to get things done.

That is all for now, hopefully I will have some more to write about next week.

Artifact of the week: Collision

Alright, last week I worked on Learning Box2D and make a project where I would use it together with SFML. We(me and another coder in the group)  had some problems initially  as we first had wrong versions of both above listed “tools”. So after we figured out that the SFML that we had been using before we started was 64 bits and that the Box2D we had wasn’t compiled for VS 2012 either we got them working together. Box2D is not that hard in it self but it is a bit different because you don’t always know what is going on behind the scenes when you first use it. At first I though that it was enough to just write the world, the bodies, set the gravity and draw a “sprite” in the form of a circle and designate it to the position of the body. It was then supposed to fall and when it hit the other box it was supposed to stop. When we started the project it did not do anything at all though.

The reason was that you still needed to make some more variables that are used to update the player.

After that we had a Ball that was affected by gravity. We then tested to make a simple rectangle to see if the collision would work. It did and so I started to work on Chains. They are made up by multiple vertices that are connected with lines that works very well as walls since its easy to form them to whatever form the room have.

To test this I wanted the player to be able to move freely and not just be dragged down by gravity. So I disabled gravity and used the SFML inputs to start with. I couldn’t use them without modifying them a bit since it was the Box body i wanted to move and not the SFML “sprite”. After that was done I put the chains in the project and hoped that it would work. At that point I had not created a fixture as I thought it was only used for making the bodies visible. But it apparently has to do with collision. After I fixed that something still was wrong. Box2D makes the whole window to have negative y value as it uses the top left corner as the origin instead of the lower left. So when I had set out the positions as positives figures thinking that it was somewhere on the window it was actually above the window.

So here is an example of a chain: