Easily my most ambitious and complex system I wrote, the replay system was based off a wireframe a co worker and I collaborated on. One of the things we both agreed on is we felt fighting games left a lot left to be desired when it came to managing and displaying replays. Often as player, trying to find the replay you want to watch can be an annoying process of trial and elimination, usually there's very little information displayed, at max only showing the characters used and the stage. We wanted a system that displayed everything you could want to see from a replay, without having to sit through the entire playback. The wireframe included in game statistics, the amount of players, what characters they used, the score, the map played on. It also featured options to export replays a video file, or publish directly online to share.

Creating the system was a huge hurdle, it was my first time working by myself in the code base so I was starting off with nothing. The first thing I focused on was creating the actual interface, there was 2 main components to this system, the replay manager, and the individual replays themselves, which I called replay containers. Sticking the containers in a list was easy, but each container had the ability to expand and show extended details, which needed to be accounted for. I designed a function that would tween replays below the selected one by the approrpriate amount, and/or push everything above it up if it was below a certain position. This neatly allowed users to expand details and always have the container appear on screen. Once that was settled and squared away, I set out and created a system to inject replay data into each container, and have it all displayed correctly. I found myself stuck on this problem for a few days, unable to deserialize the replay data, before finding out there was an undocumented bug in our serialization system. After correcting the bug, everything injected perfectly.  

The fight menu alongside the replay manager was my favorite contribution to the game, and also one of the most difficult. After working with my co workers, we decided on a panel inspired wireframe I designed for the games sub menu. This menu would be accessed from the main menu, and would be the launch point for the game's various multiplayer modes. The idea was to have panels that would expand upon selection, revealing the key art beneath and popping out in front of the rest of the panels. When I set out on writing the system, I wanted it focus on UX on both the developer and user side, making sure the system was easy to understand and update, while also feeling simple and smooth for the user. Disabling panels and updating key art were streamlined, and every function was commented and documented. Creating the pop out effect turned out to be the biggest challenge, I went through 3 different iterations before I got it working right. The first iteration was made by taking existing key art and collaging them into one image, but our lead wasn't a fan as it was going to increase our install size. The second iteration was a significant improvement over the first, but had a glaring design issue. In an attempt to have masked images appear in the foreground, I wrote a script that manually changed the sorting order of assets. However, in Unity this caused numerous issues as the engine does not like order swapping during run time, and thus the iteration had to be scrapped. The third and final version utilized canvas components, which had a built in sort order functionality. Even better yet, it could be keyframed in the unity animator, allowing me to trigger a layer swap whenever a panel was selected, saving me a lot of extra programming.

When redesigning the first thing I wanted to focus on was what features did the original lack, that a user could find useful? A public/friends lobby button, searching for lobbies were immediately apparent. These would allow users to more easily navigate lobbies without having to use Steam's overlay feature, and overall navigate less sub-menus. A problem I realized early on is that the old, and new system i was designing didn't scale well with a large player base. As a temporary fix, I added search functionality to provide extra navigation as a future buffer in-between making a large, robust lobby browser. Another thing I wanted to add was a sidebar that displayed the lobby's current players, current game-mode and rule-set. Initially I thought this could very useful for players looking for a specific type of lobby, but I realized in the lobby's current iteration it provided too much information that in most situations, was not useful. I decided it would be better suited and adjusted for when we made a proper robust lobby browser.