Aloha!
Today was the day I moved on from the Framework phase into the Core Programming phase of the course. This involved a new set of challenges to implement and expand the experience of the game. At first I made a quick pass through the list of requirements and checked off any that could be done relatively quickly. This included the homing shot that I made in Phase 1 turned out to be a requirement in Phase 2. The other quick addition was changing the ammo counter in the UI to display both the current ammo count as well as the maximum amount of ammo the player can have. This was a quick change that involved altering the lines that update the ammo counter in the UI from:
_ammoText.text = “Ammo: “ + ammoCount.ToString();
and changing it by adding the maxAmmo value to the string resulting in the line:
_ammoText.text = “Ammo: “ + ammoCount.ToString() + “ / “ + maxAmmo.ToString();
This allows the ammoCount portion to constantly update as the current ammo available to the player changes while maxAmmo provides a static value to display the maximum. The reason I wanted to use the value of the maxAmmo variable instead of just writing in the number 15 to make the line:
_ammoText.text = “Ammo: “ + ammoCount.ToString() + “ / 15”;
was that doing so makes the ui less flexible and if for example we later added a way for the player to increase the maximum ammo they can hold this part of the UI will just update automatically instead of having to go into the code and retype the string to hardcode the new values.
With the quick features out of the way I started working down the list of larger tasks with the first being to develop a way to provide the enemies with new movement options. This addition was a bit of a challenge and as of this writing I have the foundation for the feature completed but the various movement patterns are not completely implemented. This change required some major revisions to both the Spawn_Manager script as well as the Enemy script. The design I tried to aim for was to build a way for the Spawn Manager to randomly choose a movement pattern for each spawned enemy and to pass the decision on to the enemy which will then act out that movement pattern until it is destroyed.
Currently I only have two movement patterns implemented with the first being the default linear path of motion that enemy script already had. The second movement pattern that I implemented a diagonal pattern that allowed the enemy to spawn at the extreme corners of the screen and then fly diagonally to the opposite corner. To prevent the ships from taking the same path every single time I locked the x-axis range of positions they can spawn at to one spot but then varied up the y-axis points to let them cover different parts of the screen.
How I built this system was by implementing a integer array to handle the random selection of enemy Id’s similar to what was done to effect the spawn probability values of the powerup spawning. Each enemy ID represents a different enemy movement type and when one is selected at spawn an if-else statement checks the result and then the enemy prefab is instantiated at the corresponding position that is appropriate for the movement type that matches the ID. The script will then also run a function within the Enemy script called SetMovementType() that has only one line that sets an integer value that is used as a condition in a switch statement to select which movement behavior the newly spawned enemy will perform.
In the switch statement I set up two separate calls for the function that sets the enemy to travel along a diagonal path for the purposes of specifying if the enemy should travel from top right to bottom left (case 1) or top left to bottom right (case 2). The reason I went with a switch statement over and if-else statement was that a switch statement is more efficient and faster than an if statement however it has limitations for what sort of parameter conditions you can give to it. In this case a switch statement is usable since the condition is only a single integer value which means its preferable from an optimization stand point. Additionally setting the condition to a variable local to the Enemy script means I can change it alter the behavior of the enemy mid flight. One such addition was a feature I added to the CalcDiagonalMovement() function that randomly chooses between the two possible diagonal movement cases every time the ship leaves the screen. This allows for more variance in the enemy behavior even if there is only one enemy in the scene.
The next step of this process that I plan to work on during my next session is to add more movement patterns. The two I want to try the most is one pattern that moves the ships in a serpentine pattern and another that allows the ships to fly into the scene, stop to shoot their guns for a bit, then fly out. The serpentine pattern is higher on my priority list but I feel the second pattern would also be an interesting addition if it was also given different shot patterns. Until then here’s a quick demo of the progress so far. Mahalo for reading!
— Kurt
