Artifact of the week: More stars

So last week I wrote about how we used stars as collectibles. Since then we continued to work on that among other things to get our game done for Beta.  After being able to spawn stars from dead enemies and pick them up we wanted the to show the player the count as well. The reason behind why we rather show the stars than to hide them is that in the end our game is about high score. There for you should always be able to see how you rank up to previous attempts and other players at any moment. I also feel like it is much more satisfying to collect something if you can see how it grows while you collect them.

Something we thought about was where the text was supposed to be placed next to the symbol. The two options we were choosing between was to the right or to the left. The most games I have seen have had their text to the right. The counter argument was to have the text more centered to the screen as it is the number you will more likely want to look at than the image. As you can see we finally decided to have it to the left.

Through our textmanager we loaded the image of the star and by calculating the center of the window and then reduce that value by the same only multiplied by a number we could place the image where we wanted it. Since it is calculated from the windows position and not from the background it will follow the screen as it moves.  The same was done with the counter of the stars.

We had to switch the image of the star to one with a white boarder though so that you can see it on top of the black nothingness that is outside the map right now.

We also added sounds to the stars. From the sound player we loaded in three sounds that are very similar to each other but in different tones. Then we have a function where we say that every time a star is picked up the soundmanager should play one of the three sounds randomly so that it doesn’t get too repetitive when you collect large amounts of stars. Right now every enemy drops 16 stars each. Even though you mostly pick up many stars at the same time you will still hear the sound quite a few times over the course of the game.

Thats what I had for this week. Take care and I’ll see you in class

/ Hampus Lyman

Artifact of the week: Stars

Hi there !

This week I have worked with making stars appear when enemies dies with the rest of the programmers in my group. The stars are our collectables that you get extra score from when finishing the game. The way they work is, when the enemy dies, the stars will spawn from the enemy and get velocity/speed during a brief time in a random direction. Since the time and speed are the same for all the stars, it will end up looking like a circle for the most part.

When the player come near the stars, the stars will start moving towards the player. We decided that it should be like this since it is fun to collect thing but we don’t want the player to run all over the place for scattered stars. When the stars reach the player they will get deleted.

Both to check if the player is near enough to move to him and if the star is close enough to the player to be collected are made by overlaps. The first overlap is checked first when the enemy dies and if the player is not close enough for the stars to start move to him they will scatter. If the enemy would be killed when the player is in range to collect the stars they will go to the player directly. Often the stars will start moving to a random position and then those that was moving towards the player will be switching over to the first overlap and chase after the player until it gets into his collect range. It looks cool when the stars gets shot out and then suddenly starts curving themselves to hit the player. There is a slight problem though, when the player is in range to make the stars go to his position right when he kills the enemy they will never go into the else if statement that tells them to scatter. Currently this makes it look like it is just one start heading towards you. We have some more important things that we have to do tomorrow so I think we will leave it like to the beta at least and see if we can delay them somehow so that it looks like you are getting ten stars instead of one. I guess we could just reduce the range for making the stars go to the player so that it wouldn’t matter when it only looked like one star because it would be so close. But then that would mean that we would have to see if that is enough range so that it does not become like chasing the stars.

Now i will barage you with very precise screenshots about the behavior of the stars with paint drawings 😛 (and the update function from star)

   

That’s all for now, thank you for reading and have a nice day/evening/night.

See you in class

/Hampus Lyman

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 =)

Artifact of the week, AI.

Hello dear class mate(s).

This week I have been working with some simpler kind of AI. As always we have been using Box2D mostly for walls but that isn’t anything that I plan on rambling on every post about how it works, just so you know where the b2vec is coming from. 

Before  the feature freeze we decided that we probably should cut down on the number of enemies. We had four of them planned at that point. It is 3 and one of them is now a hybrid between a moth and a worker, so i refer to it as morker ^^ It starts as a worker, being passive until attacked. The next state is the attack states, and this is where it takes the ability of a moth. Only that moths were originally supposed to dodge every shot from the player and only be killed by a certain attack. The morker should only be to be hard to hit rather than impossible. We started with getting the morker to shoot since that felt simpler. 

We had the means to allow the player to fire bullets in the direction of the mouse. So to do this was not that different. The only thing that had to be done was to set the part that decides to fire to the mouse position to the player instead. It shoots right on point but it has some thing that might be considered as flaws. If you are moving constantly in a wide circle around the morker it will not be able to hit you. It is supposed to be more enemies in the game so you cant really adapt this tactic in game, but we might want to add some spread on the bullets so they are harder to predict. I think this is something that we might do a bit later though since it should work well without it too.

The thing that was more problematic to do was as to when the enemy should attack the player. At first I checked if the coordinates of the player was bigger than the enemy radius  to get the enemy to fire constantly to see if it worked.  This only works when you are moving in the screen though so it wasn’t meant to be a permanent solution. So next we added another circle to the enemy to act as range. So that if the player is inside that radius it will be attacked. 

 

Next we started on the moving part. We used a similar system from the cooldown of the bullets. A ticker counts down from 3 to 0 in very small jumps like 0.0005 and when it is between two values the morker is given a certain velocity. There are surely better solutions out there, but as fairly new programmers this was the best we came up with right now. 

 

The things we are doing right now is made in a “mock up project” since our main project is being re-built by our lead programmer. So if you feel like it looks too simple it might be because of that 😛 Anyway we will get the logic into the tasks so it shouldn’t be too hard to get it into the real project when it’s done in some days. 

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.

New blogg

My last blogg seemed to have some problem with showing comments for some reason. So I thought that I would just make another one since I wasn’t too fond of the old one anyway.

If anyone would be interested to see what I actually wrote in the last blog I will link it below. None of the post is newer than the 13th Februari though.

http://zoza.blogg.se/

 

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: