CSQC HUD roundup

Knowing that we now have CSQC to do all sorts of stuff, I've decided to have a close look at our HUD system, as well as HUD systems of other games like Quake 3 Arena. I've found out that the mod CPMA for Quake3 (as well as the Q4Max mod for Quake4) offers the possibility to configure the style of the elements of your HUD by modifying settings in a dedicated file. Here is an example:

Console
{
	rect 0 0 640 48
	time 3000
	font threewave
}

WeaponList
{
	rect 0 64 48 16
	color 0.2 0.2 0.7 0.75
	font id
	fontsize 12 16
}

StatusBar_HealthIcon
{
	rect 200 448 24 24
	image "models/players/mynx/icon_pm.tga"
}

As you can imagine, this is just a small snippet.

This whole thing is called the “SuperHud” system. They even developed a HUD editor for creating new HUDs in a comfortable way. This system allows you to alter stylistic parts of the HUD elements, like position, size, image, font, background etc. This file would not control which elements are actually shown, as you would still configure this by settings such as “showfps”, or using similar variables. This system should only alter the style of the elements if they are shown. Elements that are not contained in this HUD config file would be displayed using a default (hardcoded) style. Anyways, I think that Nexuiz could actually use such a system as well.

Oh, and to be complete, a way how something could work for a player who wants to load a new HUD (just an example console command):

set sbar_hudfile "myhud.cfg"
loadhud

The goal is to get away from hardcoded HUD styles that require a modified csprogs.dat file, but instead allow normal players to alter their HUD. Some advanced users or developers could create a few more HUD config files and let the players choose which they like best. The way of doing this doesn't necessarily have to be the SuperHUD system and its syntax. It could also be done altogether by using a lot of new cvars, probably even introducing a complete namespace like ui_xyz variables. The problem with the SuperHUD system is that we would need a proper parsing mechanism for the configuration file first – but maybe the developers of CPMA or Q4Max can help us out with portions of their code, we'll see.

Regardless of what you think about the previous suggestions, regardless of what you think how much configurable such a system should be, the following chapter lists all HUD elements that came into my mind, including the options that make sense to be configurable. Feel free to comment the items or add new items. With this list, you'll get a list of ideas of what could be done. This will help CSQC developers who are looking for new ideas for the HUD, and might also help UI designers to find out which elements exist when they create new UIs.

Also keep in mind that, right now, this list was created without really knowing anything about CSQC yet.

One important note: when the following list mentions a color to be configurable, the user should be meant to be able to specify the four values R, G, B and A (alpha), and not just R, G, B.

• HP Symbol (static image), configurable Position, size and visibility (alpha). Configurable (but optional) alternative image (if not configured, use the default image)
• Armor Symbol (static image), configurable Position, size and visibility. Configurable (but optional) alternative image (if not configured, use the default image)
• Ammo-Type Symbol (static image), configurable Position, size and visibility. Configurable (but optional) alternative images for the different ammo types (if not configured, use the default images)
• HP/Armor/Ammo value: configurable Position, style (font), size and visibility. Apart from that, add 3 customizable areas (one for HP, Armor, Ammo each). Areas are e.g. Low, Medium, Good, allow color definition for each area, e.g. red, gray, green, and the values, e.g. low=0-40, medium=41-100, good>100, that will define which area is used for the current value (e.g. HP). Example: if you have 25 HP, your will be in the low area. If you defined the low area to be colored red, your “25” will be colored red.
  Side note: the HP/armor/ammo value would need to be drawn on top of possible bars (see next point) so that they are always visible
• NEW: Status-Bars for health, armor or ammo.
  • Configurable start and end position and the values assigned to it. e.g. StartPos = “200 400”, EndX = “300 340” (x/y coordinates), StartValue = 0, EndValue = 200 → Would be a health bar which is completely filled if you have >= 200 HP and would be a rectangle with top left coordinate “200 400” and a bottom right coordinate of “300 340”. This allows the user to have health bars that go from left to right and vice versa.
  • Configurable color (I don't think we need “areas”, like presented above for the hp/armor values, a single color should suffice)
• NEW: If the characteristics of a weapon (which is usually just the ammo count) are more complex, these additional elements need to be shown as well. Example: the camping rifle magazine status
• NEW: display of your available weapons:
  • Only list weapons that you actually have, not all existing weapons (if you have laser gun or hook gun, also list them)
  • if you have a weapon, show it in the list, including its ammo
  • If you have the weapon but lack ammo, cross the weapon, or gray it out (needs a good idea of how to visually represent this state)
  • Each weapon needs a small identifying 2D symbol (just as Q3 has one for each weapon)
  • Configurable options are:
    • selection mode between horizontal or vertical layout
    • symbols right or left to the ammo-count-text (when layout is set to vertical), which of course also means “symbols above or below the ammo-count-text” (when layout is set to horizontal)
    • overall position, style (font, background) of each weapon „cell“
    • highlight color or image of the cell of the currently selected weapon
    • size of each weapon cell, margin of the cells to each other
    • configurable font style and size of the font
    • idea: one could also add the percentage value (hit shots %) to that weapon bar. That could especially be good when being an observer

• NEW: STRENGTH (Q3: QUAD) countdown timer display. Only shown to the player who actually has it (or to spectators/observers who spectate the player who has it) and only during the moment of possession
  • Symbol (static image), configurable Position and visibility
  • remaining time (in seconds): configurable Position, style (font), size and visibility
• NEW: same as above, but for the SHIELD
• Map-Timer: configurable Position, style (font), size, counting-down/counting-up
• new Idea: Separation of actual kill-messages (like “xx was vaporized by zz”) displayed on top of the screen (notify area) from other stuff (like „xxx drew first blood“). The idea: Display kills at another, customizable position, use the 2 names (attacker, victim) and a symbol that displays how the victim was killed. The symbol could be the one of the weapon that was used for killing, or another symbol if the victim committed suicide.
• Frag message (the one that is centerprinted until now): configurable position, style, size and visibility
• Ready-nagger (“press xx to end warmup”):
  • Configurable option whether element is static text or dynamic text, e.g. blinking text (setup how long it is shown and how long the break is, setup a fading time that makes it look neat).
  • Configurable option whether this element disappears after readying up or whether it stays and shows the „waiting for others to ready up“ instead. Apart from that of course configurable position, size, style, visibility
• Vote-nagger:
  • configurable font, size, visibility
  • NEW: configuration whether to hide the the vote nagger/information after you voted
  • configuration whether a countdown for that vote is shown
  • configuration whether the yes/no count is displayed
• Flag icons:
  • Configurable position, size and visibility of the (CTF) flag icons, ability to specify alternative flag icon sets
  • NEW: Due to the fact that the client knows the situation of the two flags and the client knows his teams, this allows CSQC to do things like showing a “flag stolen” centerprint, or play a alarm sound for the duration of your flag missing, or similar things.
• Keyhunt key icons: optional alternative image, configurable position, size, visibility of the icons
• Target under your crosshair: I am not sure whether this is still done with centerprints and basically a “faked” clientside setting. If it is, convert it to a real csqc setting. About configurable settings: font, position, size, color should be configurable
• When observing a player there are several lines, one that says who you are observing, one that explains what to press to cycle through the players and so on. For each of these lines there should be a configurable position, style (font), size, visibility
• general events that are (still) presented via “old” centerprint: these centerprints need configurable position, style, size, visibility
• TODO: look for other events/notices in the different game modes that are particularly created for individual players and, very often, presented via centerprint, such as:
  • Minstagib: Countdown when you are about to die due to “no ammo”
  • Minstagib: Show the number of extra lifes left (only if you picked up the powerup that adds extra lifes)

• Radar: Can already be positioned. However, maybe allow more options, such as a X Y coordinate
• mini-scoreboard: make it configurable (the one right now is static)
  • in DM mode: configuration how many slots shall be shown (the slots show the best x players, one slot per player. Minimum is 2 slots. E.g. if setting is 3, the best 3 ranked players (ranking is already configurable) are listed. All other players are NOT listed.
  • in team based modes: find out which teams exist and create a slot for each team automatically. Number-of-slots-setting from above will be ignored
  • in team based modes: configure what number is shown, e.g. score, frags, caps, ...
  • configure whether slot contains only player/team name, only frag/cap number, or both
  • configure the width of the player/team name column and the number column
  • in case that your own team (in DM: yourself) is in one of the slots, highlight your slot so that you can identify it easier (needed especially when option above is used, where team/player number is omitted). Needs configurable highlight color, or image.
  • configurable position, size, style (font)
• NEW: team overlay: when playing a team based game mode, show an overlay that lists the name, HP, weapon(icon) and position/location (if defined by map) of all members of your team. As, e.g. on FFA servers, the teams could be huge, only take the first x players (e.g. sorted by ID) of your team into account.
  • Configurable column width for the location and player names (too long player names or location names will be cut off)
  • configurable position, background color, visibility
• „game currently in warmup stage“ notice: configurable position, style (font), size, visibility
• NEW: show the number of players of each team. Configurable position, style (font), size, visibility

• showdate/speed/sound/fps/netgraph/pause: position, visibility (I'm not sure about the size of these elements, maybe the style (font) should be configurable where applicable)
• The position of the chat box should be configurable, e.g. specify a bounding box and the position of that bounding box. The user would have to keep in mind to keep the bounding box, con_chatwidth and the number of chatlines-setting (con_chat) in sync.

First of all, I guess that modifying the style of the scoreboard is absolutely not trivial. However, the following lists a few elements that could be shown in the HUD as well (they do not necessarily have to be configurable). Feel free to add more items to the list, or add comments to the existing items!

• Get rid of the “one string” solution that lists played map and the condition when the map ends. Instead list the elements at fitting places around/in the scoreboard itself (have a look at -z-'s HUD mockup for example)
• Server name
• Limits like capture limit frag limit, timelimit
• Map name
• last fastest cap?
• Ready-Symbol if a player is ready
• Small Key symbol if player has the key
• Small Flag symbol if a player has the flag in CTF
• For DUEL games only: a mode where the scoreboard lists the two players in a horizontal layout rather than in a vertical layout. This means that one player is on the left side of the scoreboard, one player is on the right side. The reason is that weapon stats could be shown in a direct comparison for both players.

Other thoughts and ideas that have more or less to do with the HUD:

• In case of using SuperHUD, for static graphics use ONE unified class, e.g. „image“ and just set its position, size and visibility and the actual TGA file. This would allow to add graphical background/foreground elements that support the HUD structure. An additional element could be the z-coordinate to allow graphics to be in front of other elements (example: a frame around the radar, a background graphic behind a quad timer, etc.)
• In case of using SuperHUD: Configure different styles for the HUD elements for different situations. This could be useful for example if you want a special element in the HUD to be visible (or, well, with another style preference) only when spectating a DM match, and other elements visible when playing in a TDM match, or other elements when spectating a TDM match.
  • game mode specific:
    • DM
    • Team based: TDM/CTF/DOM/KeyHunt ...
  • Spectator/Observer/Player specific:
    • Spectator, Observer or player DM
    • Spectator, Observer or player Team based
  • Basically this would mean that a style-definition of an element is either for “all” gametypes – or when the “gametype” setting is set to DM or TEAM is specified, only applies to this gamemode only. Then there could be another different setting like “specmode” which could be set to PLAYER (means that this configuration is only applied to the element if you are playing), OBSERVER or SPECTATOR.
  • An alternative solution could be e.g. to specify the hud file “myhud” to be loaded, while in reality you place the elements you want to configure in ALL gamemodes and situaitons in myhud.cfg, and for specific game mode or observer/player situations you place them in myhud_team_player.cfg or myhud_team_observer.cfg and so on.
  • Of course this solution is very “complicated”. A simpler way would be to have different HUD configuration files that you simply execute depending on the situation. E.g. you could have a Observer HUD config and a player config and other configs that depend on the gamemode you are currently playing (or observing) and each time you go to another gamemode/server or switch between playing and observing or spectating, you execute different HUD configs.
• When you spectate someone, make sure that you see the csqc-controlled events that he sees, e.g. the centered frag message, the „CTF flag stolen“ or other events that would otherwise have been generated/sent to this specific player
  • TODO: Create a list of applicable events (once the list above is complete), as not all events should be sent to the spectator (e.g. the ready-up nagger: the spectated player sees it, but the spectator should not see it)
• Evaluate: Item timers for Strength and Shield and Megahealth (I mean timers that show when the item will spawn again) (only for the spectators/observers). Unclear: What about item timers for items like big armors for the spectator? Is that possible at all (with armors, as there are usually more than 1 armor item)? How to name the armors in the list? Do they already get location names from the map?
• What about the z-level of all the HUD elements? Should we be able to define it for each element? This has effects especially on elements that work with visibility(alpha) values and are drawn on top of each other. Another way to realize this would be that the order of definition in the HUD configuration file defines the z-level.