OVERCOMING WIDGET CONNECTION CHALLENGES
While developing my Unreal Engine 5 game, I encountered a frustrating challenge while trying to connect multiple User Widgets. These widgets played a crucial role in creating interactive menus and interfaces for the players. Initially, I attempted to use a widget switcher to handle the connections between various widgets. However, this approach proved to be problematic as I struggled to get each widget to load correctly. It seemed like I was hitting a roadblock, and I needed to find an alternative solution.
After some experimentation and research, I decided to take a different approach by loading each menu within the code for its respective widget. This decision proved to be a game-changer. By directly handling the loading process within the widget's code, I gained more control over the connections and interactions between the different menus. it allowed me to link them together seamlessly and overcome the challenges I had previously encountered. By overcoming this challenge and getting the widgets to work together, the end user experiences a more polished and professional game.
Author: Johnni Beal
Posted on 07/15/2023
COLLISION FOR THE AI
author: Hayden Rodgers
Due to the AI not being a humanoid I could not use the standard capsule collider to hand the collision. This would cause for issues later since the hitbox for the AI would not match up to the model. Making gameplay feeling rough for that the player could shoot the legs but not have it count as a hit. This was of high importance in my task for that if not done as soon as possible for the AI it would cause issues later in development where the AI would have to either be fully rebuilt or changed.
After attempting different methods for changing the collision for the AI. The end solution was to turn off the overlap events for the Capsule collider. While also turning the collision on the mesh to pawn and enabling overlap events for the collision. With this it allows for the players to be able to shoot the AI at any body part to inflict damage.
SERVER/CLIENT CONTROLLERS
Problem: Server/Client Controllers
While building the networking framework for Extraction Protocol, I ran into an interesting issue. When a new Client joined a hosted session, the input controls of the previously joined Client would be inadvertently removed. This became frustrating as map testers could only effectively test the logic for solo sessions.
Upon thorough debugging, I identified that upon player spawning, each player was being assigned their own player controller. However, this process also caused the removal of the previous player's input controls. The auto possess feature in our character class was enabled, which led to the transfer of input control to Player0 whenever a new client connected to the session. By disabling this feature, each character that entered the session would be assigned their own controller at their respective spawn point, resulting in the expected outcome.
Author: Kyle Worthington
Posted on 07/16/2023
AI ATTACKING EACH OTHER
Author: Hayden Rodgers
This week when working with the AI with multiple of the grunts in the scene they would attempt to attack each other instead of going after the player character. The AI would only register the first entity that would enter the radius. This was causing issues for that the AI would not attack the player unless it was alone or the surrounding AI had been killed.
To fix the issue I had to add in the ability for the AI to register teams. With the team register the AI would look to see if the target that entered their range was a hostile or a friendly. This change helped to have the AI detect the player but there was another issue with the fix. The AI could register the player but do to having a large amount of AI within a scene they would eventually not be able to attack the player due to it detecting a high amount of friendlies near by. To fix this issue I had to implement a bool where the AI would check to see if it had seen the player, making it true if it had sensed the player. This allows for the AI to chase the player upon detection and to ignore the fellow AI by it.
With the fixes it now allows for this situation where the player can be chased by multiple AI
IMPROVING GAME MENUS WITH HOVER EFFECTS: LESSONS LEARNED
author: Johnni Beal
Posted on 07/20/2023
To enhance the user experience of my Game menus, I decided to add hover effects to the buttons. Hover effects serve as visual cues, indicating that a button is interactive and clickable. Without these effects, users might struggle to differentiate between interactive and non-interactive elements, leading to confusion and frustration. Implementing hover effects, though seemingly straightforward, presented some challenges. Initially, I tried adding the code directly to the button UI template, but it didn't work. I experimented with different approaches, moving the code to individual menu scripts for each button.
While this method worked for some buttons, it created problems for others, making it a less than ideal solution. In the end, after clearing out old code and starting anew, everything worked flawlessly. This experience taught me that starting over can lead to unexpected breakthroughs and transform seemingly insurmountable obstacles into successes. As developers, embracing challenges and learning from both our achievements and mistakes are essential for growth and improvement.
RESOLVING THE ISSUE WITH CAMERA AND ANIMATION SYNCING
Identifying the Problem:
In the development of our game, an issue arose where the player's mesh and animations were not being properly updated when performing certain actions, such as jumping or adjusting the camera pitch. This discrepancy resulted in a jarring experience for players, affecting both gameplay and visual aesthetics. To create a more seamless experience, I dove into the Player's Script and Animations, identified the root cause, and implemented a solution that synchronized the player's animations with the camera updates.
Implementing the Solution:
When observing the player's actions, it became apparent that the AimOffset, was not being set until after the Camera Update had occurred. Consequently, this led to a misalignment between the player's mesh and animations when performing certain actions, such as aiming or jumping. To address the synchronization issue, I restructured the animation blueprint, using the player's pitch and the AimOffset. By setting the pitch before the animation update, I ensured that the player's animations would accurately reflect their current state, making the character's actions appear more natural. I modified the Camera Update to use the updated AimOffsetPitch value which led to a proper sync between the two. To address the jump animation issue, I implemented a blend between the IdleWalkRun Blend Space and the AimOffset pose which allowed for the player to jump and shoot without the animation bending the player's mesh and creating abnormal effects. After implementing these changes, the player is now able to jump and shoot with the animations being properly set as well as the camera being synced to the updated animations
Author: Kyle Worthington Date: 7/20/2023