Blog Week 2 – A Race To Meet Alpha
|
Week two ended in a cliffhanger sort of way for me. Due to an old project that i was to hand in two days before alpha presentation I wasn’t participating in the ”wrap up” of the prototypes we had been working on for the presentation until as i said, one day before presentation date. This made it sort of a race of time for me and my coworker in programming the ”shippable” alpha version of our game. So lets start at the day before A-day. Last week I presented the movement of our player in which we used atan2 to get the angle of the mouse relative to the middle of the screen. This week we started to scramble together all of the parts for a passable alpha version of our game which included a GUI, a win and loose condition, a projectile, a power up, an enemy, in short the bare minimum of what makes a ”shippable” video game. The day before, i tasked myself with getting the enemy on screen with a semi-working animation, needless to say everything was hardcoded in main….. Malcolm, our head programmer, had implemented a animation of a cartoon character named Toph from the well known cartoon series called avatar: the last air bender. It worked pretty good so we decided, for lack of time, to reuse that code for the enemy animation. Calling on our Entity class, where we specified everything needed for the sprite, we had the sprite on the screen. Now all we needed was to make the enemy walk towards the player. This I did with a bunch of if-statements checking, if player is *here move enemy in *this direction. This made it walk up and down in a very lifeless fashion, aka not good enough. Our head programmer had made impr I quickly gave the enemy a health and the player a attack damage and created a statement checking the intersection with the projectile and the enemy’s position. If they intersected the enemy’s health was set to reduce it’s value by one and the projectile set to erase. In that statement I placed a nestled statement checking for the enemy’s remaining health, if the enemy’s health was equals to zero the enemy was set to invisible and its attack damage reduced to zero. We later improved on this as well putting all of the enemy’s movement in an if-statement checking for the monsters health, if it was greater than zero the enemy could walk and attack. This way its movement would stop and since it turned invisible we wouldn’t have something you can’t see chase you and hitting you all the time. To illustrate that the enemy was in fact dead and not just, by gods will plucked from the sky, I created a sprite and loaded a blood pattern called death at the spot where the enemy was set to invisible. Malcolm also set a isBloodVisible bool to false and set it to true when the enemy’s health dropped to less than zero. That would go to an if statement that is constantly checking if the blood was visible. Explaining how i did this vice versa is a waist of time since we used the same principle but reversed. The interesting thing about this segment, at least for me, was how many steps it took to just make an object move and make it intractable in a real life sense. This part was very educational and improved the way I think when programming/creating a world. Making the code better and effective is also important, but the steps needed to make a realistic game that has consequences and visualizing those consequences is of equal importance in my opinion.  |
ovements on the players movement and using that I created a more life like way the enemy turned when moving towards the player.I created a vector2 and gave it my players x-angle and y-angle. Then I created a float called enemyRotation and set that to equals atan2 containing the enemy’s position minus the players position. I pointed the enemy to a ”setRotation” function Malcolm created in an object class and gave it the enemyRotation-float divided by PI plus 180 for it’s rotation in degrees. I reused the if-statements and voila it worked. Although a rough rotation, the enemy rotated when chasing the player.
