HUD System

[esk33]

A system for implementing HUD elements. Most details of how it works can be found in the included documentation file (./src/hud/HUD.md)

Please don't merge yet, could use review, polishing, and example implementation. Let me know what you think.

[platz1de]

In the future this should probably be merged with the normal ui system (they mostly differ in how positioning works, ui elements could also need the extra control)

[esk33]

Will change spawn() and destroy() to show() and hide() to reflect the change

[esk33]

I think it should be all good now, I'll do some testing and double-checking later today when I have more spare time.

[platz1de]

documentation needs to be updated to mention show/hide instead of spawn, rest looks good

[esk33]

Yes I will do that

[esk33]

Making some last changes, adding a HudManager.ts file for initializing HUD elements.

It looks something like this:

import ExampleElement from "./elements/ExampleElement";

export function initHudElements() {
	new ExampleElement();
}

All HUD elements should have their constructors called here. initHudElements() is called in Loader.ts. The element's constructor should assume it is being called when the game is first loaded.

Registering elements could potentially be automated during the build process.

[esk33]

That should be all. Would be nice to implement some basic game stuff using the system to see it in action :-)

[platz1de]

ui elements shouldn't listen to global events

[esk33]

Yeah, this was just for the sake of the example. Probably shouldn't have committed it.

[platz1de]

The element won't be able to become hidden as the instance isn't saved

[platz1de]

Elements shouldn't decide their own position

[platz1de]

Let's not create a long list of class constructors

[platz1de]

ui elements are pretty much always fixed and will never be shifted around, having three methods for that is overkill

[esk33]

In regards to

The element won't be able to become hidden as the instance isn't saved

and

Elements shouldn't decide their own position

I think you and I have different ideas of how ui elements should behave. The way I've designed it is that the bulk of the element's logic is handled within the element class itself, hence no need to save the instance as all necessary functionality is setup in the constructor. Operations exclusive to the element should generally be handled by the element. I do, however, admit not saving the instance is not a good design choice.

[platz1de]

Only very simple actions should directly be handled by the element (e.g. a timer). But pretty much every element i can think of requires information of other game objects to work correctly, this info should be directly sent to the element and not need to be requested every tick (e.g. chat messages get pushed to the element by network handlers, we don't want to store those for a tick just for the chat element to request them a tick too late)

[esk33]

Okay, I'll rewrite soon™

[esk33]

Hi, if anyone reading this is willing to help with this PR, that would be great. I'm still really busy with schoolwork and still don't have much time to work on this, otherwise it will just have to wait another few weeks for me to find sufficient time for it.

[GDuath]

I can try, but I guess I'll need a day or two to really get into the depths of this.

[GDuath]

Okay, I've carefully reviewed the code, but I do have some remarks before continuing with this, so hopefully @theotherhades can shed some light on the matter:

• The HUD elements and their class methods are centered around absolute positioning, however, I hardly see any application for that. Almost all UI elements that I can think of will be within layout containers that will do the responsive adjustment of size and position for them. There might be a very small number of HUD elements that could potentially be absolutely positioned (like tooltips or radial menus), but the necessary positioning can be done in the current UI module code as well.
• UI modules can't be instantiated like HUD elements, but I've failed to come up with an example for an element that would need to have more than one instance on the screen. Am I missing an idea there?

All in all I'm wondering right now if the scope of HUD elements is maybe a bit too narrow to warrant the time of full-scale implementation, but I'm ready to be convinced otherwise 😄

[esk33]

1. I didn't really have layout containers in mind when writing that. The HudElement class was supposed to be a lower level class and thus the fine grained control of a coordinate-based placement system was all that was necessary.
2. UI modules are kind of confusingly named- they behave moreso as "pages" than "modules." HudElements were intended to serve as individual components of a UI (in this specific case, the HUD). Things like the leaderboard, chat panel, attack bar, etc. They were instantiated at first but that idea has been scrapped for reasons that have already been discussed. This PR probably needs to be part of a more general "UI System" PR in which the scope of "UI modules" (which should be renamed to "pages" or something along that line), "HUD Elements," and anything else relevant that I haven't covered is defined.

[platz1de]

Superseded by ae17c5b