This Monday we had a play testing where we got very much and good feedback. But one thing we have been discussing in the group is the downtime in our game – the time where there isn’t much to do in the game. For example when you have killed a boss and have to run all the way back to the beginning and you probably have killed all the enemies on your way to the boss already. Or if you die and have to run back to where you died, and the same thing there, you have probably already killed all the enemies. This downtime is something we want to get rid of. We have discussed doing this in three ways.

1. Teleportation. When you have defeated a boss we have discussed to put some sort of portal back to the beginning. This might be needed since the level  is built like it is, there are one boss at each end of the map so you have to go back all the way from one boss to get to the next and then back to the beginning again to get to the last and final boss. The plus is that the downtime will be drastically reduced, the negative is that if you haven’t found all the hidden rooms or all the textiles, you have a second chance if you run all the way back. This of course is something the players will have to decide themselves if they want to teleport or run, if we implement it.


2. Destructibles. One thing that might make it more fun to run all the way back is if there are stuff you can shoot and destroy. To fit our theme in the game we have discussed having some eggs along the path that the player can destroy just for fun. And if we add achievements to the game (if we feel like it and have the time, it’s not something we have planned to implement) that could be a fun one, to find and destroy them all.


3. Checkpoints. As it is now, when you die you start from the beginning again forcing you to run all the way back to where you died, with nothing to do (if you had killed all the enemies the first time). So our solution to this is adding checkpoints in the hidden rooms, so if you die you start from the last checkpoint you passed.


The only one of these that we have decided so far to implement in the game are the destructibles, the eggs. We’ll see if the rest is going to be implemented as well if we have time.


Bosses implemented

This week I have finally implemented the AI for all our three bosses, and tried to balance them somewhat. I will explain some of the balancing in this post, for the bosses’ different AI take a look at my previous post from last week.

I started with our boss Grubby McGrub (the whack-a-mole boss). When he shoots up from the ground he will shoot some slime at you. I started with one, aimed at the player, and then added four more shooting out from him in the directions of a + and an x:


After some testing from Ludde in my group he complained about how easy it was to avoid the slime, so I added 24 more!


Now it’s very much harder to avoid the slime, especially since he shoots up from the ground almost right beneath you. You only have a very short time to move from where he comes up from the ground, the only thing alarming you is the cracks in the ground. This I also had to balance some since first I set it too low, you didn’t have a chance to get out of the way. Now you can barely make it. I still have to balance his life and damage but that will happen sometime next week. Then I have to try all the set bonuses and without any textiles at all to find out how much is the right amount.

Then I started with the boss Ben Bugger (the kiting boss). The things I have balanced with his fight is how often he shoots his slime, how slow/fast the player and the boss will run while in the goo and while not in it.


At first I managed to forget to reset the timer that decided when to increase the boss’ movement speed so he got a really high speed almost directly as the fight began so the player was unable to run away from him. This I discovered pretty fast and also changed the timer to a shorter time since we want him to be really fast and annoying. He won’t be super-fast though since when he is in the goo or he hits the player his speed reset. I believe he is still a bit too fast, since the player has 500 in speed and the boss starts with 400.

As with Grubby I still have to balance the health and damage for Ben, but it’s the same problem – I have to test all the possible combinations of textile.

The last and final boss I haven’t balanced that much yet, it’s not that much to balance since he won’t do any damage himself, and all his minions are already quite balanced. The timer for when he spawns his minions is quite long, but the thought is that he spawns them when he reaches 75%, 50% and 25% of his life as well. It’s his health I have to balance later.

AI for the bosses

Even though I have been home with a fever this week I have tried to do some work from home. I have been drawing some sort of flowcharts over the three bosses AI. The boss I am going to start with when it comes to code is the final boss, Mothgomery. This because if we run out of time we think this is the most important one for the game. He is the “emperor of the suit” who started the invasion and leads the other bugs.

First when you enter the room with Mothgomery all the exits close, then Mothgomery says some cool line to start the fight. Mothgomery then has two phases in the fight. He starts in phase 1 where he is invulnerable and he lets four of his minions (Buggers and Grubligs, the normal enemies) fight to protect him. When all his minions are dead he will enter the second phase. Here Mothgomery is vulnerable, he stays in this phase until he is down to a certain percent of his life or (if it takes too long time) the time is up. Then he goes back to phase 1 again. This goes on until the player has killed him, and wins the game. The minions will have a different AI than the normal bugs, they will always be in their chasing AI so they follow the main character, Barney, wherever he goes.


Before you can challenge the final boss you have to meet and defeat the two other boses, Ben Bugger and Grubby McGrub, who will have a quite simple AI aswell. Ben, who is the boss you have to kite to kill, has only one phase. He follows you around the room trying to catch and kill you. He will only get faster and faster as time goes. There will be some sticky goo on the floor which the player should try to kite him through, because Ben will be slowed and take more damage. While kiting Ben the player has to shoot at him to lower his life and kill him.


Grubby will have two phases. He is the boss which acts kind of like a whack-a-mole. In phase 1 he is underground moving towards Barney with quite some speed. As he reaches his target he enters phase 2. He shoots out of the ground while shooting some icky goo around him. If Grubby hits Barney on his way up Barney will take a lot of damage. If the goo hits Barney or the player run over it, he will take damage but not as much. In phase 2 the player can shoot at Grubby to lower his life before he digs into the ground and starts chasing Barney again.


AI for Enemies

So the other week I wrote about pathfinding. After a consultation with our mentor we decided to add some other ai first and if we have the time, implement pathfinding later.

monster 1
So this week I have been writing code for the enemies’ ai-states. Our two different enemies will have different states when I’m done, but for now they will have the same just so we have something for the alpha. The one to the left is the ranged enemy and the one to the right is melee.


The player, Barney, have three “collision circles” called colliders, the smallest one (the brown circle in the middle) checks if Barney is hit by something (so he will take damage), the next one (the red circle) checks if the enemies are close enough to start attacking (if they are inside they are close enough) and the last one (the blue) is to check if the enemy is too far away to continue its attacks on Barney or too far away and will go back to patrolling. The pictures show the colliders in the prototype (the second picture) and in the actual game (the first picture).

The first state being the “PatrollingState” is active when the enemy is too far away from Barney to attack. The enemies have waypoints which it moves between, when it reaches its destination or collide with a wall it gets a new waypoint to travel to and so on. So far the only state the enemy can switch to from the patrolling state is the “ChargeState”, this happens when the enemy reaches the second collider.

When the enemy enters the charging state it starts with slowing the speed and moving towards Barney. After a short while it get Barneys position and direction, calculating where Barney will be and where to charge. Then it charges with high speed to that point. Then he stops again, moving slowly towards Barney and calculating the next charge point. But if it is outside the biggest collider when stopping it will not charge again, it will go back to the patrolling state and continue patrolling the suit.

Later there will be a state calls “ShootingState” which the other, ranged, enemy will enter instead of the ChargeState. It will change to ShootingState when reaching the second collider. The enemy will stand still and shoot at the point where Barney will be in a short while, calculating that point as the melee enemy in ChargeState. If the enemy is outside the second collider it will move towards Barney until it reaches the collider again where it stops to shoot. If it is outside the third collider it will return to the PatrollingState.

Even later, when all the smaller enemies have their states, I will begin with the bosses’ states.

The Tutorial

The other day we had a great discussion about level design. We drew the map on a whiteboard showing the bosses and the players’ spawnpoint. Then we discussed where to put all the pickups (textiles) to best help the player.

We also discussed the tutorial path. When you start the game you will get a short but informative tutorial. Have you played the game before you don’t have to follow it, just run past it.

2014-02-06 15.10.38
Red dot = spawnpoint
Black dot = PickUp (Wool)
Blue dot = Enemy

The tutorial starts with an open room where you have to discover how to move around using the keys W, A, S and D. When you have found the right keys to walk around and explore the room to see nothing’s there exept one way out, you meet your first enemy. The enemy is patrolling the tunnel and the player will have to learn how to shoot, using the left mouse button. When the bug is dead you can go on exploring the suit.
A few steps later you see a nice looking chest. When you walk on it you get a notification somewhere on the screen saying something like “Picked up a [what kind], you can now use it in your customization”.
Then you have to choose, will you go right or left? They will both lead to the same place and show you the same mechanic though. When you go within the red lines there will be an exclamation mark above Barneys (the avatars) head and a notification sound to enlighten you there is something of value or something hidden nearby. You might just pass throught it and the exclamation mark disappears, and you might go back to see if it comes back, which it will. You might see the hint of the hidden room, the ragged walls are gone and there is a vague hint of a path right infront of it. If you see this you have found the first secret room in this map and you know how to find the rest. The exclamation mark will not be showing after this point but the notification sound will.
Now the tutorial has come to an end and you have learned all the mechanics to play the game.

We won’t give any tutorial to the customization since that is not necessary to beat the game. The only hint about it is when you pick up the first textile and then you have to explore it yourself.

Rooms done, and some AI

Today was a good day for my programming. I managed to put collision in all the rooms of our game. There was one room where it didn’t want to work but I’ll check why tomorrow. I probably just sent the wrong file to Tomas (while I made the collisionpoints for every room I sent the files to him so he would implement them). Tomorrow I will make some changes to the Collisionpoint-maker program so he can use it on the map. He’s going to make points where the textiles and enemies will spawn.

When the collision was done and we had had our lecture on pathfinding I started with the AI to the game. We long discussed if we are to have pathfinding in the game, if it’s worth the time since none of us has ever done it before. We came to the decision that it would be cool (and I really want to learn how to do it), so I took the responsibility for it. Hopefully it won’t take the rest of the project to get it right, but  that’s what we’re counting on. Though we want some simple AI for the smaller enemies (and maybe one boss if there’s time) for the alpha which is due next friday. So I thought I could start out with some move patterns and then build the pathfinding from that.

Simple AI

So I made this circle which travels from point to point, using circle to point collision. I think this code will do for the alpha as AI, depending on if we have the time to implement the different states on the enemies, we might want to add some sort of attack AI, at least for the ranged enemy but maybe for the melee one as well. Else the player will only take damage if he runs in to the enemies (which is probably not that likely).

After I have fixed the program for Tomas tomorrow, I will start with the pathfinding for real. It will take lots of research and trial and error testing. We got a tip from our teacher to look at this website and work from there:

So this is what I will do for the next couple of days/weeks/month. But hopefully it will work for our final version of the game!

Even more collision!

Today I worked some more on the collision-checks for the game. I got the line-circle collision to work with SFML. The code had been working for a while before I realized I had forgotten to update the players collider position when the player moved. Now it has been implemented and I will put it to the test tomorrow.

I have also added a check between two circles. Most of the objects (I believe all the objects but the projectiles) will have a circular shape. So this will check collision between enemy-enemy, player-enemy, player-object, enemy-object. And today I finally got to use some of that math I never thought I would from school.


The Pythagorean theorem.

I also improved the tool which we will use to set the points in our room which we will check the collision between.


The scale is 1:2 but the output is the correct points we will use later. For extra help I show the mouse position in the bottom right corner. The black lines (which might be hard to see in this picture) show the user where he/she has put the points and where the player won’t be able to get past. We will simply name the files after which room the points are for. As it is now you can’t choose the pixels that are at the edge of the picture, I will have to look in to that so there will be no gaps in between the rooms. Tomorrow I will put three of the rooms together and see how well this really works.