The past week has gone by a lot quicker than I’d like. Since it is reading week I had more time to work on Project Retribution but with the week going by so quickly, and not having a set task assigned to me, I was only able to get minimal work done. I started working Monday on changing the projectile spawn system to a pooling system as our mentors at Snowed In suggested the prior week. After watching some tutorials online I figured this would be an easy task and wouldn't take much time to implement. Unfortunately, that's not a great assumption to make when learning a new technique. I ended up following Brackeys tutorial on the subject (https://www.youtube.com/watch?v=tdSmKaJvCoA&ab_channel=Brackeys). While the video is easy to follow and implement into our project, I had an error. The projectiles worked the first time they were activated, but as soon as they were activated again they would no longer spawn in the correct position as shown below.
After a few hours of trying to find the culprit, I realized the issue was with the prefab once it was being deactivated. After a projectile prefab was activated, it would collide with an enemy and then be deactivated. Once the Queue started over, it would place the prefab into position, but the child of the prefab would not be reset. Its position was still changed which cause a cascade effect on all projectiles being shot out, once the Queue would loop back on itself. To fix the issue I reset the position of the child and parent objects after being disabled. As you can see below the pool of objects is working which means we no longer instantiate and destroy a projectile every time it is fired.
Next, I worked on getting the projectiles to collide with the obstacles on the scene, such as the barrels, mast and cannonballs. This worked smoother than the pooling as Val already put all the obstacles on the scene under the “obstacle” layer so I only needed to add a check to an OnCollisionEnter2D function which checks if the object the projectile collides with is on the obstacle layer.
After quickly finishing that I added sound effects to the projectiles which took longer than expected. I budgeted out 2 hours to find and add sound effects to the final boss, however, it actually took me close to 4 since I had to solve the issue of playing the sounds at the correct time and for the correct amount of time. In the end, I used an isFiring variable to check
when the player is firing using various methods depending on the controls the player is using. For instance, if the player is using the mouse and left clicks then isFiring becomes
false on the button going up (releasing the click). If the player is playing on mobile
then I check if the magnitude of the right stick input is below a certain number then the player is not firing and the variable is set to false.
I do still have some bugs to iron out, however. The mobile version isn’t working correctly so my next plan is to fix that issue. You’ll hopefully be able to read about how I solved that next week.
As for the other members of my group,
Val has been working incredibly hard on getting the Restaurant Rush minigames core mechanic to fruition. As well as creating NPC sprites to fill out the crowd in the minigame and the hub world.
Mark has been working on the Restaurant Rush instructions
Sean has been working on the Restaurant Rush Game Manager
Steve has been working on the Hub World layout
Below are the sprites that Val made for the NPC as well as a video showing off the Restaurant Rush minigame at its current state. I added some background music as I was writing this blog since it felt devoid of soul without any sound.
That's all from me this week. Next week we will be working on the next minigame Fire Fighter. Excited to show you what we do next!
Comments