Root implementation

Time once again for a blog post, this week I’ve been working mostly on my project report, but I’ve also been looking on some tweaks for the game. I have been working with trying to implement roots while underground which would give the player hints on where the vegetables on the top level is. However, this wasn’t too complicated.

The way it was done was basically to add a texture and a sprite to the constructor of the vegetable class, this is also where we create all our other vegetables. I set the position of the roots to the position of the strawberries. In our draw function in our gamestate we have a for loop which draws all our vegetables on the screen. I did the same for the roots, but for the underground level. So whenever the player takes a vegetable and it gets invisible, the root for that vegetable also gets invisibile.

This is how the roots look like while the player is underground. If i would take a strawberry on the top level, the root for that strawberry would also get invisible. We added the roots to give the underground some ”life” if the roots wouldn’t have been implemented it would basically have been a brownish background with some tunnels in it, which wouldn’t be so satisfying for the player. The roots will help the player to orientate when he is underground.

Other than the roots, we currently have quite an annoying bug that I’ve been working on but haven’t been able to fix just yet. The ones who have seen our game on the beta presentation probably remembers that whenever the player would eat a vegetable, he would gain a minor speed boost for a short period of time. But if the player would dig up on a vegetable, he will start moving backwards. I’m not quite sure why this happens. When the player eats a vegetable we set a bool to tryue and if that bool is true we start a timer. As long as that timer is under 0.5 seconds the player gets a speed increase with +4, and when the timer goes above 0.5 seconds, the players speed will decrease with -4. So the timer keeps on going, which isn’t that strange since we reset it as soon as the player picks up a vegetable, the weird part is that the timer won’t reset if the player would dig up on a vegetable, so I’ll have to take a deeper look on what the issue really is. Hopefully it’s an easy fix.

”Final touch”

My work this week has consisted of tweaking our current work. Balancing it and giving it a more final look. This had to be done due to the beta deadline and since all of our planned objects to the game already has been implemented we figured we’d put all of our time just tweaking our work and get it ready for beta.

So, I have reworked the eagles behavior a bit.  The arrow shows the eagles movement while it’s still just a shadow that’s scouting for the mole. This is pretty much the same as before, it’s moving with a sine wave movement with an additional hitbox in the form of a rectangle shape which stands for his ”aggro range”

This other photo is where the change shows, instead of just changing the eagles position to -64 on the x-axis, I changed it to 1400 and gave it a velocity of -50, so that it comes from the opposite way. This will make it easier for the player to avoid the eagle. Before I did this change, the player could be seen by the eagle at the top left corner, and then get caught without even seeing the eagle. This way the player will always either be able to see the shadow of the eagle, or have time to dig down to avoid it.

I also changed the animation of the sonic spike trap, making it look more like a trap, during the playtesting we got the feedback that it looked kind of like a sunshade which didn’t really make sense. So this has been changed by just changing the texture, so no big deal.

I also added a boundary for the level, so that the player cannot move outside of the screen level. This was done by adding 4 if statements saying that for an example if the player is higher than 1268 pixels on the y-axis, it would set the players y-position to 1268, giving the player kind of like a ”pushback”.

This is the ”largest” changes I’ve done this week, nothing big. It feels good that we don’t really have any more features to implement, all that’s left is just balancing the game and adding some more graphics, and we should be all set.

I have also made some minor changes of the balance of the game, like increasing the stuntimer when throwing rocks on the gardener, or changing some numbers on the powerups and so on, so just minor balancing work.

Other than that, the beta presentation of our game is tomorrow, and I think we’re in a good phase right now, I hope it goes well.

”Sonic spike trap”

This week I’ve been working on implementing another object for the game, the “Sonic spike trap”. The main purpose for this object is that it will serve as a distraction for the player. As you can see it’s a circle shaped sprite with a blue circle outside of it. The blue circle is the traps “aggro range” which means that the player can’t enter unless it’s destroyed. Think of it as some kind of sound waves that this trap emits which forces the mole to stay away from it. Later in the game we will add some bonus objectives that will be under this trap, so that the player will have to “waste” one of his rocks to destroy the trap in order to get these objectives, which isn’t mandatory for a win condition though.

In order to get this object in to the game I just added a sprite and gave it a position, but it’s also animated, giving it kind of like a lightning effect on the inner sprite, and the blue circle outside of the sprite goes further away from the sprite and then back in again. In order to get a correct hitbox for this object I added a rectangle shape at the sprites position which I don’t draw on the screen, and instead of checking the sprites global bounding box I check the rectangles outer lines for collision. I did this since the sprite will change its texture size at some points since it’s an animation, but I still want the hitbox to be at the max range of the sprite. The collision is done by checking the moles global bounding box and the rectangles global bounding box, if they collide we just push back the mole.

I also added a finite state machine for the trap, giving it different states, three states to be more specific. The first state is when the trap is active and where the mole can’t enter it. Another state is when the trap has been hit from a rock which will change the atlas that the animation is on, making it look more like “broken” and when that animation is done it will change to the broken state, where we just have a broken trap which does nothing special. The finite state machine is done by using a switch and different cases by predetermined enums in the header file. By using simple if statements you can easily switch between different cases, giving the object different behaviors.

On Monday we will have play testing where we will have the opportunity to collect feedback and give feedback to other groups as well before the deadline of the beta of our game. Until then I will work on trying to get a working score system.

”The eagle”

This week I’ve been working on implementing the last aspect that will serve as a threat for the player, the eagle. The player can at random occasions see an eagles shadow on the ground, if the player would move into the shadows aggrorange, there will be a sound playing which will be kind of a screech to simulate an eagle. After a period of time, which will be decided upon later in the process when we start to balance, there will be an animation playing which would simulate the eagle sweeping in from the side of the screen, picking up the mole, which would mean game over for the player.

So, at this part of the game, the player will have to react fast to the screech to avoid the eagle by digging underground as soon as possible.

As you can see in the photo, there is a shadow, this is basically just a sprite that has some movement. At the moment this movement is in the form of a sine wave from left to right. As soon as the eagle goes out of the screen, it will be moved to the -64 x-coordinate to simulate it coming in from the screen. The movement shall be different on beta, but as for now it’s just a simple loop with a sine wave. We have been thinking about giving it random locations that it will move to with this sine wave, this would make it more lifelike and not giving the player the perception that it just loops from a given position to another.

The eagle won’t be there at all times either, the shadow will sweep in at a random time, which we haven’t really implemented yet. But we’ve been thinking about sending it in every 30-40 seconds and give it a lifetime for about 10-15 seconds per time.

We decided to implement the eagle since we don’t think we will have the time or knowledge on how to make the gardener “smart”. We don’t really have any knowledge in working with AI at all. At this point the gardener just moves to the players position, which isn’t optimal at all. We will code it so that the gardener moves between different nodes and if the players gets in the gardeners aggrorange it will try to catch the mole. Since we can’t really make the gardener as much of a threat as we would want to, we had to make it more risky for the player to be on the toplevel by implementing something else, so we came up with the eagle.

The output of a sine wave is determined by this algorithm;
“y = amplitude * sin(frequency * time * phase) + bias”

By giving the eagle the movement of this algorithm,
it will give the movement the output shown in this photo;

Destructible terrain

I’ve been working with the background and foreground implementation of our game during the last and this week. What I mean when I say the background and foreground implementation is more like a bitbased map.

At first when we started working on our game, we had this mindset of going with a tilebased map, since that was what we knew how to program. However we felt that it would make the gameplay while underground worse. It would feel choppy and not as free roaming as we want it to be. If we would have gone with a tilemap, it would feel more like an arcade game while digging those tunnels. So we decided to go for a bitbased map instead. A bitbased map is used in worms for an example, where the destructible terrain feels kind of free for the player, and not so rough.

So, the implementation of a bitbased map is quite easy at first, but is hard to perfect. First off you add two backgrounds, so basically just two sprites as large as the screen size. When I had added them, I had to convert the sprite that’s used for the foreground to an sf::Image which is done by using GetTexture() and CopyToImage(). After that I added a function to the image called createMaskFromColor which basically makes a color on the image transparent, so I put the color Magenta to be transparent. That’s basically it for the background and foreground implementation. This is a quite performance demanding task to do though. Since every time the image is updated, it gets copied to the graphics card, the screen clears and then the updated image is drawn out to the screen again. First we had two very large sprites used for this, so whenever we made the tunnels underground the game would crash, so what we had to do was to break the sprites down to smaller files. It’s still quite laggy though, we’re still working on how to break the sprites down even more.

To dig a hole underground we basically just create a circle shape in the color of Magenta, which makes the circle transparent. Making it look like the player is digging a hole, but actually just drawing a circle.

In this image you can see that there is two sprites, one that is darker, this is the background. And one that is brighter, which is the foreground that I was speaking of earlier. The tunnels are just circle shapes made transparent on the image, which makes it look like the mole is digging tunnels.

Mole Munch

So, it’s time for another blogpost, this time it will be about our current project. We have been told to design a game based upon another groups concept that they created in the last gamedesign course.

We decided to pick the concept “Mole Munch” which is about a mole that tries to eat all of a gardeners vegetables, the gardener isn’t quite too fond of this of course, and will therefore give pretty much everything he has to catch this mole.

During this week I’ve been working a lot with the camera of the game, along with other objects. But I decided to write about the camera. I’ve been trying to get it as suitable as possible in regards of the gameplay. We made a decision about the moles movement, you can basically just move forward or backward, there is no sideways. So to be able to turn around you’ll have to rotate your mole, and then move forward. I’ve taken this in consideration when implementing the camera. So whenever the mole is rotating, the camera is also rotating at the same speed, while it also centers the position of the camera to the players position. So basically what the camera does is that it always follows the player, centers it at the players position and rotates whenever the player rotates. This has been done basically by using sf::View in the code, so nothing too hard.

At this point we have two different “states” in the game, one where the mole is on the top level, running around on the grass trying to pick vegetables while staying away from the gardener. And one where the mole is down in the underground digging holes and getting power ups.

How I described the camera earlier is how the camera works in the top level, while it works a bit different while down in the underground. Down there I’ve added a sprite that is as big as the screen size. The sprite is black on the sides while getting more and more transparent while going towards the middle. So basically it is just a sprite that is rotating at the same speed as the mole, just as I did on the top level but instead of using sf::View I added a sprite that worked as a camera. We did this to give the player less vision while underground, since it’s quite logic. The mole shouldn’t be able to see the whole map since he is just in a quite small tunnel. We have been thinking about making the vision even less, but that will have to wait.

When I first started with the camera, I had the sprite on the top level as well, but we decided to take that away since it made the game a bit too dark. We wanted the player to be able to scout a lot when he is on the top level, and then having to go down under the ground when he feels threatened, but that would also give the player less vision and the vision of the vegetables would also be gone.

This is how the top level looks like, as you can see, the camera has rotated a bit. This is due to that the mole has been rotated as well. The mole has quite a big view, which gives the player possibilites of quickly scout the area for vegetables and other interesting objects. Then go down underground for safety.

And this is how the underground camera looks like. As you can see, this is basically just a circle in the middle that is transparent, showing the background and the mole. And going more and more less transparent until it gets to the black.

Programming – Bomberman

I have made it back to Stockholm to spend the holidays with my family, however during christmas im going to work on creating a copy of the original game Bomberman with a classmate of mine. So far we’ve been able to program a window, so what we’ll have to do from now on is basically to add each of the objects and give them their own properties. The objects are Player1, Player2, Bombs, Walls and Boxes.

I’ll be sure to keep you guys updated on our work process.

Programming week 5 – Final build of Arkanoid

We have completed building the game Arkanoid and I’ve had loads of fun doing it, it’s also been quite hard understanding each line of code, but I think it’s gone quite well.

So we are soon done with the course, what remains is next week with some lectures on collision and how it works. Then we’re supposed to build our very own game, either as one or in groups of two. Me and my classmate has decided to build the game Bomberman and I think it will be quite amusing to see how it will work out since there is loads of things to keep in mind when programming.

I will keep you updated on our work in progress over the next coming weeks and I hope I will be able to give you guys a final release that’s actually working.

Until next time, have a good one!

Programming Week 4

This week we started building on our second game – Arkanoid. This project is a bit more complex though since we’re actually building this game from scratch. Our teacher is livecoding while going through each line of code, it’s interesting but very hard!

We’ve learned more about inheritance, which is that you can create an original class, and then you can create another class which can inherit the original class’ values.

We have also started discussing something new – Polymorphism, which is what the name virtual in the image stands for. Polymorphism is one of the most important concept in object oriented programming and it is a mechanism that allows you to implement a function in different ways. For instance, the method ”Draw” in the image can behave differently depending on which state it’s in.

Programming week 3 – Classes

This week we have been going through Classes and Class Inheritance. which felt like an easier concept to grasp than the previous, since we had already been working with this a bit when creating ”Pong” earlier in the course.

Classes are just like variables different data structures that can be called within the main function, they can have different functions inside of them. That way we can use classes to reduce the amount of code we have to write, making it a lot less painful to actually code millions of lines of codes day out and day in.

What Class inheritance means is that you can create a class, then create another class and let it inheritance all of the public variables or methods in the original class. It’s messy, I know.. But for instance if you create a class named ClassExample, and give it the variables int x = 0 and int z = 0, you can easily give another class those variables as well. By typing for instance ”Class InheritancedClass : public ClassExample” you will pass on all those variables to the newly created class, saying you inherited them.