The importance of using backups

This week, I’ve been working on improving the projectile and MenuState I’ve been working on before. My goal was to be finished with both the complete MenuState and the projectile by the end of this week. The reason why I wanted it done before this weekend is that our beta version of the game is coming up, and we want to finish things that are essential for our game. From former blog posts, both of these things are relatively finished by now, only requiring a bit of final touch to their code.

The MenuState was working as intended, with a few features still yet to be implemented. What still needs to be implemented for the MenuState is:

• Collision for the buttons, so that you can click on them and get a different output depending on which button is pressed.
• A button that handles the instruction on how to play our game. However, this one might be replaced by loading a how-to-play picture before loading PlayState once you’ve clicked play.
• Highlighting animation when you hover over a button.
• Some graphics still needs to be finished before being implemented

The projectile, which was almost finished, has been worked on for quite a while now. It has always been doing its best to make me confused to why it’s never working as intended, but I finally got the last bits of it to work before applying collision to it. But then, due to some issue regarding SourceTree, all my work with the projectile was suddenly lost today. What happened was that SourceTree prompted me to use an older version of the project than what I was using. I’m not entirely sure what really caused this, but I have a feeling it relates to different repositories using same names for the project, where when I was trying to pull the newest version of our game, the old repository with my test version got changed aswell. And even though I ignored the messages of replacing all files, I suddenly sat there with an older version of my project. Luckily, we had just started merging our code together so that the MenuState was in another project and therefore not lost. But all code about the Projectile was lost, making me have to rewrite it tomorrow from scratch. It shouldn’t take too long, but it’s a distraction from other things that needs working with before the beta version has to be finished.

So with this blogpost, I want to point out what I’ve been working with. But also to remind you what could possibly happen if you don’t have any backup for the files you’re currently working on. Sure it’s easier to rewrite it than to write it from scratch, but doing same thing you’ve already done before just because of some random issue, can be a bit annoying.

Luckily we had another repository with the newest version, so only some projectile code was lost during this issue. So at its current state, without the bullet, our game now looks like this. It’s not finished, but with our latest version without major bugs, the productivity will increase due to time being spent on coding instead of fixing errors while merging code manually between projects.

Programming a Menu for our Mole Munch project

Recovering from the hectic last week where we had to code so much, especially the last days before our Alpha deadline, we now look towards the Beta deadline. Several things still need to be implemented: powerup, improved projectile (the object I was working on last week), graphics and some other things. This week I will be finishing the projectile completely and I’ll also be implementing graphics to our game. But this blog post will be about what I’ve been working on for the most part this week, our menu for the game. The menu is meant to be a way for the player to start or exit the game when they boot up the game. There’s also a button for instructions that displays a picture showing what buttons are used in the game, and what the objective is.

The menu contains 3 different buttons; Play, Instructions and Exit. By clicking on play with your mouse, the game will call for the function GetNextState(); which will get the player onto the next state, GameState. By clicking on exit, the game will stop running by returning the bool m_running in Engine.cpp to false. This will make the whole game stop, since that variable decides if the game is running or not. If instructions button is pressed, a sprite will be loaded displaying information that the player will need in order to play the game.

The menu is handled by the class MenuState, which shares some functions with PlayState. Functions that are shared are: Enter(), Exit(), Update(float delatime), Draw() and OnAction(). These functions are all inherited from the class AbstractState, which contains virtual functions that the different states can inherit. The different states are being handled together by the StateManager class, which has some useful functions that help manage the different states.

As of the time of this writing, the MenuState is almost finished, it just needs some final polishing. The different sprites aren’t completely finished either, but these will be added to the code as soon as they are done.

Below is how the buttons will look like, but the complete menuscreen is still being worked on so for now what is best shown is the buttons. An instruction button will also be added eventually.

The buttons will be able to be clicked using the mouse, but when the game starts, the mouse will be invisible since the game is played using keyboard. Showing the mouse in the PlayState won’t be any beneficial, but for the MenuState, it feels like the player should be able to click the different buttons instead of having to press the keyboard to access what the buttons are going to do.

Making a stone projectile for Mole Munch

This last week before Alpha deadline for our game Mole Munch has been hectic. Our coding planning has not been the best, and this week we have been paying for that mistake. We still had a lot of things that needed to be implemented for the Alpha. Luckily, our game designer came to help us this last week so we could get the coding done faster. One of the things I coded this week was the projectile that our mole can shoot. It’s a stone that will stun gardeners for a set amount of time (not defined yet). The reason why we added a projectile is so that the playercontrolled mole can stun gardeners who get too close, allowing a chance of escape. However, the player is limited to shooting one stone at a time, so they can’t just spam stones against gardeners to make the game easier.

The stone has three different functions that defines what it’s supposed to be doing: void UpdatePlayerStones(float deltatime), void SpawnPlayerStone(const sf::Vector2f& position, float direction) and void DespawnPlayerStone(unsigned int index).

UpdatePlayerStones updates the stone and sets its position and speed everytime it gets updated. It also despawns the stone if the stone reaches a wall or an enemy.

SpawnPlayerStone checks with an if-case if the stone count is 1 or if it’s 0. If it’s 1, a stone will spawn and no more stones will spawn until that stone has despawned.

DespawnPlayerStone checks how many stones the player has, and defines when a stone will be spawned again after a despawn. The code for this looks like the following:

The different functions aren’t too complicated to understand, but it still took some time to get them to work the way I wanted to. The reason for the longer time is that we’re rotating our game, which makes the collision and direction of the stone a bit harder to code.

The stone is important in the game because it can provide an escape from gardeners without having to dig down into the ground. However, in a future version of the game, we tend to implement an AI to the gardeners which will make them enraged after the stun duration, making them move faster towards the player for a short duration. So you’ll have to be more careful about shooting since the gardeners will be moving with a speed that is a lot higher than yours. Which means you won’t be able to escape very easily.

An early version of how the stone currently functions in the game looks like the following:

The stone has been fired from the mole, and is moving towards the NE of the map. The stone was coded with basic graphics implemented, meaning the background doesn’t look like it will in the game.

PlayerMole

Den här veckan har jag arbetat med den spelbara karaktären i vårt spel Mole Munch, mole. Det var ett antal saker som vi i gruppen ville att vår mole skulle kunna göra till vår Alpha. Vi ville att den skulle kunna:

• Byta mellan SurfaceMode och DigMode (vi använder oss av gradvis osynlighet för att visa att vår mole är under ytan i vår Alpha)
• Röra sig med hjälp av piltangenterna (normal rörelse)
• Plocka upp grönsaker genom att gå över dem (ger poäng, poängen implementeras i ett framtida poängsystem)
• Få Collision med objekt i vår spelplan (enkel collision till att börja med (väggar etc.))

1. SurfaceMode och DigMode är de olika modes som vår mole kan befinna sig i. I SurfaceMode är vår mole helt synlig, och han rör sig med en konstant hastighet. Dessutom måste vår mole vara i SurfaceMode för att kunna plocka upp grönsaker från spelplanen. I DigMode rör sig vår mole med den dubbla hastigheten av SurfaceMode, och mole blir halvt osynlig för att symbolisera att den är under jorden. Vi har dock planer på att lägga till dirt trail istället för osynlighet, men detta är inget vi har satsat på till Alpha. Som spelare kan man byta mellan SurfaceMode och DigMode när man vill, genom att klicka på Space. Detta sker genom en if-sats. I if-satsen finns det en bool flipped som kollar om man är i SurfaceMode eller DigMode. Vad som sker när man trycker på Space bestäms av en if-sats som sätter transparans och dubbel hastighet, och en else-sats som sätter vår mole tillbaks till originalvärden (startvärden).
2. Rörelse styrs med hjälp av piltangenterna. Mole rör sig med konstant hastighet, if-satser kollar vilken knapp som är intryckt, så att man rör sig åt rätt håll. Vilken hastighet som man rör sig med beror på om SurfaceMode eller DigMode är aktivt, som nämnts tidigare.
3. Spelet går ut på att ta en viss mängd grönsaker som spawnas med hjälp av en rand funktion på olika platser. Anledningen till att rand funktionen bara spawnar grönsaker på vissa ställen är att vi inte vill ha grönsaker som spawnar i objekt i spelet. Genom att gå över en grönsak sker en collision som gör att man tar upp den och i utbyte får man poäng. Dock får man ännu inga poäng för att ta upp grönsaker, detta implementeras i en senare version av spelet.
4. Som spelare kan man inte gå utanför spelplanen, detta hindras med hjälp av if-satserna för movement, som bara fungerar om mole befinner sig på en position inom spelplanen. Annars stoppas rörelsen och spelaren kan inte fortsätta utanför spelplanen. Collision med objekt i spelplanen är det sista som behövs till vår Alpha, och det kommer bli implementerat så snabbt som möjligt. Vårt spel är isometriskt,och kommer  ha tilebaserad collision. Så detta blir det sista som mole kommer få innan Alpha.

Just nu arbetar jag med hjälp av placeholders medans våra grafiker gör färdigt våra riktiga figurer och objekt.

Här nedan syns skillnaden mellan DigMode (halft osynlig) och SurfaceMode (synlig) i tidig pre-alpha. Ingen bakgrundsbild är färdig för tillfället, utan en placeholder grid användes istället.