B.A.M. | Sprint 2 | 9/10-9/24

    B.A.M. is a mecha strategy action game my team and I are developing for our Advanced Production class at Chico State. I am one of two Programmers in our 14 person team. This post details my work process across our second Sprint.

    My work this Sprint consisted of some more features for the enemies, spawning the player's Robot in at the start of the level, and starting on the pause menu. There will be multiple enemy types in the future, each with a different cooldown between spawning, so I implemented a simple system to set the maximum cooldown duration per enemy. Now, the spawner waits a random amount between 10 seconds and the previously spawned enemy's cooldown before spawning a new enemy.

Updated Enemy Walking Behavior

    Next, the enemy needed an adjustment to it's walking behavior to mimic the player's more closely. Previously, the enemy just walked in a straight line uniformly using Unreal's Move To node in the Behavior Tree. However, it needs to take single, sequential steps like the player robot, so I adjusted the behavior to reflect that. This was somewhat challenging at first because I thought I would need to write a custom movement function that the Move To node would then use, but I figured out a much better way utilizing a basic time limit instead.

Enemy Spawn Camera Fly-To

    Finally for the enemy, the first time an enemy type spawns into the level, the camera flies to it and focuses on it for a few seconds to show off the new enemy. My lead and partner programmer Cai Mcdonnel had already implemented a camera locator and move to system for sake of swapping the camera between the Hero and Robot views for the player, but I ran into a couple issues with it. His system worked by adding each Camera Locator to a map in the Game Instance according to a unique Name key, but that name had to be manually set for each Locator. This wouldn't work for me since I needed a Locator on each enemy - since I didn't know which enemy would be first - and I'm spawning multiple enemies in at the start with my object pool. Because of this, each sequential enemy's Camera Locator overwrote itself in the map since they defaulted to using the same key, and I couldn't get the specific enemy's Locator when I spawned it. Therefore, I implemented a functionality into the Camera Locator to update its key and re-add it to the map, which I then used to programmatically update the enemy's Locator key according to the spawned enemy's object name. This gave each enemy a unique key and place in the map which I could then give to the Player to move the camera to.

Camera Locator's Update Event Key
[I] is a reference to the Game Instance

Parent Enemy's Setup

Robot Spawns in Level

    The next feature I was given was letting the player deploy their robot at one of a few designated positions at the start of the level, which was pretty simple to implement. The robot exists at the start of the level to perform it's setup and turns itself invisible. When the player spawns it in, it then teleports to the spawn location and turns itself visible, letting the player control and interact with it from then on. To do this, I adjusted the system I had for the enemy spawn locations a little to use for the robot. The camera also flies to the robot show off it entering into the level, which was a much simpler implementation than the enemies' camera fly-to. Ultimately, the player will choose where to spawn by selecting locations on the map, which led to me working on the pause menu next.

Current Pause Menu Functionality

    Before this, I had basically no experience doing UI or working with Widgets in Unreal before, so this pause menu has been all learning. The first thing I did was design the widget according to the wireframe in the documentation; there is a small menu on the left, the map is centered on the screen, and the options and quit game menus pop up when selected. The next thing to do was start coding the functionalities, which ended up somewhat convoluted. We're designing BAM primarily for controller and I've heard that Unreal's Button widget works very poorly with controller inputs, requiring a complex and buggy system involving switching Input Modes and manually focusing on widgets. This being the case, I decided to design the control system manually, keeping track of the selected button via an int correlating to the index of an array of each menu's button. I then decrease the render scale of all unselected buttons so the selected one is larger (when increasing the scale of the selected, it becomes noticeably lower resolution). As of now, the pause menu successfully opens and closes and the Exit Run menu successfully opens and closes and lets the player quit the run.

Section of Pause Menu Graph Showing Inputs

    Lastly, once I had the core pause menu functionality done, I moved to the map. The first thing it needs to do is display the robot spawn locations for the player to deploy their robot to. To do this, I implemented a map icon widget and functionality into the map widget to find and display all icons of a specific type. This is well scalable for future types of icons. I ran into some trouble getting the math right to convert positions of Actors in the world into positions on the UI map, but I was able to get it done in an effective and flexible way.

Map Icons

    However, there was one major issue we discovered. When I implemented the player robot spawning, I had overlooked a couple things with the camera movement. At that point, there was no checking if there was already a camera fly-to cutscene playing or preventing new cutscenes from happening. This meant there were edge cases where the camera was already looking at a first enemy or the robot as it spawned when the other event happened, breaking the camera. This problem was relatively simple to resolve: just prevent enemies from spawning while the player is in a cutscene, stop the player from pausing (and thereafter spawning in their robot) in the middle of a cutscene, and explicitly tell the camera to move from position A to position B when it moves, instead of sometimes just telling it to reverse the most recent movement (which could be the wrong one).

    With that aspect of the bug solved, there was still one more issue, one much more game-breaking. After spawning in, the player robot stopped receiving controls anymore, and when my partner programmer tested it, the camera would switch to the enemy whenever it spawned in. When going through our code and workshop levels, we realized the issue had stemmed from a simple miscommunication. At this point, I had implemented the robot spawning to literally spawn in the actor instead of teleporting and activating an already present robot, meaning the new robot's setup didn't hookup properly. I had done this at my partner's advice, but afterwards we realized he had thought we were discussing how to spawn in the enemies and not the player. Furthermore, we believe the reason the camera swapped to enemies when they spawned in was because he had placed in the player robot spawn locations thinking they were the enemy spawn locations, and mistakenly spawning in duplicate robots instead of enemies. This highlighted a critical blind spot in our communication and the way I explain my code and work, one that I plan on remedying.