Aloha!
For today’s batch of progress the focus of development was on completing three goals:
- Implementing a screen shake method that can be called for any purpose.
- Implementing a new powerup spawning method that spawns powerups with different probabilities for each.
- Clean up some of the code.
For the first goal the idea was we wanted to provide some additional visual feedback to the player and add some impact to the hits that that player takes. This can help improve the feel of the game by making the hits the player takes feel more severe which can help the game be a bit more exciting. While the animation for a screen shake is very simple, at the minimum all that needs to happen is to have the screen shake side to side, there are some finer details that can be taken into account to improve the implementation of the screen shake. One detail to take into account is that there is a balance to strike between too much and too little screen shake. A restriction that we have to work under in this project is that our background image limits how far the camera can move in the scene. Overdoing it causes the ends of the image to peak into the frame and this breaks the immersion of the scene we are trying to convey for the game. To remedy this slightly I expanded the size of the background a bit to allow for more wiggle room. Additionally I wanted to keep the amount of sways from side to side limited to prevent too much visual disorientation.
Another detail I wanted to keep in mind for the shake was starting the shake with a motion that moves the ship downwards on the screen. This gives the animation a bit more force as it makes the shot seem like it slowed the ship down and briefly pushed it out of sync with the camera. Then add an upward curving pattern for each side to side motion to smooth out the shake as the ship crawls its way back to the focus of the screen. A nice tip that I picked up from past animation work is that having the movement take place in curves rather that direct lines to each key point helps make most motions feel more natural and less mechanical. Another is that overshooting the target points such as the last movement before the ship settles back into its idle position also helps reduce the feeling that the ship is snapping back into position.
When researching different methods to program screen shake into the game I found a few different methods with the most commonly recommended and flexible option being using an open source plugin called EZ Camera Shake, This plugin came with scripts and tools that allowed for flexible screen shake implementation. I feel that this was worth noting for future projects but for the sake of learning how to do it from scratch I went with trying to program the screen shake behavior using an Animator component attached to the main camera. To do this the main camera of the scene was put into an empty container object to preserve its location in the scene and was then given two animation states, Idle and Shake, that would only transition between each other when a animation trigger is activated.
To activate this transition a simple script was created that contained a single function that activate the animation trigger “Shake”. The script is then attached to the main camera and this allows any object in the scene to access and trigger the screen shake if one should ever occur. An example was to meet the requirement of the screen shaking when the player takes damage. To do this I had to only add three lines to the Player script which called a camera and accessed its Animator component, then once the player takes damage it sets the “Shake” trigger to true and the animation plays out successfully.
The other notable feature that needed to be implemented was changing the spawning rates of the different powerups from having an even spread of probable chances to spawn to having an uneven one where the homing laser powerup has a lower chance to spawn than the others. The way I accomplished this was by creating an integer array that contained multiple indices of the same value. The spread of indices were as follows:
This was an array of seventeen entries with three copies of every number except “5” which had two entries. This puts every number result besides “5” at about ~17% chance of spawning, while the result “5” has a 11% chance of spawning. If we wanted to raise the difference between these spawn rates we could reduce the number of “5” entries in the array or increase the amount of copies for one or all of the other numbers. Once the array was created then during the Coroutine that controls powerup spawning it will generate a random number from a range of 0 to a number equal to the length of the powerup ID array. The chosen number will then be used as the index address for the powerup ID array to pull one of the seventeen possible numbers from the array to decide which powerup to spawn.
The rest of the work for today consisted of cleaning up and commenting some of the code to remove unused values and fix any variable naming inconsistencies that happened. Overall I am very happy with my progress so far with this project and the next step that I would like to do when I resume work on Monday is is to cap off Phase I: Framework by revisiting and polishing up some of the homing laser behavior that is still inconsistent. After that is complete I can move on to Phase 2: Core Programming. Until then mahalo for reading and aloha!
— Kurt
