ARTIFACT BLOG #5 COLLECTIBLES

Stars!

This week all three of us sat down and did our tasks together, so that we wouldn’t have someone get stuck on a task just before beta. One of the things we’ve done is collecting stars when enemies dies. You collect the stars to get a better score.

The stars themselves work almost exactly like the enemy bullets, only they get added when the enemy’s life has hit zero rather than when they’re in attack range of the player.

When the star is added, and the player isn’t close enough to collect, they get a velocity to spread out. To make the stars not fly off the screen we multiply the function to get the velocity with a float that decreases over time. As to not make the stars all pile up in one place, we define the position in the constructor as “setRotation(rand() % 360);”, and then set the rotation to rotate in relevance to the player’s position. The rand function makes the stars, for the most part, spread out in a circle around the enemy’s position where it died.

To then gather the stars we used the same velocity/rotation that the enemies and bullets use to know where the player is and move towards it’s direction, only the stars have the velocity and rotation in it’s update instead of it’s constructor. So they work as a homing missile when the player is close enough. We then use our overlap function to delete the stars when they reach the player’s position.  Currently we don’t count the stars collected, but it’s something to be made tonight (beta’s tomorrow).

 

As for the overlap, we’ve remade the previous one. The first one we made only checked the overlap between the player bullets and one of the enemies, but with another enemy and enemy bullets we decided to make it anew. All of the beforementioned objects are so called game objects, and the game objects inherit SceneNode’s functions. In Gameobject.cpp we have an overlap function (bool GameObject::Overlap(sf::Vector2f position, float p_fRadius)) so we can check the overlap between any game objects. If the overlap is true an object either loses a life or gets deleted immediately (bullets/stars).

It’s currently 22:32 on thursday and right now we’re sitting with the HUD (Life/Stars) as well as the winning and losing state. It’s gonna be a fun (?) night. We’ve also, finally, changed the second enemy’s textures so it doesn’t look like a melee enemy punching bullets out of thin air. The animations were finished quite a while ago, but we just never took the time to implement them. It looks quite badass now!

ARTIFACT BLOG #4 Second Enemy, again

Hi. This post will refer quite a lot to Box2D, you can check out my first post for the course to see more about what we’re using it for, or go to http://box2d.org to read more on your own.

This week we have.. worked more on the second enemy. Last week we felt somewhat done with the behaviour of it, but implementing it in the real project proved to be quite hard. Due to github not working for us, we’ve all worked in very different versions of the project, and so our lead began to write a new structure for us to all work in some week ago. It all seemed fine but apparently the collision had stopped working, so we had to fix that. What went wrong there was that the iterations needed for the box2D world to work had been set in the class’ constructor, not the update, meaning the sprites ran around fine, but the box2D bodies they were attached do did nothing at all.

Then came the second problem, the behaviour of our first enemy wasn’t working correctly either. It moved around, but the rotation (which the velocity uses) was incorrect, so it didn’t move or rotate towards the player. This was solved like this:

I honestly don’t really remember what was wrong, but I think we had put cos/sin in the wrong place,

So, after fixing our first enemy, we finally got back to the second one. What makes this one different is that it zigzags and shoots, so it’s pretty much the opposite of our first enemy. As of right now, the states (passive, aggro and attacking)trigger exactly like the “warrior”.

^ the distance is sqrtf(enemypos.x – playerpos.x * enemypos.x – playerpos.x) + (enemypos.y – playerpos.y * enemypos.y – playerpos.y).

When we get the collision between objects and bullets to work (we don’t do that with box2D because their “contact listener” was something we didn’t understand) the new enemy will only be triggered to aggro when shot by the player. The enemy does zigzag now though, and it changes its movement depending on where it is in relevance to the player. So basically it uses the player as the (0,0) and checks if it’s own x/y-position is lower/higher to see in which corner it currently is.

The code in the above picture checks if the enemy is lower to the right or above to the left of the player. The coordination system in box2D is upside-down, so X is still in the right direction, but Y isn’t. Which is why it looks like the >= and <= are wrong. It’s not the neatest solution to the zigzaging, but it works!

ARTIFACT BLOG #3 Our second enemy

Greetings!

Chosen artifact of the week is the ranged enemy for our game. The behaviour we wanted for it was that it should be passive until attacked by the player (You *have* to kill all enemies to win so they’re not skippable) and when it’s in its attack state it should start to zig-zag rather fast while shooting at the player. And as of tonight we’ve pretty much nailed the behaviour.

We started off by making the enemy shoot against the player all the time (enter any if-statement that is always true) as well as make the player change color when it got hit, just to check that it worked. After we had the actual shooting part completed we wanted to change the if-statement to only when the player gets too close. We solved this by putting a circle that is bigger than the enemy on the enemy’s position, and change the shooting trigger to check if the player is overlapping the circle. Which we did by checking if the distance between the player and the circle was smaller than the player’s radius plus the circle’s radius. So now we have an attack range for the enemy.

Making the enemy zig-zag proved to be a lot harder as neither Hampus nor I had really tried to make an object move on its own before. But we managed with the magic of if-statements.

We have a float that is initially set to zero, and it always ticks down from whatever value it’s at. If the float is lower than zero, it enters a world of if-statements. First, when entering the first statement, we set the float to 3. After that it checks if the float’s value is higher than 2.5, and if it is the enemy gets a linear velocity and starts moving downwards. Then it checks if the float is higher than 2.0 but lower than 2.5 and if so, changes the velocity so that the enemy moves upwards instead. This goes on to make a moving pattern (Down-> up slightly-> back down-> up a lot-> down slightly-> back up-> down a lot->repeat) and depending on the level design the enemy could move left and right as well of course.

So we have an enemy that shoots if the player gets within a certain range, and it zig-zags. Next thing we need to do is make the enemy only start this behaviour if it gets attacked, which should be easy enough. We just have to check if the bullet hits the enemy, and we already have a method for that as previously described in the attack range but with a bullet instead of the player.

Overall it feels rather good as we’ve done this on the exact time we said it would take in the sprint planning. Getting it done faster would’ve obviously been ideal, but it’s a lot better than it requiring more time than first planned!

Good thing I like writing

Hi again, so yesterday our programming teacher told us something wonderful(?), we have to make a blog post each day. Each blog post needs to be at least a thousand words. My first thought was that I don’t even think that much in a day, but I kind of hope I do.

First of all let’s get up to speed with how the project is going. We’re done with our prototype, and we’re in the middle of trying to transfer that code from SDL to SFML, which is easier said than done. While SFML seems to be quite easy to use, I’ve finally gotten somewhat used to SDL, so switching libraries is really annoying. The logic behind the actual should be the same, or close enough, but it’s a hassle trying to figure out how to write each thing in SFML anyway. Now then, we have four main things we need to get into the new project to begin with. These things are a player that can shoot, aiming with the mouse’s direction, collision and at least one enemy with some form of AI. We put Martin on the mouse direction, Hampus on collision and myself on the bullets. But we’ve encountered some issues here. We have a graphical artist who’s programmed before, so while we made the prototype he set up a form of ground code for us to build upon, which is quite awesome. But the thing is we three coders in the group are all used to building it up in a certain way, whereas the ground he made for us isn’t exactly what we’re used to. So the new plan is to build it from the ground up ourselves while still using some of the code our dear graphical artist wrote for us.

Back to today. It’s 10 o’ clock. The teacher, Tommi, is nowhere to be found, but Jerry’s there. Apparently we didn’t have a lecture today, but we didn’t know. Maybe he said something about it yesterday and we were busy daydreaming about the matrix and how they could read all that stuff on the screen so fast. Anyhow, I kept working on getting the bullets to work on the base project we had, but it didn’t go too well. I did manage to go from around 45 errors to 0 errors and 5 warnings, and the project can build, but the player is still unable to shoot. At first I had this fun problem where I tried to set the shoot action to the left mousebutton and every time I pressed “a” to walk left, the game crashed. I tried setting the shoot button to right, expecting it to crash on “d”, but alas, it did not. I did some more research on how the mouse class worked in SFML and noticed I structured it like SDL while using the pre-built class in SFML, which seems kind of counter-productive. After changing that the player could finally move in all directions without crashing the game, but there were still no bullets to be found. I’ve never actually worked with something like bullets before, so I’m not 100% sure I got it all right. But honestly I’m mostly copy/pasting the code from the prototype and trying to change some details here and there that seem to be SDL-specific. This trial and error went on to around lunch, and I haven’t actually coded since. While the others were on a meeting with our new programming guide/coach I was at the health center, and after returning we had a meeting with the entire group to talk more about the schedule and deciding on the producer for the upcoming week.

General thoughts on programming:

I have zero experience in programming from before beginning university, so the stress is extremely high. It doesn’t exactly help that I’m rather bad at self-discipline so back in the first course I should’ve studied on my free time way more than I did. It really shows that I’ve studied less than other classmates, and it straight up sucks. On a positive note I feel that I did quite well on the last assignment (the Breakout game), but I’m still way behind. I want to spend more of my free time on studying the basics again, but I barely have any free time now that we have a totally new game to develop, and with a new library. I should make use of Tommi and Jerry and book some coaching meetings but I can’t really pinpoint on one or two things I wish to get help with. One of the guys in the group had one of those meetings today so maybe we can do it together in the future. I should also make use of my lovely roommate who is a 2nd year at the same program.

Oh, and I guess I should actually tell you what game we’re making. The concept was called Suit ‘Em Up, it’s a space shooter (everyone is making a space shooter, that was the deal) and mechanics-wise there’s not really anything special going on. You move around and you shoot enemies. The thing about the game is that you’re tiny tailor inside a suit, and this suit is filled with bugs trying to eat and destroy it. So you have to kill all of the bugs before the suit is beyond repair. The group that made the concept had an upgrade system in mind, but we’ve pretty much decided to scratch that as it would take too much time. Instead of finding textiles that you can use to customize your suit and bring forth a new kind of playstyle as they wanted, we’re aiming for finding textiles and using them as temporary upgrades to stats like speed/health/damage and maybe changing the weapon’s attack a bit. Maybe some kind of multishot. The whole upgrade system we have in mind is currently set as a very low priority feature, meaning we’ll only do it if we have some extra time left after completing the main features of the game.

PS: I’ll try to start using images of my code or other relevant things in future posts. It mostly just depends on which computer I blog on, the one with the project or the one without.