Inventory Item Class: Created a modular inventory item base class to streamline both UI and backend development. All inventory items inherit from this base class, which contains core variables such as the item's stat map, name, type, cost, and image. This architecture allowed developers and designers to access shared data and functionality without repetitive casting or boilerplate code.

The base class also included common utility functions, such as enabling/disabling input and toggling visibility, making it easier to control item behavior across different systems. This setup significantly improved workflow efficiency and laid the groundwork for more maintainable and scalable inventory features.

Inventory Backend: To support a smooth and reliable inventory experience in our networked game, I developed a backend system that connects directly with the build menu and HUD. When a player attempts to purchase an item, the system checks whether they can afford it, if it’s already in their inventory, and whether there’s at least one open slot available. If all conditions are met, the item is spawned on the server and added to a replicated inventory array. If it's the only item currently owned, it becomes the held item, and both its input and visibility are enabled automatically.

To maintain consistency and prevent UI elements from shifting, the inventory is structured as an array of exactly four indices—each representing a slot. If a slot is empty, it remains null rather than being removed, which ensures stability in both UI presentation and backend logic. Selling an item simply sets its slot to null, and swapping between items using the scroll wheel or number keys disables the currently held item and enables the new one.

Each time an item is bought, sold, or swapped, the HUD and the dynamic armor system update in real time. The dynamic armor visuals are managed through a scene capture component that renders a base character model on each client, reflecting gear changes based on the player's build. This structure gave us consistent performance, minimized replication issues, and provided a solid foundation for expanding inventory features in future updates.

Dynamic Stat panels: Developed a dynamic stats panel to address the issue of players being overwhelmed by item choices without understanding their value. The panel, located on the right side of the build menu, pulls an editable stat map from the currently hovered inventory item. It automatically hides unused stats and displays relevant ones as bar graphs or numbers, depending on the stat type (e.g., time, ammo, or health are shown numerically).

Additionally, the panel shows a detailed item description to provide further context and suggested use cases. This system helps players quickly grasp each item's function and effectiveness, giving them the critical information needed to build informed and strategic loadouts.

Dynamic Armor Modification: Implemented a dynamic armor visualization system tied directly to the player's loadout decisions. When a player buys or sells an item, we calculate how many credits they’ve invested in each category (Spirit, Tank, Support, Tech). Based on that distribution, armor pieces are dynamically assigned to the player.

To reflect these changes in the UI, we spawn a base character model on each client at match start, equipped with a Scene Capture Component. This component renders the character model to a texture, which is displayed in the build menu. As the player modifies their loadout, the system updates the armor on the model, tells the Scene Capture to refresh, and then updates the render texture, ensuring the player sees a real-time visual representation of their evolving build.

Reusable item buttons: Designed and implemented a custom user widget that dynamically displays an assigned inventory item's class, type, and price, and functions as an interactive button for purchasing and selling items. This modular approach allowed for quick integration into the buy menu. Each item could be added simply by assigning its class, eliminating the need for manually creating and managing individual buttons, images, and text, and leading to a much cleaner event graph.

Preset Buttons: Designed preset buttons to accept an array of inventory item classes defined by designers. Each button calculates the total price of its associated loadout and gathers references to the corresponding item buttons to handle purchases and sales efficiently. These curated presets were created to provide players with quick access to recommended loadouts, helping to reduce decision paralysis and streamline the buy phase by offering clear, accessible options.

Weapon Affordability Visual: Whenever a player buys or sells an item or receives credits, each item and preset button automatically recalculates affordability based on the player's current credits. If the player cannot afford an item, the corresponding button is grayed out. This system effectively reduced information overload by providing clear, immediate visual feedback, allowing players to quickly identify which items were available for purchase.

Scaling Images: Developed a custom function (included in our shared function library) to scale images proportionally based on their assigned textures. The function compares the texture’s X and Y dimensions, clamps the larger dimension to the corresponding image axis, and then uses the aspect ratio to calculate the other axis value. This ensures that images are precisely scaled relative to their source texture, maintaining consistent visual quality and proportions. This was particularly important for our project, as we dynamically switched images across multiple UI components and needed them to scale accurately without distortion.

Players were overwhelmed by the amount of item information and had trouble understanding what each item did.

Managing and displaying a large number of unique items made the UI cluttered and hard to maintain.

Items wouldn't consistently replicate to the client, causing them to not appear or function properly after being bought.

Making the visuals and information more digestible through the use of our presets, stats panels, and weapon affordability visuals.

Creating the reusable item buttons and utilizing the inventory item base class.

Utilizing rep-notify variables, call the function to enable the item once the replicated variable has notified the client that it has been properly replicated.

Kill Feed: To keep all players informed of team and enemy activity, I implemented a dynamic kill feed system. When a player was killed, a server function captured the killer, victim, and the primary assister (the player who dealt the most damage without getting the final blow). This information was passed to the GameState, which exists on all clients, and a multicast event updated each player's kill feed. The UI would then check if the killed player was on the same team as the local player, using our team enums, and color names accordingly—blue for allies and red for enemies. This consistent color logic was also used across other UI elements for clear team identification. The kill feed is in the top left of the screen in the above video.

Game State Notifiers: As we brought in more playtesters, it became clear that players lacked crucial feedback on events like hardpoint rotations, credit gains, and other major game state changes. To address this, I developed a game state notifier system—text pop-ups that appear near the center of the player's screen. These were driven by a UI container (a vertical box) that listened for specific event delegates. When triggered, the system would display a message with the provided context. To maintain clarity and avoid UI clutter, we limited the container to three messages at once and ensured that duplicate messages would replace older instances of the same content.

Damage Indicators: After receiving feedback during an early industry playtest, we learned that while players could tell they were taking damage, they often had no idea where it was coming from—especially when attacked from off-screen. We tested this ourselves and confirmed that it made many engagements feel unfair or disorienting. To address this, we implemented a directional damage indicator inspired by Call of Duty. When a player takes damage, we run an event that captures the attacker’s world position at the time of the hit. Using this, we spawn an arrow on the HUD and calculate the direction based on the difference between the attacker’s world rotation and the player’s current rotation. The arrow rotates in real time while visible, updating each frame to reflect the player’s changing perspective, giving them clear and immediate feedback on the direction of incoming damage. This is visible at the center of the player's screen in the above video.

Ability Cooldowns: About seven weeks into the project, we made a key design shift: we removed bounty points and replaced them with ability cooldowns. This change introduced the need for a clear, intuitive way to communicate cooldown status to players. Taking inspiration from Overwatch, I implemented an ability cooldown timer system. Each inventory slot is assigned an item from the inventory array, and if that item has a cooldown, the UI binds to its cooldown start delegate. When an ability goes on cooldown, it notifies the UI and passes the cooldown duration. A background progress bar visually displays the cooldown using an animation whose playback speed is dynamically adjusted based on the cooldown length, by dividing the default animation speed by the cooldown time, creating a responsive and readable visual indicator for players. The same logic used for the ability cooldown animation was also applied to our weapon reload wheel. This consistency across UI elements helped players intuitively understand both ability and weapon timing at a glance.

Kill feedback: Continuing the trend of implementing feedback-driven features to enhance game feel, I created a kill feedback system. While simple in execution, it significantly improved clarity, satisfaction, and responsiveness. When a player secured a kill, an event ran on the killer's client, passing in the victim's PlayerState. This allowed us to reference the killer's HUD and display the victim’s name in an animated UI element. The result was a satisfying and informative visual that let players know not just that they got a kill—but who they took down.

Early playtests showed players couldn’t tell where incoming fire was coming from, especially when attacked off-screen, making engagements feel unfair and confusing.

Without any feedback on confirmed kills, players often didn’t realize they had eliminated an enemy, losing out on valuable context and satisfaction.

With both teams using the same character models and limited HUD indicators, many players struggled to quickly identify friend from foe, especially in chaotic moments.

Because the game was networked, getting vital UI updates and state changes to replicate consistently and accurately across all clients proved to be a constant technical challenge.

Creating damage indicator arrows that pointed to where the damager was at the time of the hit: This gave players crucial directional feedback, improving survivability and fairness during off-screen engagements.

Adding in both a kill feed displaying everyone's kills as well as a kill feedback animation that told the player who they had killed in a more accessible location on the screen: These systems enhanced clarity and satisfaction by clearly informing players of combat outcomes in real time.

To rectify this we ensured that the local player's team always appeared as blue and the enemies as red. For the UI this meant that your team's score is always blue and your teammates always appear as blue in the kill feed. We did more with this using name tags and hardpoint markers: This consistent color-coding across all UI elements helped eliminate team confusion and allowed players to quickly assess the situation.

I found that the best way to send information to every client was to utilize multicasts (events that run on every client) on blueprints that existed on every client (like the game state or player controller): Leveraging multicasts on widely replicated classes ensured reliable and consistent communication of key events across all clients.

Contextual Player Names: Player names were one of the first features where we encountered issues with network delay. To ensure every client had the correct name, I retrieved each player's PlayerState during BeginPlay, waiting until it was valid. Once retrieved, I pulled the player's name and updated a replicated RepNotify name variable. This variable was then used to assign the name to the player’s name tag widget on all clients. Later, we expanded this system to include team-based coloring: when assigning the name, the local player compared the tag owner's team to their own, displaying ally names in blue and enemy names in red. This gave players essential context—both who they were fighting and what team they were on.

Contextual Hardpoint Markers: For most of the project, the hardpoint markers remained a stagnant red, which often led to confusion—at a glance, it looked like the enemy team always held the objective. To address this and provide clearer context, I redesigned the hardpoint marker to dynamically change colors: it turns yellow when the point is uncontrolled or being contested, red when only enemy players are present, and blue when only players from the local player’s team are on the point.

Incrementing Damage Numbers: Another feedback-driven feature was the implementation of incrementing damage numbers. Initially, we had no plans to include damage numbers, but after testing, it became clear that players lacked sufficient feedback when hitting enemies and had little sense of how much damage they were dealing. Our first approach spawned static damage numbers at the hit location, replicated to all clients, but this cluttered the screen and confused non-involved players. Inspired by Apex Legends, we pivoted to a client-only incrementing system: when a player damages an enemy, a number appears near the enemy's head, visible only to the attacker. If more damage is dealt to the same target within a short window, the number increments and the display timer resets. This system gave players much clearer and more satisfying feedback on their cumulative damage.

Ping: The ping system was one of the first UI features we implemented, designed to let players quickly communicate locations in the world. For example, a player spotting an enemy could say, “look at my ping” to direct teammates. The mechanic is simple yet effective: when a player presses the ping button (middle mouse by default), it casts a ray from the center of their camera into the world. On impact, it spawns a ping actor at that location, which is set to always face the player and render above all other elements to ensure visibility and prevent clipping.

In a networked game, we couldn’t simply pause the world like we would in a single-player project. Fully disabling input would also block UI hotkeys, preventing players from closing menus or navigating settings.

Given that some team members, including myself, were using mid-tier hardware like an RTX 2060 laptop, we needed to ensure that the game remained playable without sacrificing key visual elements.

Every player has different preferences for sensitivity, FOV, and input bindings, so we wanted to allow for a highly customizable experience.

In past single-player projects, we would often pause the game when menus opened, but that approach was not viable for this networked project. Simply disabling all non-UI input wasn't an option either, as it would prevent players from using hotkeys to close UI panes. The final solution involved broadcasting a delegate when the player opened a menu. This delegate disabled input for all items in the player's inventory and temporarily prevented the player and their camera from moving, effectively locking gameplay input without compromising UI usability.

To ensure the game was accessible on a variety of hardware setups, we introduced a wide range of customizable visual settings. Players could adjust texture, shadow, and VFX quality to help reduce graphical load or enhance visual fidelity, depending on their system's capabilities.

We also included settings for mouse sensitivity, control schemes, and FOV. This gave players the ability to tailor the core gameplay experience to their preferences, ensuring comfort and responsiveness regardless of playstyle.

It was integral to communicate to players who was on each team so they could easily identify open slots, locate specific teammates, and confirm which team they were on after joining.

To ensure that team selection in the lobby was reflected for all players, I utilized multicast events. When a player clicked a team button, the system would first add them to the appropriate team array on the server. Then, using a multicast, the player’s name was added to the corresponding team array on every other client. Each client would search through its list of UI name slots and replace the first instance of “Empty” with the new player’s name. When a player left or changed teams, their name would be removed from the array and the corresponding UI slot would be reset back to “Empty.” This kept team information consistent and up to date across the lobby for all players.

Our testing process began with rigorous internal evaluation. Any time a networked feature was implemented, the responsible programmer would pair with a teammate—ideally another programmer—for immediate in-editor testing to verify proper replication and functionality across the network. If issues were discovered, one person would run as the server and the other as the client, stepping through the debugger to identify replication hiccups or timing issues. Once a feature passed editor testing, we moved on to testing in packaged builds—the same format we provided to players and industry professionals—creating upwards of 10 to 20 builds per week. If a bug only surfaced in the build version, we would revisit the codebase to identify areas susceptible to network latency and attempt to reproduce the issue. Because many of our bugs stemmed from timing and replication problems, we eventually established internal playtests with 4–8 team members, both in-editor and in builds. While most bugs were resolved at the one-on-one testing level, the full team sessions were essential for catching the edge cases that slipped through. These structured internal tests became a priority after early external playtests revealed critical issues that hindered gameplay evaluation.

In addition to our internal testing efforts, we hosted weekly external playtests to gather feedback on balance, gameplay flow, and player experience. These sessions were designed to be as bug-free as possible, which is why we implemented our multi-layered internal testing system beforehand. Nonetheless, issues would still emerge—often due to players interacting with the game in unexpected ways or from network stress when matches exceeded eight connected users (including spectators). When bugs arose, we quickly made use of our reporting form, and programmers were prompt in addressing the issues. With tests typically held on Fridays, Saturdays, and Sundays, our dev team would often spend Friday nights and Saturday mornings fixing and testing bugs found during earlier sessions. These playtests drew a diverse group of participants, including industry professionals, competitive FPS players, and our fellow students at Michigan State.

We implemented a shared Google Form for bug and crash reporting across both internal and external playtests. When a player encountered a bug, they were asked to document what happened, how it affected gameplay, steps to reliably reproduce it, and—if possible—include a recording of the issue. For crashes, players were also instructed to submit their crash logs. Prior to each external playtest, we walked participants through how to access the form and retrieve crash logs to ensure a smooth reporting process. After every internal 4+ player session and all external tests, programmers reviewed new reports, prioritized fixes, and updated the team on what had been resolved, how it was fixed, and when. To maintain quality control, no bug was considered fully resolved until it was retested and verified in a 6+ player packaged build environment following the documented reproduction steps.

Around week 5 or 6, once our game had reached a fully networked and playable state, we began encountering crashes that affected either the server, individual clients, or both. These crashes disrupted our playtests and hindered player enjoyment, making it clear that we needed a more rigorous debugging process. We turned to Unreal’s crash logs to diagnose issues. After a crash, players could navigate to the project’s Saved/Crashes folder and locate a crash log (.txt file). In approximately 70% of cases, reading the final lines of this file provided enough context to identify the issue. For the remaining 30%, we used the memory dump (.dmp) file in conjunction with Visual Studio and our PDB (program database) file to pinpoint the specific line or area of code causing the crash.

This workflow helped us identify and fix several major issues. One critical crash involved inconsistent player respawns—using the memory dump, we discovered that an object had been placed on a player spawn point, and our respawn logic hadn’t accounted for blocked spawns. Another recurring crash stemmed from accessing an invalid array index; we traced the issue to a skeletal mesh asset with a malformed bone hierarchy.

Optimization is even more critical in networked projects than in single-player games—especially when the game is competitive, as ours is. One key area where we learned this was in our UI implementation in Unreal Engine. In my earlier experience, I commonly used UI bindings to connect elements like text fields or progress bars directly to player variables (e.g., binding a health bar’s percentage directly to a health variable). This seemed like best practice, as it's what my professors taught and what most online tutorials demonstrated.

• However, we quickly realized that bindings in Unreal Engine execute every frame, which can be costly, especially in a networked environment where performance and bandwidth efficiency matter most. A better approach in most cases is to use delegates. By firing a delegate only when the relevant variable changes (e.g., when health is modified), you can update the UI element directly and avoid per-frame overhead. This method is far more efficient and scales better as your project grows.

Another bad practice I fell into in earlier projects was cramming too many UI elements into a single widget, rather than breaking them down into modular, reusable components. For this project, I focused on improving that by creating custom UI components that I could easily reuse across different parts of the interface.

For instance, I decomposed our HUD into individual widgets such as the score overlay, kill feed, game state notifications, and player health. This not only made each component easier to manage—with much cleaner and less cluttered Event Graphs—but also allowed me to selectively display HUD elements based on the context. Since we had both a player HUD and a spectator HUD, this modularity made it easy to reuse and rearrange components as needed.

I also applied this principle to our buy menu by creating a custom button widget. Instead of manually creating and managing over 20 unique buttons for each item, I built a single customizable button widget that accepted an item class as a parameter. This approach saved significant development time and greatly simplified the logic in the buy menu’s Event Graph.

As we discovered during this project, network delay poses a significant challenge in online development, especially when using replicated variables that are modified on the server and then accessed by the client. A reliable way to mitigate this issue is by using RepNotify variables. These are variables that, when changed on the server, trigger a notification function on the client only after the updated value has been successfully replicated. This ensures that any client-side logic relying on the variable’s updated state only runs once the data is valid and synchronized, preventing errors or unintended behavior caused by premature access.

• Coming from a primarily single-player development background, our team quickly realized the complexity of testing a networked game. Features that would take hours to test in a solo environment often took three to five times longer in a multiplayer context, especially when dealing with synchronization and replication. Many issues only emerged with multiple players involved, so we developed a structured testing workflow: small two-player tests immediately after implementation, four-player tests every few days, and full eight-player sessions at least once a week. We also discovered that some bugs only appeared in packaged builds, not in-editor. After one particularly problematic playtest, we made it standard practice to test all critical features in both environments before delivery.