I decided that my primary objective today would be to create a new enemy movement. My intention was to have the enemy seek the player when the two were within a certain distance of one another.
First, I declared a public transform called “target” on the enemy script as well as a float value for the “focus distance” between the enemy’s transform and that of the target. In the Start() method of the enemy’s script, the target is defined as the player’s transform.
Within the enemy’s CalculateMovement() method, which is updated every frame, I added code that says (in pseudo): //if the Vector3 distance between the enemy and the target is less than focus distance, //redirect the enemy’s path of movement toward the position of the target. This lead me to Vector3.MoveTowards, which I learned more about in the Unity scripting API. This member takes three parameters: current position (from), target position (to), and max distance delta (max to move per call). I added a debug log to ensure the adjustment was working properly.
Although the movement was working as intended, the idea needed more finesse. I decided to manipulate the calculate movement method in two more ways:
- Have the enemy speed up as it closes in on the player, making it more difficult for the player to evade the enemy’s craft. I accomplished this by setting the max distance delta to be double the enemy’s typical speed.
- Have the enemy disengage its pursuit of the target if it moved “lower” than the player on the screen. Essentially, I did this in response to a bug in the game where if the player did not destroy the enemy, and the enemy made it to the bottom of the game screen, the enemy would just sit at the bottom floating back and forth toward the player. Since the player is constrained to stay on the screen (vertically), there was no way for the player to then destroy these enemies. I fixed this bug with if() logic involving the y axes of both transforms.
Uncovering the MoveTowards member of the Vector3 structure through research feels like a solid example of how my skills as a developer continue to grow. Speed and efficiency will increase with time and repetition; for now I’m cementing my good habits and problem solving methods of action. Since I plan to iterate more functionality with the enemy movement next — differing enemy types, movements, weapons, etc — I know I can and will be successful this by following a similar approach.
As I chip away at the requisite challenges of the core programming section of the space shooter game development, it’s incredibly valuable to see others at work from time to time. On Fridays, our GameDevHQ group has all-team sessions — and this week was another demonstration from Al. Al expanded on last week’s discussion regarding animation and animating in Unity. He gave some tips on getting components through script as well. Al’s demonstration included fog effects through rendering light settings and animating through keyframes, as well as working with vignettes, color grading, and bloom on the post processing layer. In a matter of an hour, while explaining every step he was taking, Al recreated a space craft hovering over a sandy desert landscape with animated dust kickup that looked like something out of a recent movie.
The possibilities through Unity are vast — and as Al’s demonstration proved, when you sharpen your skills and exercise commitment and discipline, anything is possible with this internship opportunity. To echo some of my previous sentiments, I am grateful to be working through this program with GameDevHQ. Huge thanks to Jonathan and his whole team, as well as the Aloha Connects Innovation and Economic Development Alliance of Hawaii.