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!