-
-
Notifications
You must be signed in to change notification settings - Fork 6
What Is Xhud?
From conception, Xhud has been about optimizing the USER in a competitive environment.
This is achieved through the meticulous attention to detail of every aspect of the HUD and how it contributes to user performance in high intensity situations. Throughout the iterations of the HUD, it has been used by myself and top-echelon players, crash-testing and fine tuning the design. This is very much a passion project as, from scratch, a rough estimate of time spent developing the HUD so far would be in the hundreds of hours from just myself, excluding my prior experience in the development of other HUDs.
Although file size is generally overlooked on modern hardware where multi-terabyte storage is commonplace, in Xhud it is treated with exceptional consideration as the very first interaction the user makes with the HUD. By minimizing file size we remove practically all thought from the decision making process of installing the HUD. At only 6 MB, the HUD can slip into bloated gamer HHDs, be sent between friends over Discord, or be stored on the cheapest thumb drive you could find the night before a LAN. Xhud is roughly 10% of the size of similarly featured HUDs, and half the size of JUST the custom killfeed icons used in nearly all HUDs (Xhud includes a custom optimized version).
To be clear, file size is never the deciding factor on the design of a feature, but it is always minimized wherever it can be done without compromise. The way I minimize file size is typically through cutting bloat, tailoring something to its application, or through an understanding of material data formats. For more information on this topic, check out this wiki page.
The first time you launch the game with Xhud installed, it asks you to select a resolution from the list of supported resolutions. Then, it remembers your selection and you're ready to play or customize the HUD using the in-game customization menu.
This is a simple and non-noteworthy process, and that's because of the extensively designed and tested Log-Base system responsible for the memory of the user's resolution and customizations, originally developed using Animation-States before adopting a more reliable process refined from JarateKing's bleeding edge Basefile Script Integration. For more information on the system developed for Xhud, check out this wiki page.
A benefit of this design is the portability of your customized version of the HUD. All of your customizations are stored in only couple-hundreds of bytes in a text file and generated by the HUD, so sending this file to friends over Discord, distributing it to fans, or transporting it to a LAN is incredibly easy.
The governing principal behind Xhud's menus is to get the user into game as quick as possible.
On the main menu this is executed by placing the most important buttons, "Play" and "Quit" in the corners of the screen. At first glance this seems like an unintuative place to put important buttons; however, the speed at which people maneuver their cursor to a given target is determined by the size of the object and distance to the object. By placing the buttons in the corner of the screen, the distance needed to get there is offset by the infinitely large target as the cursor is unable to overshoot. This also places the "Play" and "Quit" buttons in opposite corners, ensuring that pressing of one or the other is intentional, something overlooked in the default placement of TF2's "Play" and "Quit" buttons.
My commitment to this principal is also evident in my working alongside Horse and the numerous iterations of their Menu Fix, to fix the TF2 bug where exiting the loadout screen using the Escape-key in-game would cause you to pause to the loadout-selection screen (instead of the pause screen) when pausing the game the next time. While it was an incredibly minor bug, it was on that made menu navigation clunkier and more time consuming; as such, Horse and I spent a couple months developing, testing, and refining a fix for this bug. In doing so, we also added the functionality to entirely skip the loadout-selection screen, going straight to the class you are currently playing. This further streamlines loadout editing, as we acknowledge that the user is most likely to edit the loadout of the class they are currently playing, and on the chance that our assumption is wrong, Xhud allows the user to navigate to any other loadout from the one currently selected anyway, thus not increasing the steps editing a loadout over the default configuration even in our worst-case scenario.
There were decisions that needed to be made regarding efficient navigation. Because users of the HUD may have thousands of hours of using any other HUD, default included, in some cases we had to balance streamlining navigation while avoiding a learning curve to menu navigation. For example, on the loadout screen, the layout used by default and a majority of other HUDs places the character preview between the weapon and cosmetic equip columns. Technically speaking this slows down the user if they want to edit weapons AND cosmetics simultaneously, as the user's cursor needs to traverse the effective dead space of the character preview to edit the other column. However, because of the prominence of this layout and the infrequency that the loadout screen is interacted with, especially the cosmetic section, changing this layout would likely have introduced a learning curve that would have offset the minor efficiency improvement an optimized layout could offer.
The governing principal of the in-game HUD is that information should be delivered to the user in the most efficient way possible, without distracting the user.
A mental scenario I think about when designing in-game elements is if I'm currently fighting an opponent, when do I need that information; while I'm fighting the opponent, before I take my next engagement, when I coordinate with my team next, etc.
An outline of information priority is here:
- Ammo - This determines how I behave in a fight. If I need to reload I'm going to focus solely on dodging while I reload my chance to win the fight.
- Health - This primarily determines my decision to commit to a fight or not. I should have enough health that I can commit to the entire length of winning the fight, or escape to gather the resources I need to recommit.
- Team Status - This determines how I coordinate fights with my team. Once a team decision is made, I need to manage the above two points for myself before I can coordinate with the team again.
- Objective Status - While the objective wins the game, you need to consider all of the above factors before concluding how you can best contribute to the objective.