This week I’ve been working on implementing another object for the game
, the “Sonic spike trap”. The main purpose for this object is that it will serve as a distraction for the player. As you can see it’s a circle shaped sprite with a blue circle outside of it. The blue circle is the traps “aggro range” which means that the player can’t enter unless it’s destroyed. Think of it as some kind of sound waves that this trap emits which forces the mole to stay away from it. Later in the game we will add some bonus objectives that will be under this trap, so that the player will have to “waste” one of his rocks to destroy the trap in order to get these objectives, which isn’t mandatory for a win condition though.
In order to get this object in to the game I just added a sprite and gave it a position, but it’s also animated, giving it kind of like a lightning effect on the inner sprite, and the blue circle outside of the sprite goes further away from the sprite and then back in again. In order to get a correct hitbox for this object I added a rectangle shape at the sprites position which I don’t draw on the screen, and instead of checking the sprites global bounding box I check the rectangles outer lines for collision. I did this since the sprite will change its texture size at some points since it’s an animation, but I still want the hitbox to be at the max range of the sprite. The collision is done by checking the moles global bounding box and the rectangles global bounding box, if they collide we just push back the mole.
I also added a finite state machine for the trap, giving it different states, three states to be more specific. The first state is when the trap is active and where the mole can’t enter it. Another state is when the trap has been hit from a rock which will change the atlas that the animation is on, making it look more like “broken” and when that animation is done it will change to the broken state, where we just have a broken trap which does nothing special. The finite state machine is done by using a switch and different cases by predetermined enums in the header file. By using simple if statements you can easily switch between different cases, giving the object different behaviors.
On Monday we will have play testing where we will have the opportunity to collect feedback and give feedback to other groups as well before the deadline of the beta of our game. Until then I will work on trying to get a working score system.
ludvigstorm 
I must say, one of the better blog posts I’ve read in a while.
You give a clear explanation on what the artifact is, what its in game functionality is and the reasoning behind it. You also explain in a satisfying way how and why you have coded it in a certain way. I would say this post is valuable, however there are room for improvements.
The picture you are using does help to understand the artifact, however I think you could have zoomed in on it and made some sort of mockup on the Sonic spike trap, with some accompanying text and arrows to further help the reader understand what the artifact does, since I now have to guess that the thing you are describing is that thing in the left corner of the picture.
To make this blog post even more valuable and to raise the quality of your posts, I would suggest you include some pictures of the actual code to help the reader better understand how the thing you are talking about is actually coded, e.g for someone who is not very familiar with finite state machines, an in-code picture of the switches and cases, with accompanying comments, would be very useful. Also, I think you can use some more programing terminology when writing your post, which will help a reader to further understand how something is done, eg what SFML functions did you use and why?
Overall, a great blog post Ludvig, but there is always room for improvements.
//Johan Holmér
GillaGilla
Tjeeena Ludvig the Storm Johnson! D here to drop some comments
Is it clear what is done?
More or less, yes! At the start however you say the trap ”will serve as a distraction for the player.” It sounds more like the trap functions as a blockade, make the blue area non-traversable for the player. Neither would I refer to the blue circle as an ”aggro range,” since nothing is being aggroed (aggro suggests aggressive action from an ai). Rather, the trap’s radius is visualized by the light blue circle, and the player cannot enter this radius until the trap is destroyed.
Is it clear how it’s done?
Yup, I know it’s frustrating describing code verbally, I think you do basically as much as can be done without diagrams, which might not be necessary for a post of this length.
Is it clear why it’s done?
Yes, it’s clear what your goals were and how you went about programming to accomplish them.
Is the post valuable?
Sure.
Can it be improved?
Sure! Your wording can be a bit unclear at times. Minor grammar note: remember to use an apostrophe to denote possession! ie ”the trap‘s aggro”, ”the sprite‘s position,” ”the rectangle’s outer lines,” etc.
GillaGilla