Two days before GGC – Where are we at right now?

So we’ve been working on this new game for a bit more than a week now. A lot of things have changed in the game since we started working on it. We’ve managed to add a checkpoint system, a few different monsters with different mechanics, a smooth fighting system with two different attack styles, healthpickups, animations and a lot more! For the most part, I’ve been doing things like our different systems and not so much work on the balancing and animations. For a week worth of time, we’ve sure managed to get a whole lot of things into our game.

Our game gets inspiration from games like Dark Souls, where the player should feel at a disadvantage until they learn how to play the game. Therefore, we have some hidden mechanics that players will notice the more they play the game. We’ve also made the fights quite hard to prevent players from just running in and hitting opponents until they die. But since this current build is meant to work for the general GGC public aswell, we decided to add checkpoints into the game so that players wouldn’t have to spend so much time walking back to where they were after a death.

We’ve been having some very late nights, and it has made us realise a very important thing: Something that seems hard is generally considerably easier the day after. Often, we spent a couple of hours trying to find errors or fix bugs in the code or animations, only to find it within seconds the day after or with some extra eyes to look at the issue.

But all in all, we’ve managed to make a game in just a week that the team really wants to show to the GGC audience. And we’re even considering a continuation of the game afterwards, where we’d rework some things and rewrite a lot of code in a clever and better way. But that will be on our minds after GGC, only thing on our minds right now is the last day before GGC, friday, where we have to implement the last parts in the game, like win condition and menusystem.

Så, vad har hänt?

Har inte skrivit på ett tag, men det har hänt en hel del med spelet. Efter att ha gjort om själva linjesystemet med tillhörande checkpoints och liknande ungefär 5-6 gånger, så hade vi tillslut en hyfsat färdig pre-alpha. Tyvärr var den färdig efter alphan och vi tog spelet till speltestning. Där fick vi det bekräftat det som vi hade trott, spelet var inte alls kul att spela och designen var helt enkelt för dålig. Mer om vad vi gjorde för att ändra spelet och var vi ligger just nu kommer i morgondagens blogpost.

Så under dessa veckor, då jag glömt att blogga ett antal gånger, så har mycket gjorts om i spelet. Vår LineRenderer Component vägrade fungera som vi ville och efter ett tag tröttnade vi på det systemet och bestämde oss för att komma på ett helt nytt system, vilket skulle bli vårt sista system. Istället för att använda LineRenderer valde vi att gå över till prefabs som spawnas längs linjer. Vi kom på att spelet faktiskt inte behövde en dragen linje, det enda som behövdes var att simulera hur en linje dras genom att alla sprites på linjen byter färg beroende på om de har blivit aktiverade av vår nervsignal eller inte. Med detta system var det inga problem att få fram endPosition och när man gick utanför linjen. Det var inte mycket kvar som behövde läggas in, men mycket tid hade behövt läggas på att finputsa spelet. Så det var antingen att fortsätta jobba med ett projekt som ingen längre trodde på, eller gå över på något helt nytt. Vi tog, efter att ha konsulterat med Adam Mayes och Håkan Mattsson, beslutet att göra ett helt nytt spel från början.

Det blev ingen lång bloggpost idag eftersom det mesta som har gjorts är att bygga om samma LineRenderer Component på olika sätt, de flesta icke-fungerande. Men imorgon bör den bli ansenligt längre då det nya spelet kommer presenteras samt vilken framgång vi har haft hitills!

The initial weeks of BGP have ended!

So me and my group have now been working 2 weeks on our big game project, Synapse. Since we were a group which was formed late and with an unfinished (at that time) concept, the initial part of the project was put on finishing the idea of the game. Our group consists of 6 2D artists who have various tasks and 1 programmer, myself. Since I’m the only programmer I’m also in charge of making sure that the technical things needed for the game are working properly. But since the game doesn’t require much more than a touchscreen for it to work, this task isn’t too difficult.

After the initial part of the project was finished, I began working on an early prototype of the game to see how it’d work and to test our main mechanic; moving a nervecell to a certain point in the brain to mimic brain behaviour. First thing that I wanted to create was a way for the player to draw a line in the game. With the help of some tutorials using Unity’s LineRenderer, I was able to come up with a system that worked quite well. However, I had some issues with the line colliding with objects the way I wanted it to. So I ended up scrapping the system and move on to another one that hopefully would fix the issue I was having.

The idea is that the player should draw a line along a pre-defined line and to know approximately where the player is, checkpoints were added. The checkpoints are also there to prevent the player from drawing lines outside of the pre-defined line in order to cheat their way through a level. But this system also had a slight flaw. It was designed so that the player would only click and the line would draw itself. But I had to change it so that it was the player drawing the line instead. So I ended up adding my old system to the current one. And after a couple of tweaks to the code, it was working as intended and the early prototype was therefore finished.

The prototype took slightly longer to finish than I originally anticipated, but a major factor to why it took longer time was because I got sick 2 days the 2nd week of development which hindered my work substantially. And since I’m the only programmer, when I’m sick the whole coding part is frozen in development. But luckily I got healthy quite quickly and was back up working. Now all that is needed is further coding to implement graphics, and also to implement some challenges so that what we have is more of a game instead of a drawing simulator.

Last blogpost for Mole Munch – Fixing syntax in code

Hello! We’ve now reached the final blogpost for our Mole Munch project. Our beta presentation went well, but as a group, we didn’t feel like we wanted to add a lot more things to our game. Some adjustments were decided to be made, especially on the coding side, but most art will remain intact. The reasoning for this decision was that we all wanted to focus on our project reports. But we also felt a bit fed up with Mole Munch by now. We’ve been reworking things on it from time to time, and it felt like it’s time to finally move on.

Since we didn’t really feel like adding a lot more things, there isn’t any artifact that can be written about this week. Instead, I’ll be writing about what I did, which was looking through all the code to make sure that the Syntax looks good and that every function/method/variable has a reasonable and well-describing name. This so that a function handling player movement isn’t called something like ”X” or ”Whatever”. Since it was three of us who wrote code (three programmers), the code looked different depending on who had written it. Therefore, a challenge with fixing the code was to make it still look like everyone had written code. I didn’t want to make the code look like it was written by one person. As of the writing of this post, the code is not finished, but it’s starting to look better and better.

The syntax also matters since we’ll be handing in the source code for the Spelprogrammering II course. Therefore, I took it on me to look through the entire source code so that it all looks good codewise. This is for readability in code, but also because the syntax for writing code should follow a certain pattern. Below is a picture made to illustrate the difference between good syntax and bad syntax (the picture is made by me, therefore there might be some small errors in the syntax, but it should be relatively correct). For exact way to write syntax, look up a site like http://www.cplusplus.com/ or similar.

Apart from rewriting code, there wasn’t a lot else that could be done since we decided that we didn’t want to continue developing the game. So this was my blogpost for this week! It wasn’t really about an artifact I worked on, unless you want to consider the entire code an artifact in itself. But this is what I did this week, apart from working on my project report. Thanks for me!

Last week before Beta presentation, adding a tutorialscreen

Hello reader! Compared to how we felt one week before our Alpha presentation, our group is feeling a lot better when we go into the Beta presentation. During the Alpha presentation, we had only really basic gameplay without objectives, and no graphical implementation at all. We also lacked things like powerups and a projectile. To be fair, it didn’t look like a mole doing anything at all, it was just a square picking up squares being chased by squares. While the mechanics for that was good, we lacked the graphical implementation that would make the game a lot better.

However, for this presentation, we’ve added a lot of things to the game. We’ve added powerups, projectile, graphics, an objective, tutorialscreen, menuscreen, and a way to lose the game. It looks a lot more like a game, and we’re proud of the gameplay we’ve managed to produce. It’s not a very advanced game, but it’s enough to be a lot of fun and challenging to play!

So this week I’ve been recovering from when my code disappeared, and rewritten the code to make it work, even better than before. I say it’s better than before because it’s now written in a better constructed way, and not random code slammed together to make something work. I worked a lot with adding a tutorialscreen after pressing the Play button. It wasn’t as easy as I thought it would be, and it ended up taking a lot longer than I thought.

As it is right now, the tutorialscreen shows up during the switch between MenuState and PlayState. What I did was to add a picture to PlayState that covers the entire window. This picture shows information on how to play our game, and it currently has a fading animation that makes the tutorialscreen fade away after some time. This is just there for a cool effect, and the code for it looks like this:

The time is currently set to be around 10 seconds, but it may be changed depending on feedback. It’s also possible to just skip through the tutorialscreen instantly by pressing Enter. We wanted to have a tutorialscreen for the player because we wanted to have some way of telling the player how to play the game. We thought a tutorialscreen would be an efficient method to give the basic knowledge of the game to the player, without taking away time from them to test out our game.

I’ve also been working on other things this week, like getting the projectile to work. It’s now implemented in the game, and will soon have collision done so it works as we want it to. I also added collision to the MenuState when pressing the buttons. And for the final version, I will be adding a credits button that will show the names of the creators of the game. But that’s it for this week, and if you play our game, you’ll see this tutorialscreen before starting:

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.

 

Week 6 in game programming (delayed blog post)

This week we went through how to add text into a game. This was done using SDL, and works similar to how you insert images in your code. We also went through advanced collision briefly, for example the different kinds of collision, and how to make circles collide and such. For some weeks now, I’ll be working on my Bomberman project together with Ludvig Storm, so far, we haven’t gotten very far. But we’re agreed on what needs to be done, and we’ll decide very soon on what to do individually, and what to do together. The ferry back to the mainland for christmas ”holidays” was spent coding the essential parts of our game, but a lot still needs to be done.