Making a stone projectile for Mole Munch
This last week before Alpha deadline for our game Mole Munch has been hectic. Our coding planning has not been the best, and this week we have been paying for that mistake. We still had a lot of things that needed to be implemented for the Alpha. Luckily, our game designer came to help us this last week so we could get the coding done faster. One of the things I coded this week was the projectile that our mole can shoot. It’s a stone that will stun gardeners for a set amount of time (not defined yet). The reason why we added a projectile is so that the playercontrolled mole can stun gardeners who get too close, allowing a chance of escape. However, the player is limited to shooting one stone at a time, so they can’t just spam stones against gardeners to make the game easier.
The stone has three different functions that defines what it’s supposed to be doing: void UpdatePlayerStones(float deltatime), void SpawnPlayerStone(const sf::Vector2f& position, float direction) and void DespawnPlayerStone(unsigned int index).
UpdatePlayerStones updates the stone and sets its position and speed everytime it gets updated. It also despawns the stone if the stone reaches a wall or an enemy.
SpawnPlayerStone checks with an if-case if the stone count is 1 or if it’s 0. If it’s 1, a stone will spawn and no more stones will spawn until that stone has despawned.
DespawnPlayerStone checks how many stones the player has, and defines when a stone will be spawned again after a despawn. The code for this looks like the following:
The different functions aren’t too complicated to understand, but it still took some time to get them to work the way I wanted to. The reason for the longer time is that we’re rotating our game, which makes the collision and direction of the stone a bit harder to code.
The stone is important in the game because it can provide an escape from gardeners without having to dig down into the ground. However, in a future version of the game, we tend to implement an AI to the gardeners which will make them enraged after the stun duration, making them move faster towards the player for a short duration. So you’ll have to be more careful about shooting since the gardeners will be moving with a speed that is a lot higher than yours. Which means you won’t be able to escape very easily.
An early version of how the stone currently functions in the game looks like the following:
The stone has been fired from the mole, and is moving towards the NE of the map. The stone was coded with basic graphics implemented, meaning the background doesn’t look like it will in the game.
Game Design 
marcusvanaller 07:33 den 24 februari, 2015 Direktlänk |
What could you or your team have done to improve the planning of the coding? Have you tried to use Trello to get a more visual perspective on where things are at? While Scrum is intended to do the same thing, the things on Trello can be easier to see and it is a bit more user-friendly.
Why do you feel like the planning of the coding was bad? Did the team put too much work on too few people, or on members who might not have been experienced enough to complete the tasks given?
When you brought up the code, it would be easier to read if you removed the unnecessary information, it would for example only be necessary to say ”UpdatePlayerStones” and not ”void UpdatePlayerStones(float deltatime)”. Especially as in the text under it, you only use the function name when you talk about each of them.
After ”SpawnPlayerStone”, it would be nice if you just for reading convenience added what would happen if the value returned 0. One can’t really dumb things down too much when explaining something unless what one says is just redundant text.
I however like the picture you added under with the code as it elegantly clarifies what you were saying above.
I find that you are very clear in the why and how and I find the discussion about where the game will progress in terms of the projectiles and their interactions with the game very interesting. Maybe think a bit more about how your team could have avoided the problems you faced in the beginning as that part doesn’t really have much discussion on a solution.
GillaGilla