Last blog post Dragon Song

So this is the last blog post for this project. We have managed to complete most of the feature we wanted to have for the beta so this week have mostly been about cleaning up the code and trying to eliminate memory leaks. This makes it harder for me to find an artifact to write about in this weeks blog post.

The new particle system implemented in our game last week resulted in some major memory leaks. I mentioned smart pointers last week, and I solved this memory leak using smart pointers. We used unique_ptr in our project. They keep track of the memory they point to and delete themselves when they have completed their task. The advantage for us using this method is that it’s more simple for us to use, and make the code shorter. One disadvantage, and a reason that we maybe should have not have used this method in this project, is that we should practice deleting pointers in a traditional way to get a greater understanding on how they work. We don’t have enough time to change back, and they work as we want them to so we won’t change them back.

Another problem I had with the smart pointer, or at least I think it was because of it, was that I had to write some collision checking in another way. Using a for loop crashed the game when collision between some objects happened. So instead I had to use “auto, while”. I don’t know why this works while the for loop doesn’t but at least it works now.

Here is an example of the collision checking:

auto enemybulletIter = m_enemyBullet.begin();

while (enemybulletIter != m_enemyBullet.end())

{

bool enemyDied = false;

auto bulletsIter = m_bullets.begin();

while (bulletsIter != m_bullets.end())

{

if (enemybulletIter->get()->getSprite()->getGlobalBounds().intersects(bulletsIter->get()->getSprite()->getGlobalBounds()) &&

enemybulletIter->get()->IsVisible() && bulletsIter->get()->IsVisible())

{

enemyDied = true;

enemybulletIter = m_enemyBullet.erase(enemybulletIter);

bulletsIter = m_bullets.erase(bulletsIter);

m_PlayerScore += MAX_SCORE;

++m_bulletCount;

break;

}

else

{

++bulletsIter;

}

}

if (!enemyDied)

++enemybulletIter;

}

It checks if two sprites intersects with each other and if that is the case remove both of them from the smart pointer “list”. This does almost the same thing as a for loop would do, but works better in this instance, and also looks more advanced for better or worse. We also have a nice debug screen activated by pressing F3. With that we can see if the objects in game are really removed when they should be.

A picture showing the debug info:

I have also reduced the size of Enter and Update in the GameState.cpp. In the Enter I created functions where I moved parts of the Enter, to give the code a cleaner look. Now I call on these functions in enter to load input, sound, textures and text. For the Update I moved some parts of the code to already existing update functions and created some new ones. With the load background Love crated earlier we have now moved about 300 lines of code out of the Enter, and around 100 for the Update. This won’t make any difference in the game play but makes the code cleaner and easier to read.

After this was done I went through the whole code to restructure some parts of the code, removing unnecessary white space and remove some code we did not use anymore, and removed some code that were commented out and only made the code harder to read.

This blog post was a little messy because of the lack of a good topic to talk about. With this being my last blog post I just want to mention that I thing I have learned a lot during this project, and while these couple of weeks have had their ups and down it has been a fun experience!

Bullets in Dragon Song

Similar to the previous week this week have mostly been about fine tuning parts of the game. Anthon Fredriksson introduced us to smart pointers and helped us implement them in our game. With this a lot of our memory leaks were eliminated. Some other parts of the game were also fixed, but for this blog post I will write about the bullets in the game. The player bullets, the enemy bullets and the huge sound wave “bullet”. All of these are actually projectiles but I have decided to name them bullets in the code for a good reason I am sure.

The player bullet and the power up bullet were already implemented in the game, I only made some minor changes due to the redesign we made of the game last week because of the delay between when the player shot a projectile and when the sound played. When the bullet no longer has any connection to the beat of the game the player had no reason not to spam shoot the enemies, making the game impossible to lose. Therefore I added a limit to how many bullets that can be active on the screen at the same time. The solution was simple, I added an integer that holds how many bullets that can be activated at the same time. When the player shoots a bullet one value is subtracted from this integer, and when some collision happens between the bullet and an object or the end of the screen one value is added to this integer.

Last week the player could activate the power up bullet without any limitations, resulting in that the player could spam the power up. I changed this in a similar way of the player bullet with an integer. When the number 1 key is pressed one value is added to this integer, and when this integer reaches 10 a big P symbol (a place holder) the power up can be activated. If this power up is activated the integer is set to 0 again.

The enemy bullets was created this week. The class is written almost the same as the player bullet class as it works very similar. The challenge for us now is how the enemy bullets should be activated. At this moment they are activated when the player has activated the player bullet five times, and is activated from every living enemy. We have not yet decided how this should be done, or how we will write the code for it. This is one of our goals for the beta presentation this Friday.

A picture showing the player bullet and the enemy bullets. Because of changes to the game we have used place holders for the bullets:

The following code is a example of the collision between enemies and player bullet, with the ++m_bulletCount integer adding a value to allow the player to activate a bullet again. This piece also includes collision with discobomb bullets and enemies. This is just an bonus example if you want to see  how the smart pointer works in our collision checking.


auto enemiesIter = m_enemies.begin();
while (enemiesIter != m_enemies.end())
{
bool enemyDied = false;
auto bulletsIter = m_bullets.begin();
while (bulletsIter != m_bullets.end())
{
if (enemiesIter->get()->getSprite()->getGlobalBounds().intersects(bulletsIter->get()->getSprite()->getGlobalBounds()) &&
enemiesIter->get()->IsVisible() && bulletsIter->get()->IsVisible())
{
enemyDied = true;
enemiesIter = m_enemies.erase(enemiesIter);
bulletsIter = m_bullets.erase(bulletsIter);
m_PlayerScore += MAX_SCORE;
++m_bulletCount;
break;
}
else
{
++bulletsIter;
}
}
if (!enemyDied)
++enemiesIter;
}


Power Up Bullet

During this week I have not really worked on a single large ”artifact” that provides a good topic for a blog post. Unfortunately I also became sick yesterday so I apologize if the quality of this blog post is somewhat lacking. This week have mainly been about tuning already existing parts of the game, like adding animations. For example the new lane animations we have to provide the player with a visual separation of the three different lanes and also show the player the beat of the song with the lines twinkle in the same rhythm as the music.

We have also have some problem with a minor delay in the audio of when the player shoots the projectile and when the sound plays. I personally find it hard to hear this delay, but other people hear it more clearly. We have tried with trying this out in a clean new project with only the necessary parts to try it out, and also using the Windows API with help from our scrum master and finally trying this out in a SDL project. The delay remains.

One artifact I have created from scratch during this week Is the power up projectile. The power up is meant to be a huge sound wave spawned from the left of the screen moving to the right, clearing all enemies in it’s path. We have not created a sprite for this part of the game yet so I created a programmer art projectile in Photoshop to have something to draw on the screen and create collision with the enemies.

The code for this power up is simple, but not yet finished. The power up class is almost identical to the bullet class. I did this because the power up is in reality just a bigger projectile, the only difference is that this projectile can only be used when the player as picked up the power up.

I created a new else if under the GameState::OnAction using the action “AltFire”. At this moment a new PowerUpBullet is created here, but later we might move this to the PowerUpBullet so the GameState doesn’t get to large.

I had some linker error with the use of the math.hpp created earlier during this project to normalize a vector2f when shooting a projectile. I had used math::normalize(m_direction); in the bullet class ( math was created as a namsespace) and this created the problem when I tried to normalize the same m_direction two times in two classes. This was solved when I moved this line of code directly to the Entity.cpp.

We have not yet decieded how the player will receive this power up, but one way to do it would be to create an int that is added with one when the player kills a certain enemy. And while this integer is more than zero the player can activate the power up with the press of a button.

A screenshot from the game when the power up is activated. With my programmer art.

Dragon song – animations using Thor

With the alpha completed we began the work on the beta. I have mainly worked with the implementation of animation in our game. This blog posts will be about that topic.

Previously to this week I had never animated from a programmers point of view, I have had some very inconsequential experience with animating in flash. When I researched how to animate using SFML I found out about a library extension called Thor.  From reading the documentation I saw some functionalities that could be useful in our project, so after asking a second year student if he thought Thor could be of use for us I decided to try to implement it.

To use Thor in our project I first had to install Thor with the program CMake, and then compile it visual studio and finally link it with the project. This took some tinkering but after some time it worked.

The main reason I wanted to use Thor, other than its fun to learn new things, was that it included already made functions I could use to easier create animations with easy to read code. Later in the project when for example the player character receives more animations Thor has functions to easy switch between them, another reason I thought it worth to try it.

I will take on of the enemies as an example on how the animation code looks. Here is how the sprite sheet looks:

 

In the enemy.cpp the sprite sheet is set loaded from a file and then set to a sprite. Using thor::FrameAnimation the coordinates are set from the sprite sheet. We have different looking enemies in the game that is spawned using a txt file. Every enemy sprite sheet is created to have the same coordinates and consist of eight frames of an animation. This in combination of how the code is used allows for every enemy to use the same animation function, only with different sprite sheets.

Example:
m_animation.addFrame(1.f, sf::IntRect(0, 0, 256, 256));

m_animation.addFrame(1.f, sf::IntRect(256, 0, 256, 256));
Then I set the animation to a string that can be called on later to play and update the animation. And I can also set the length each animation will take in seconds. This value is easily changed, which allows for quick fine tuning and thanks too Thor it’s really easy to read this code.
m_animator->addAnimation("idle", m_animation, sf::seconds(0.46f));

m_animator->playAnimation(”idle”, true);

m_animator->animate(*m_sprite);

In the GameState the animation is updated and the animation starts when an enemy is spawned.

 

Here is a link to the Thor website : http://www.bromeon.ch/libraries/thor/v2.0/doc/index.html. I have only used Thor for animations yet, but I might look if there are additional classes that could be useful for our project.

Dragon Song – Gauge Meter

This week I want to talk about the “gauge meter“ that will play a big part in controlling how the game will sound in relation too how good the player perform during the game.

The music that plays during the level consists of different layers. The first layer is only the core beat while the second layer is a bass track. When the player achieve a certain goal (we have not yet decided exactly which goal that is but right now it is bound to reaching a score) the player will hear another layer of the music.

With the game we want to make the player feel like he or she is a partly responsible for playing he music. When the player shoots and when the bullet collides with an enemy different sound will play, and if the player does this while keeping the beats per minute of 128 the music should sound better then if the player only play the game like a regular space shooter. This is combined with the gauge meter that adds layers to the music to make it sound better and finally playing a complete track for the player.

It is important for the game to always keep the music in synch with the game play, and that the different layers are in synch with each other. Too make sure this happened I set all of the layers to play at the same time when the Game State is activated, and then I set every layer but the first one to volume 0.

Too try if this way of doing it would work I put in three different music tracks and played all of them at the same time in the Game State enter, and put all of them to volume 0. Then I set three buttons, the same we use to change lanes with the player character, to set one of the tracks to 100 and the other two to volume 0. It worked, but I could not check if the sounds were in synch as they were three completely different tracks.

When I received the actual layers of sound from the sound producer I changed the placeholder music with the new content. Now I could try if the layer were in synch with each other when actually implemented in our engine. From what I could tell it sounded like they were in synch and sounded good when played at the same time, but I have to show it for the sound producer and see if he agrees.

Concept for how the meter could look.

Project Dragon song

During this project our group will produce a game out of the game concept created by another group during another course. In the game the player have to follow a beat while shooting down at enemies, resulting in music playing. Very similar to playing drums on rock band.

As we are only two programmers in our group my task is primarily as a programmer. During this week we went into production after working on the prototype were we tried out different ways to create a beat meter (the player have to press the space-bar as close to the beat as possible).

During this week I primarily worked on the engine. We choose to use the project created by our teacher on the game programming course II as the engine. In this blog post I will write about the projectile the player will shoot. This part is not yet completed, but is essential for our game so I wanted to write about this subject. At this moment there is a class for the projectile, but depending on what we want the projectile to do we need different methods in the class.

The greatest challenge with the player projectile is how it will work and how we should write the code. As this is a music game the player needs to be able to shoot and hit the enemies in synch with the music. If we make the projectile to fast or to slow it will be hard for the player to feel a rhythm.

We have discussed a couple of ways to allow the player to shoot at the enemies while still allowing the rhythm of the game to continue. On way would be to make the projectile only visual. The enemy would be set to inactive when the key-input is pressed down and play it’s “death sound” after a set time. The projectile would only be an animation playing when the right key is pressed at the right moment. The other way is the traditional way of a projectile who collides with the enemy resulting in both being set to inactive and playing the appropriate sound.

This depends on how the rest of the game will turn out. The player won’t move on the x-axis so it may not really make a difference, but the collision may be wonky if the speed of the projectile is too fast. In both cases an “optimal score zone” could be implemented, were if the player shoots the enemies while their position is in that zone will result in both better score and sound that is in synch with the music.

 

A picture from the early alpha while shooting the projectile.

Space Invaders – Making the enemies shoot

One of my task was to make the space invaders shot at the player. We used block code in the Arcanoid engine as our enemies and the ball code for the projectiles the player can shoot. I thought the code in the ball could be reused for the enemy’s projectile so I created Bullet.cpp and Bullet.h using largely the same structure as the Ball.cpp and Ball.h.

I then used the code in the GameState for making the ball (or projectile) follow the player and activate when pressing down a key, and then used that in a bullet class. Now just one enemy would shoot, the first in the row. To make the enemies I needed to use a random function with the Bullet entity to randomize which enemy that would shoot.

I had some problems to create the random generator but Anthon Fredriksson helped me.

std::random_device rd;
std::mt19937_64 generator(rd());
std::uniform_int_distribution distribution(0, m_enemies.size() -1);
int random_enemy_index = distribution(generator);

Block* block = static_cast(m_enemies[random_enemy_index]);

Space Invaders – Key input

The Arcanoid code we use as the structure for the space invaders clone used mouse input to control the paddle. We wanted to use keyboard input instead so this had to be changed. This task should actually be rather simple, but I had problems to make it work. I spent a lot of time looking at the Arcanoid to figure out where the changes should be made and how to make them.

The problem lied in how I had written SDL_KEYDOWN and SDL_KEYUP in Engine::HandleEvents(). I didn’t understand how the SDL mouse input code worked and when I tried to look at that code when writing the keyboard input.

case SDL_MOUSEBUTTONDOWN:
{
int index = event.button.button - 1;
if (index 2)
index = 2;
m_input_manager->SetMouseButton(index, true);
}
I wrote code in the SDL keydown/up like: if(index <0), that resulted in that no keyboard input was registered. After reading code from earlier during this course, Pong, I finally realized the mistakes and wrote a SDL_Event that worked.

case SDL_KEYDOWN:
{
int index = event.key.keysym.sym;
m_input_manager->SetKeyboard(index, true);
}

Beginning of Space Invaders Clone

I have started with the final project during this course. The assignment is to make a clone of an existing game like Tetris or Pacman in c++ using the SDL library. I work together with another person in my class, and we choose creating a Space invaders clone as our project. We choose this game because it seemed to fit our level of skill in programming, we both have limited experience and Space Invaders seemed to be less complex compared with other games.

We plan to work together with git-hub or something similar, and both of us live in the same city during the Christmas break giving us the opportunity to have at least one meeting before we return to the university.

We will use the Arcanoid code provided to us by our teacher as a framework to our code, and my first assignment is to change the controls of the game from mouse input to keyboard input.

week 4

I have been terrible at posting in this blog, so I am some weeks behind with my blog right now.

This post is about the Kelvin/Fahrenheit/Celsius converter I did during week 3. I did write a fully functional code but realized that I just used ordinary functions, when the assignment was to create a class.

I had some problems understanding classes and splitting code into header and cpp files before, but completing this assignment greatly helped me understand how this worked. The assignment weren’t really that hard, but I have found that while I sometimes can understand the code the teacher shows us during the lectures it still can be a challenge to use that knowledge.

Here is the code I wrote in my header file:

#pragma once

class TemperatureConverter
{
float x;
float answer;
public:
/*int convert;*/
TemperatureConverter();

/*int choose(int);*/

float Farenheit_Celsius(float);
float Farenheit_Kelvin(float);
float Celsius_Farenheit(float);
float Celsius_Kelvin(float);
float Kelvin_Celsius(float);
float Kelvin_Farenheit(float);
int getType1(int);
void GetValue();
void Answer();
};

 

And just an example of how I used it:

cpp:

float TemperatureConverter::Farenheit_Celsius(float y )
{
x = (y – 32.0f) * 5.0f / 9.0f;
return x;

}

main:

if (choose == 1)
{
tmp.Farenheit_Celsius(temp);
tmp.GetValue();
}
else if (choose == 2)