WarFrontIO / client

Real-time strategy game played in the browser
https://dev.warfront.io
MIT License
22 stars 6 forks source link

HUD System #6

Closed esk33 closed 1 month ago

esk33 commented 4 months ago

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.

esk33 commented 4 months ago

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

esk33 commented 4 months ago

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 commented 4 months ago

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

esk33 commented 4 months ago

Yes I will do that

esk33 commented 4 months ago

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 commented 4 months ago

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

esk33 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

Okay, I'll rewrite soon™

esk33 commented 3 months ago

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 commented 3 months ago

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

GDuath commented 3 months ago

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:

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 commented 3 months ago
  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 commented 1 month ago

Superseded by ae17c5b