Team 12 Report 6 – The Finishing Touches

Hello everybody! It is finally time for the last blog post for this course! A lot of time has passed and I feel like have developed a huge amount during this course and it is a really fun thing to see!

Anyway let’s talk about the game and how it turned out and what I have been working on this week. This week we in the group decided to put in all of the effort so we would be finished with 1 spare week for emergency changes if it would be needed, there has been a lot of optimization, polishing and just a lot of small things that we have added!

The major feature I added this week was the web obstacle! The web obstacle is a obstacle that is stationary which the player can collide with! The player has the option to dodge below or above the web, he or she also has the option to dash through the web, thereby destroying the web in the process. The web is one of the few stationary objects that can be destroyed by the player. This is its main feature, it gives the player choice if he or she wants to dodge or go right through. The fits well into the game considering there is a spider enemy so it fits aesthetically into the game!
The cobweb obstacle works like most features and was pretty easy to implement, the only hard part was to make it so that the player could dash through it, thereby changing the sprite into a ruined version of the cobweb.

So besides all that I have been working on a function inside our AnimatedSprite manager, this function would get the current frame playing inside of an animation. So for example, we have an animation with 10 frames, and after 10 frames you want the sprite to disappear and stop repeating itself. This function was mainly created by that need. In our game we have ice stalactites that fall from the ceiling and if they hit the floor or the player they shatter. When they shatter they play that animation but it should only play once, that is the main reason I created this function. In all honesty the function was quite easy to make, it just check inside of the frame vector which frame it is currently on and returns it as a number! Even though it was not a difficult challenge to make it is a very good function to have and gives the animateSprite manager more flexibility and gives us as programmers more options and control.

So the final thing I worked on this week was the spider. The spider has been a real pain in the ass top get right but I think I finally managed to make it work as intended. Now you can dash through the web string holding up the spider in order to kill it. Once the string is destroyed the spider falls. I also made it so that the spider ”dangles” up and down to give it a more natural feel.

That is about it! The next week will be dedicated to optimization and project report writing! Thanks for reading and have a good one.

Here, have the AnimatedSprite function!    int AnimatedSprite::GetAnimationFrame()
{
return m_frame;
}

Very difficult isnt it? 😉
See you next week.

Team 12 Report 5 – Beta Polishing & Problems.

Hello everybody! This week has been a tough one filled with hours upon hours of work for us! The beta presentation has always been like a shining light at the end of the tunnel for us and we really wanted something nice to show during the presentation. Unfortunately this week has also been plagued by a lot of problems and communication errors between the programmers and the graphics artists. But problems aside this week has been very productive and we have gotten a lot of artifacts and features completed and polish.

This week is quite hard to describe by only talking about one artifact or feature so I will go through some of the things I have been working on for the beta presentation.

So first off I have been working on the spiders movement and finishing it up. It now hangs in the ceiling and dangles up and down when time passes. This was done by just having a speed variable that can be positive and negative, so when it is positive it goes down and when it is negative it goes up! I also tried to make it more menacing by making it so that the spider would leap towards the player when he or she was close to it. This feature was scrapped because it did not fit the game and it made the spider way to hard to dodge.

The second thing I worked on this week was the troublesome geysers. This artifact is the one that I disliked the most in the entire game. So my task was really to make the geyser a fun and challenging obstacle for the player. The geyser is a ground based obstacle and acts like you would think that a  real geyser would work. It has an internal timer that makes it change animation into an attacking animation. The geyser attacks with a beam of hot water that sprouts out of the ground towards the player. The real challenge here was to make it so that the geyser would only be dangerous towards the player when it’s attack was active. This was a challenge since I had to time the hitbox for the geyser with its animation. The end result was that the geyser too was way to strong of an obstacle.

Other than that I worked on level design, fixing the sonarbeam, tweaking the speedpowerup. This week has been a challenge but it has all been worth it considering that now we almost have a completed game!

std::cout << ”kim” ” ” ” Out!” << std::endl;

Team 12 Game Development Report 1 – Traps and mechanics

What I made: This week my big focus was on making traps and obstacles for the player to dodge.

The spider: The spider trap is a trap that will be somewhat hidden for the player and once the player is within striking range. Once the player is within striking range the spider will lunge downwards towards the player, the spider will charge downwards really quickly and once the spider has completed its charging cycle it will slowly reel back in to its original position and resetting its attack.
The spiders speed and and trigger distance is directly related to the players speed. This is so that the trap will not become obsolete if the player is traveling really quickly or really slowly.

How I made the spider: I made the spider in Visual studio in c++. It has several functions that are dependent on the players properties, I did by linking the players values to the spider so that the spider can read the players values.
The spider measures the players speed and distance and triggers once the values are optimal. Once it triggers an internal timer inside of the spider starts that decides how long the spider will charge. The timer starts at 0 and counts up to 9 seconds, the spider charges for 3 seconds and the reels back up for  6 seconds, once the 9 seconds has passed the spiders internal clock will reset and it will go back to 0 so that the cycle repeats.

Why I chose to implement the spider: I chose to implement the spider into the prototype because it is a trap that would be more interesting than just normal falling traps. Before I started to work on the spider I had made a falling stalactite and the choice was between the stalactite and another enemy and I made the decision to make the spider.
Why we wanted to have a spider inspired enemy inside the game: The team wanted a spider themed enemy because it would match the aesthetic style in the game. A lot of power ups are based on fireflies and a fireflies natural enemy is a spider. From a coding perspective I chose it because it would be an interesting challenge to have make an enemy that would have a charging attack and timer implemented into its trigger mechanics.

The end result with the spider was an enemy that was somewhat scary looking with and unpredictable behavior

.