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!

ARTIFACT BLOG #2 Alpha time!

Hi.

This week has been rather stressful. During our project we’ve had a lot of problems syncing our projects, meaning we’ve been sitting with maybe 3 different projects that all needed to merge together. This week all of us have worked mostly with trying to do just that.

We had one project with most of our game mechanic, that later got the collision from another project (by project I mean solution files), and then we had a third project with most of the basic structure, i.e. all the managers. We sat down together with Jerry on Tuesday to get advice on what project to use, the one with the managers or the one with the mechanic, as trying to move the code from one to the other would be problematic either way we did it. After deciding to focus on the one with the mechanic, we sat down together on one PC and tried to glue it together with what we had from the manager-project. Martin’s state manager fit in right away but after that it got messy. As we’re using box2D together with SFML we kind of confuse ourselves a lot on what needs to be where.

The day after, on Wednesday, we realized we still need to fix the win and lose conditions for the alpha. Hampus and I focused on that while Martin kept trying to get the structure up with the help of the other project. In Box2D there’s something called ContactListener, which checks if objects collide, something that can be useful if we want a bullet to make the enemy die. I don’t know how long we spent on that but it didn’t work at all, and so we moved on to more traditional colliding for the bullets. If the distance between the bullet and the enemy is shorter than the enemy’s radius, they collide. Boom. That’s that. We spent an entire day to look up ContactListener and we could’ve solved it with just a few rows of code. I feel like we always try to make things more complicated than they need to be.

Anyway, with that done, we still needed to implement that in the real project (we just made a testbed to see if it would work before messing around in the big bad project file). But the thing is, one of our graphical artists has been coding for around 7 years or something, so he helped writing a lot of the code in that project, and the rest of us aren’t really familiar with the structure in his code meaning implementing the function to see if the bullet hit the enemy was incredibly hard. We had to ask him to come help us, which he gladly (I think) did.

 

“_b” refers to the bullet and “_e” refers to the enemy.

After getting the enemy to die we began working on the actual conditions for winning and losing. Our first enemy doesn’t shoot anything, he’s melee, and being so close to deadline we simply made the losing condition be that you have to kill the enemy in a certain amount of time. This sounds a bit like cheating but the game is supposed to be on time, and the player’s health is connected to it (if you get hit you lose time) so it makes sense in the end. As for winning you just have to hit the enemy five times so it dies.

It’s now 22:51 local time and I haven’t eaten in way too many hours.  Good night!

Artifact blog #1 Collision

Hi. Time to start writing about the game design course!

This past week Hampus and I worked on understanding and using the collision in Box2D.  Box2D is a physics engine that works with C++, and while only using it for the collision might seem a bit of an overkill Box2D has such a great variety of usage that learning it now can pay off in later projects as well. As far as collision goes here’s a list of the features Box2D has:

• Continuous collision detection
• Contact callbacks: begin, end, pre-solve, post-solve
• Convex polyons and circles.
• Multiple shapes per body
• One-shot contact manifolds
• Dynamic tree broadphase
• Efficient pair management
• Fast broadphase AABB queries
• Collision groups and categories

What makes Box2D so easy to use is the fact that as long as the objects you create are in the same “world”, they will collide with each other. Or rather, in Box2D you make the hitbox for objects and then in SFML (or another library of your choice) you make a the actual object and have it share the same position as the hitbox. Then you just make one of them move (in our case the hitbox) and have the other one follow by always updating the position. The hard part is implementing Box2D in an onworking project as I will come to shortly.

We began reading the documentation that came with Box2D and focusing on the parts about collision, on Tuesday we began trying to include the files into a project and try things out. Including it in an empty project on its own is just as easy as SDL or SFML, but together with something else is where the issues begin. SFML doesn’t particularly like Visual Studio 2013, but Box2D doesn’t particularly like VS 2012. We tried using CMake to build Box for 2012 but that didn’t achieve anything, no matter how much the tutorial tried to convince me.

At Thursday we had a meeting with our mentor from the 3rd year, and he thought it would be easier to just make the collision ourself rather than trying to learn Box2D. Since he’s a 3rd year we took his word for it even though we didn’t really get why it would be easier to do so, and I began working with the collision from a previous project and see if it could work out here as well. Hampus on the other hand felt that we had spent too much time on Box2D to give it up and so he continued tempering with it. We thought that if we split up and tried different things we’d simply use the collision from whoever got things to work first. And that was Hampus. On Friday we had a ball dropping down on an invisible square and colliding with it, and during the weekend Hampus got chains to work as well. Chains is a way to make collision work between objects and walls. You simply set out the coordinates for every point/edge in the wall and the chains will link them to each other automatically.

 

^click

So as of right now we understand how to create objects and chains, and our next artifact is to implement it in the project.

 

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.

This is the end! Post #8

We wrapped up the last of our game last night. With Fabian’s fabulous dedication  and with some guidance from Jerry we got TTF to work, and we now have everything we want in the game. Time to write the individual report today-tomorrow and then that’s the end of Game programming 1. Rushing into game programming 2 and game development next week.

TTF is not my friend. Post #7

Writing this one slightly late, as the following is what I did yesterday. Got home way too late to blog anything.

Anyhow. As I wrote in my last post I was playing with the reset-function of the game, but that’s still not working. It’s really a low priority thing so I only work on it if I have some extra time. I’m getting closer, but yeah, that is put on ice for now.

We got the score up and running yesterday, although our calculation for the score is a bit funky. In initialize we set the score to 27000 and then in run we simply put in Score–;, in a way working as a timer. The actual calculation for the score goes Score = Score * (Life + 1). What happens is that the score always goes down, so to get a higher score you have to be fast, and then it multiplies itself with how many life you have left, so you’re more likely to get a higher score if you win. Only downside is that if you win slowly you’ll probably get less score than if you lose fast, but hey, it’s still a score system!

Other things we did yesterday includes the sound for the defeat condition, as well as sound effects for when the ball collides with anything. One thing we began working on but didn’t finish was TTF, or True Type Font. After reading up tutorials and looking at examples we kind of understood how to implement it but.. it just doesn’t work. As far as we know the code SHOULD work, but it just doesn’t write out anything, which just sucks. We have score, we have life, and we’re going to get highscore (so it remembers earlier score), but it would be neat if we could write it out in the game with something else than pictures.. as that probably wouldn’t even work with the score.

It’s just bonus score to have ttf, but bonus score is nice. I want bonus score.

Audio is up! Post #6

The mission of today was to make the audio work, and it does! To begin the day we focused on some smaller details and made the ball move with the x-axis of the paddle the player control when the ball is idle (i.e. when it spawns). Before the ball would just reset it’s position but keep it’s direction, meaning if you lost once you would probably instantly lose twice again for a game over because the ball just resets and goes down again. A bit harsh, I’d say. Now the ball goes idle and sets it’s x-axis to be the same as the paddle’s x-axis so you can move around and begin again, on your own terms.

As for the audio, we now have a background song looping, and when the victory condition sets in it changes. I think we’ll make some more sounds tomorrow, like when the ball hits something, and something for when the player has lost. Other things we’ll work on is an option to reset the game after you’ve won/lost. I tried to make it work just a few minutes before we called it a day but so far it only resets the bricks. The controls are still frozen, not quite sure how to fix that. Right now there’s just a key that when pressed down goes through cleanup and then initialize. Maybe it’ll work if we put the global speed (the variable we set to zero to make the game “freeze”) in the cleanup along with the pictures for winning and losing. We’ll see tomorrow if it’s that easy or not.

To get the points for having a soundmanager we seem to have to have a playlist so you can change songs and pause, so there’s that too.

Quite satisfied though, there’s 5 days left until the deadline (gotta write that report too!) but I feel like we’ve come a long way in a very short time.

Epic winning! Post #5

Productive day!

Today we made the win condition, defeat condition and set up a life counter so it’s not game over instantly. The win condition was rather simple to implement as Fabian already made a counter for the bricks. So we simply set the global speed to zero and popped a “Victory” banner when the bricks reaches zero. As for the defeat condition it was a bit more complex than that, but it still went past somewhat fast. Instead of checking the amount of bricks left, it checked the ball’s Y-axis, and if it hit bottom we’d take the life int and remove 1 from it (it has 3 from the start). When it reaches zero it pops a defeat banner and sets the global speed to zero, just like the win condition.

Overall it felt like a really productive day, although we mindf**ked ourselves for a while. We managed to draw out the images for winning/losing but when we replaced the images for the ones we wanted (our test image was the Dell loading screen) it seemed like something was wrong. We couldn’t see the images, but there was no error. After a shamefully long time we realized the picture was set at too few pixels so it only showed the borders of the images, which are transparent. You see the problem.

Time to go. Tomorrow we’ll work on audio, hopefully.