Team 12 Report 3 – Including animations and implementing it into our engine.

Hello! This week I will go through what I have been working on for this week. This week my task was to implement an old Animation skeleton from the SDL library to our new engine that is SFML based. This task proved itself to be a very hard challenge, my initial prediction of the time it would take was around 20 hours but that was a way to positive and naive prediction.

What I have made: I have converted the old SDL Animation skeleton to our new SFML based engine. This is so that we will have an easy to use way to implement animations and it will give us a great deal of flexibility and control over the animations. With this new skeleton we would only have to write a minimal amount of code to be able to use animations and it would mostly be filed based.

Why I chose to pick the animation implementation: I chose to start working on the animation skeleton since I wanted to challenge myself and see how much I could to in c++ and SFML. The reasons are more personal than optimal since I am not the best programmer in my group. Another reason I wanted to work on the animation skeleton was because I have worked a lot of programming game mechanics but not as much on the engine based things inside of our game. This lead me to be a bit afraid of falling behind on the more technical aspects of programming and I wanted this as a learning challenge.

How I made and implemented the animation skeleton: In order for me to explain how I made the animation skeleton I will need to explain the very basic foundation of how it works.
An animation works by taking multiple pictures and playing them one after another in rapid succession. To do this you need to do a couple of things. The first thing you need to to is to load a sprite sheet into the program, a sprite sheet is a picture with multiple sprites in it. for example a walking animation can contain 5 pictures and a sprite sheet with all of them in it would be a walking animation sprite sheet. The second thing you need to do is assign which parts of the sheet should be what picture, you need to put them in order so that they are played one by one after another. In order to play them one after another you need a timer that keeps track of which  picture you are on

.picture of a sprite sheet.

All of these things that were needed were inside of the old SDL engine and my main task was to convert SDL based functions into SFML based functions that would work in our new engine.

A lot more could be said about this topic but I feel like that would go way to deep into the programming lingo. Overall this was a very difficult challenge for me and as for the time when im writing this the animation skeleton is about 80% done.
Thanks for reading!

Team 12 Game Development Report 2 – Sonar projectile

In this weeks development report I will go through the creation of the sonar beam artifact, its purposes in the game and how I made it in c++ with visual studio.

What the sonar beam is: The sonar beam is teams 12 games only projectile. It is a projectile which will travel from the player through out the screen, clearing and destroying all of the enemies present on the current screen. The sonar wave will be what is called a ”smart bomb”, a screen clearer. It will act like a power up in the sense that it is available at all times.

Why I made the sonar beam: In order to finish the design course and pass the assignment each game was required to have a projectile in the game. At first we did not have a projectile in our game and we had some troubles deciding on how we would implement the projectile. We ended up with the sonar beam because of these reasons:

1. The game play will be quick and action packed and the player will be put into hard situations, having a screen clearing bomb will help players get some breathing room.

2. We discussed having a normal projectile that would be able to kill some enemies and destroy some obstacles but after some discussion we came to the conclusion that the player might have a hard time navigating the environment and shoot and tackle obstacles with precision at the same time.

3. The last and final reason would be that we wanted simple and easy controls and adding a fire button that the player would constantly use would be distracting.

How I made the sonar beam: I made the sonar beam using timers and distance measuring. The sonar beam will get the position of the player and when the player is pressing the fire key a sonar beam will be created. The sonar beam will grow in size as it travels away from the player by increasing the scale of the sprite.
The second the wave starts traveling a clock starts ticking inside of the sonar beam. The beam will grow in size and be visible until the clock has reached 3 seconds. After 3 seconds it will be invisible and another timer will start. This timer is the cool down timer that makes it so that the player will not be able to shoot multiple waves in a short time frame. The sonar beam attack will be used as a power up and therefore it should not be something that you can use all the time.
When the sonar beam collidies with obstacles and enemies they will be destroyed.

This is one of the main features I made this week.

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

.