Game Design Blog #1

This weeks sprint planning for me included the enemy spawn mechanic change and the flare pick-up mechanics. The change of the spawn of the enemies was bound to happen as my older static and preplaced spawn system was criticized by the project manager and the lead programmer to being too predictable, thus making me change the old spawner this week into a random spawner which makes the game less predictable. As one of the most important aesthetic goals of the game is “Mysterious and Exciting”, a random spawning mechanic of the enemies were needed to make them close their distance to player from different angles, thus making the player unable to feel that he can predict the enemy movement and to be on more of an edge. The process of making the random spawner started with figuring out how it would be implemented. The project Manager had the idea of having a circle around the player where the enemies would spawn, while the lead programmers suggested a system where the players x, y, z axis were randomized and the tip of the axis were used to spawn the enemies. I went to route closer to what the Project Manager suggested but instead of circle, I used four rectangles to around the player. Then I calculated the how the enemies would spawn within the rectangle. After I implemented the enemy prefab to the code of the spawner, I seemed it was working fine in the way that it spawned the enemies randomly in places within the rectangle. But soon I realized the enemies were just spawning at the right side of the rectangles I created. While I was trying to understand the reason behind why this was happening I found out that during my calculations I misspelled an y with a x, thus solving the problem. In the future more additions of the such as a despawn would need to be added to the game as the enemies that aren’t able to catch up or swarm the player needs to be dealt with. The idea for the despawning system was brought up by the project manager in a way where the enemies despawn after they are at a specific distance away from the player.

Game Design Blog #2

For two weeks I have worked on the full implementation of the pick-up powerup called the flare. A powerup in any videogame is there to make the player feel powerful while also trying to ease them out from a serious situation. The reason our group chose this kind of a powerup is caused by the similarities it has with the flashlight mechanic which essentially is a light that when held upon a blurry sprite, reveals what the actual sprite holds which either is an enemy sprite or a powerup sprite, thus making the players experience easier to handle time to time. The first idea was that the way the flare works is when collected and fired with the required button press, it sends a single red particle that becomes larger until a limit which essentially stays around for 5 seconds. This reveals most of the blurry sprites on the playable screen.

The process of me making the flare started with figuring out the particle system. Firstly I made a single particle move towards the camera, as our unity project is in a 3D world it made it possible. Then growth was also added to the particle giving the illusion where the flare gets high up in the air in a top-down view. The next step was to actually making the flare reveal the blurry sprites which I were able to do by copying the flashlight mechanic. But instead of using a cone hitbox I used circle hitbox which took over most of the screen. After the input was done where the “q” button would be used, a slight problem was brought up by the project manager. The problem was that when enemies got in touch of any light hitbox they got into a aggro which made them move towards you to attack. When the flare was used it made less of a powerup and more of a suicide button as hordes of enemies suddenly moved towards the player. This was fixed by making the enemies hit by the flare hitbox to not change status to aggro but rather stay where they are.

yeyey32