Trowl – EndState

This week we have had a lot of things to do since final is closing in. Most of the tasks this week has been buggfixes and implementing all animations to make the game more smooth and fun to play. But one thing that I have worked a lot with besides these tasks is the Endstate of our game.

The Endstate is the state when the player either loses or wins the game. The easiest one of these two were the lose critera. When the players stress has reached its maximum amount the player dies and the game is over. Stress represents the players health. So this part was actually quite simple. The win critera however, was anything but simple. I had this vision in my head where the player wins and the locomotive appears and when the player passes the locomotive the player has won. It might sound simple when put like this, but it really was not.

There are some thing that I need to clarify before I can explain further. We have two trains which we loop since our game is a sidescroller. Basically we draw two trains after eachother and loop them when they go out of screenbounds to create the illusion of a long running train. These are constantly drawn out and looped as the game is running.  So, what I wanted to do was to draw the locomotive as soon as the player picks upp the last owlet from the train (owlets needs to be picked up to win the game). And when this occured I also wanted to replace one of the trains with the locomotive and stop drawing that train. And this should only happen if the last owlet was picked up aswell as the second train was fully visible on the screen. I chose this solution beacuse I wanted to create a smooth transition.

To do this I made a boolean variable that checked if the last owlet was picked up and change it to true. And if this boolean variable was true aswell as the position of the second train was equal or less to zero in the x-axis the locomotive was to be drawn out and the other train stopped being drawn. And when the second train was out of screenbounds it also stopped being looped and drawn out. And finally when the locomotive was out of screenbounds the player has won! I worked many hours trying to accomplish this and now it works as I wanted it to. I am very pleased with the outcome!

Trowl – Enemy Waves

This week  I have been working on something we call Enemy Waves.

In a lot of games you have different waves of enemies. The purpose of these waves is to present a new enemy type or challenge the player in some way. Sometimes a combination of both. Our game has a total of ten waves at the moment. We thought that presenting each enemy type would be a good start of our wave system. We got three different enemy types and wanted to present these in the first three waves. First we start of by sending in the easiest enemy, the Falcon. This enemy only has one health. Next wave the player would encounter our second enemy type, the Hawk. Which has two health. And on the third wave our third and most difficult enemy type is sent in, the Eagle. This enemy has three health and therefore the most difficult one to kill. The first five waves looks like this: 

So, after presenting each enemy type we start to combine them in order to test and challenge the player. These first five waves works fine and is not to difficult to complete, but the rest of the waves still need reworking since some of them are way too difficult. You could say that we have a lot of play-testing ahead of us.

Enemy Waves is a class that I created which primary function is to draw out the enemies when want and to update them. This class stores references from each enemy type and power-up so I can easily access them in the Enemy Wave class. In each wave I call for a function that draws the chosen enemies and power-ups that I want the wave to contain. For each wave I have created a boolean variable which can be either false or true. When the boolean value is true, the wave is initialized. When the boolean value is false the Wave is finished and sets the next waves boolean value to true. A wave is finished when all enemies in that wave is either dead or out of screen bounds. After each wave I also have to reset the enemies position to their original one. To do this I call on a respawn function that resets their position, health and sets another boolean value to true which allows me to draw them once again.

Creating this Enemy Wave class was difficult. I had never done something like this before and therefore it took quite some time to come up with a solution that worked. At first I had a lot of issues with it causing the enemies not to respawn correctly and many other problems. But now it kinda works like a charm!

That is all for this week!

 

Code Review – Group 15

This is a code review of Group 15’s player class. I will look into how did they implement their player class in their game, what kind of bond to other classes it has and what functions it holds.

To make their player class work they have four keystones:

• The player class inherits from an Entity class which inherits properties and functions from another class called GameObject. The GameObject class handels most of the games different objects movement, position and when to draw objects in the game.
• A DrawManager is included which handels the rendering and drawing of the sprites.
• A SpriteManager is included which handels the different sprite textures.
• A CollisionManager which handels the player’s collision with other textures.

The functions of the class do not really do much at the moment besides the Update function which handles the player’s movement. The player controls the avatar with WASD and the mouse points out the direction the player is facing and where the player would like to shoot for example.

In GameState the player class position is called upon in order to set the enemies movement towards the player if engaged and if their health is above 0.

Something I do not understand is why the player’s movement controls are created in GameState as well, when they already have one in their Player class. The best solution to this would be to call upon the update function from the player class instead of have multiple functions for player movement. In my opinion it also is more neat to have less code I GameState and much easier to find and modify if needed, if it is placed in the player class.

In the GameState draw function the player calls upon a draw function from the DrawManager to render and draw the player sprites. This is good since it is just one short line of code and does not require anything else. This is how they should have called upon the Update function from the player class in the GameState update function to decrease the amount of code.

The player is also connected with a camera that checks the player’s X and Y position and therefore always focused on the player.

Besides from that one slight flaw with player controls being created twice there is not much that I would like to change. I would like to see them use the player class a bit more though. Maybe put the collision of the player in there as well, just to have easy access to.

But overall it looks good!

Trowl – Thunder

This week I have been working on one of our obstacles in the game. This obstacle is a thunderstorm that occurs at certain occasions as the game proceed. The thunderstorm event takes place on the top of the screen and covers an area that is 1920 pixels wide and 300 pixels tall. Here is a picture of how it looks like in the game:

The thunderstorm sprite is just a temporary one which I drew myself! As you probably can see it does not really fit in with the artstyle. It is what it is and works as a temporary sprite to do some testing with the obstacle, and so far it works kind of as we want it to.

To implement this obstacle I created a new class called “Thunder” with different functions. The functions in this class is actually quite similar to the functions in our “HardWinds” class which I talked about in a earlier post. The Thunder class stores the hitbox of the sprite which at the moment is equal to the thunderstorms size, 1920 x 300. When the player collides with the thunderstorm hitbox it increases the players stress. Stress represents the players health. The program checks the collision between the player and the thunderstorm by checking if the two different sprites overlap eachother. And if they do the collision function is initialized and a function from the HUD is called upon which increases the players stress. At this time this obstacle occurs every 20 seconds and has a duration of 10 seconds. This is achieved with a function which the HardWinds class also use. This functions uses three different float variables: one for elapsed time, one for duration and one for frames/second. As the game starts the frames/second starts counting and is equal to the elapsed time variable. And when the elapsed time is equal to the duration variable (which is 20 frames/second) the thunderstorm event is called upon.

Like I said before this obstacle mostly works as we want it to, besides from two flaw. The players stressmeter increases extremly rapid as soon as the player enters the thunderstorm and kills the player within seconds after entering it. This makes the obstacle a bit unbalanced and need to be dealt with. The second flaw is that the thunderstorm just suddenly pops up without any warning and easily kills the player if the player is positioned on the high end of the screen. To fix this we have to implement som sort of thunder sound that alarms the player that this event is about to occur.

So that is all from me this week!