The boomerang
|
A brief explanation: So in our game, you play as a burglar in a big, badly lit mansion, and the only source of light you have is a glow stick that act as a boomerang, which of course means that the player can throw this to light up a distant area. As any good boomerang, it always returns to the thrower. The player throws the boomerang using the right mouse button. It flies towards the courser and returns to the player when it reaches the given destination. A green oval light follow it and both the boomerang and its light rotate as it flies. Some code: The boomerang is a class of its own and of course contain all the basic stuff; a sf::Sprite, a light, a sf::Soundbuffer, a hitbox ect. It has a player pointer which enables easy access to the players variables, in this case we are interested in the position of the player. A finite-state machine with an enum and a switch with cases, is used to identify what state the boomerang is currently in. We’re using this since it’s a simple way of keeping track of the objects’ various states. Also it makes for good code structure. These are the three different states, pretty straight forward: What happens when the player presses the RMB when the boomerang is in the held state is that a hitbox is placed where the mouse course was when the RMB was clicked. Since we are using sf::View to move the camera along with the player, we need to convert the mouses’ coordinates from -the default- screen, or pixel coordinates, to game worlds’ coordinates. Did that make any sense? The screen and the game world basically has different coordinates, so we need to convert them in order to use the mouses’ coordinate in relation to the game world. The position of this “target hitbox” and the position of the boomerang are used to calculate sin and cos for the angles the boomerang and the target hitbox create. Sin and cos for the angles are used to modify the movement of the boomerang which results in the boomerang moving along the triangles hypotenuse. Letting the PC do the calculations is more foolproof than hard coding the movement directions. Also it works. When collision between the boomerang and the target hitbox is detected, the state is switched from the flying state to the returning state. Now the target hitbox is set to the position of the player, and the same calculation mentioned before is done, and the boomerang moves towards the player instead. When it collides with the target hitbox when the returning state is active, the held state is activated and the boomerang is set invisible by tweaking the color of the sprite using sf::Color, since the avatar animation will show the avatar holding the boomerang (which is not the boomerang object). While the boomerang is in the flying state, it checks if it is colliding with any walls. If it does collide with a wall before colliding with the target hitbox, a loud bang sound is played and the returning state is set active causing the boomerang to “bounce” on the wall back to the player. To clarify (or confuse even more), here is some more code to bite into:
 |
