The development of the Troopers HUD - eXoR[Troopers] - 23rd Apr 2003
A detailed story of how our current HUD came about. It was originally posted as a news item on the old site, but since the news archives aren't being transferred and I thought this to be too valuable to lose, I posted it here as a plan update.
A long time ago in a galaxy far, far away, we had a temporary HUD in the Troopers internal builds. Implementing it had been a great way to learn my way around the UT2003 HUD code (or better yet, how to skip it entirely as I found the game’s system of Widgets to be rather limited). It was also good practice for Kahlzarg, who I worked with for the original HUD textures. We got to get to know the problems that arise when pulling HUDs in-game.
The HUD that was built, however, didn’t really seem to catch the Star Wars atmosphere, which is why you havn’t seen it in any of the early screenshots. We really felt that we had to address the aesthetics for the public release, so the entire team sat down and had a brainstorming session. It was during this brainstorm that the affinity some members had for the Tribes II HUD began to reveal itself; upon asking what it was they liked about it, they all instantaneously shouted out: the configurability!
So, that’s how it began. The idea of making a similarly configurable HUD was jammed in my mind, and over the course of the next period of coding, whenever I was working with HUD classes I would check to see whether such a configurable system could be realized.
A long period of trial and error started up soon enough in which our texture artist, Richard a.k.a. Pruneboy, came up with sketches and concepts; put them all online for us to see; hoarded comments, criticism, and suggestions; and then went back to the drawing board time and time again. Prune showed great dedication during those days, and via extensive trial and error, we finally came to the look that you now see in our latest screenshots.
As soon as I received the first sample textures from Pruneboy, I started to work on the code that would have to power the entire HUD configuration utility. I began writing my own version of the UT2003 Widgets that would be controlled entirely from script and, more importantly, would be open to any possible future additions. The first aspect of the new code that was worked on was the positioning of elements and sub-elements with correction for different scales, offsets, texture sizes and—most importantly—alignment. A system of dynamically created FinalBlend’s and TexScaler’s was set up to horizontally mirror and flip textures, should users want them to be used in different positions. This base functionality took a bit of trial and error, as offsets and scales have to be used differently for each type of alignment, but things finally came together in the end.
As I was working on the system, Prune sent me more and more pieces of the HUD. Once placeholder textures for sub-elements of the HUD were completed, code was added to fit them in the parent textures with correct placement, scaling, and mirroring for each alignment. The game code related with the HUD got some updating as well, to make sure that the area of a source texture that’s rendered to the screen would be varied when the game state required so. One example of this is the health indicator; the health texture has ten different states that are selected depending on game state (i.e. whether you’re about to die).
By the time I had this code in place, Pruneboy had the final look of the HUD established and had supplied me with most of the placeholder textures. We were still using the old number readings for the team scores and ammo though, so it was time to implement the fonts to be used in the final version of the HUD. Richard came up with a sample font to work with rather quickly, so it was time for me to get back coding quite soon. Getting the alignment right for all sorts of font sizes and widths was a bit tricky, but things were working within a few days.
So now we had a working, configurable HUD system in place, but any configuration would have to be done directly in the TUser.ini file. Since that’s not really how most mod players want or expect to set up their settings, it was time to start working on the interface that would help them set things up in-game. I had another little brainstorm in which ShroomDuck, GhostEnigma and PruneBoy were really the main influences, and we decided that we’d try to get a preview window in the configuration screen so that you could immediately see what effect your changes would have. I was unsure whether the GUI system of UT2003 was able to render preview HUDs on the GUIPage, so we were doubtful as to whether such functionality could be achieved. At first, it looked like rendering materials to the Canvas from a GUIPages wasn’t feasable, as elements added to the page didn’t receive any render calls. I later found out that the main parent element got calls though, and by forwarding those to the element that would render the preview HUD, rendering one of the HUD textures on top of the GUIPage was a possibility. I remember cheerfully showing a screenshot to GhostEnigma that must have looked like a total failure, since the HUD was drawn over the normal GUIPage and not in the correct position, but from that point on, I knew that a preview window could be accomplished.
So I got back to work, creating a recursive rendering system for the HUD as I went because I found out that the method I had used in the HUD class wouldn’t work here. It turned out that texture scaling with those factors (going from full screen to a small preview window) was not very pretty. Unfortunately, we still haven’t found a good remedy for all this yet, but we’re working on it. Anyways, the main elements are at least clearly recognizable, and the most important things such as size, position, offsetting, and alignment are good enough to work with. It’s not as pretty in the menu preview as it is in game, but hey, we tried, right?
With the technical issues solved, it was time to find a graphical layout for the HUD tab that would function well. I made a quick and crude sketch in Photoshop and, after some talk with ShroomDuck and others, the design proved to be the right way to go. So, after some fiddling in the GUI design mode, the HUD layout configuration tab was there. Some issues had to be solved with the whole utility (using the configuration window while in a map would sometimes cause references for dynamically created materials to be written to the .ini file, producing empty or white textures when launching the game the next time), but we fixed things up and the utility works brilliantly.
After the entire process we went through had been completed, it was time to add the finishing touch: HUD presets. Since the configurations and flexibility of the system we’d designed could easily cause a less-than-optimal HUD display when configured improperly, a method of restoring defaults was needed. Thanks to input from GhostEnigma (among others), we decided to implement presets. On the HUD configuration tab, screenshots of various pre-configured HUD settings would be shown; when such a button is clicked, the HUD configuration shown there is automatically applied.
I think that covers the design process of the Troopers HUD! A big thanks to Pruneboy for managing to stay sane under the constant pressure of Shroom’s and my comments, and thanks to everyone who has helped me build the HUD with their suggestions and idea’s. I hope you’ll like it when we bring Troopers to you!
Comlink
news by email
back
