-
-
Notifications
You must be signed in to change notification settings - Fork 553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bouncing indicator [bounty: 2 XTR] #2451
Comments
I've mentioned it in passing before, so I hope this isn't unwelcome. Maybe it's worth broadening the discussion here. It seems to me that these kinds of issues stem from the underlying programming paradigm used throughout the codebase:
Note that creature has to get a method call for the changes. And if it hears the first
This is an inherently complicated pattern. "Teach a person to program, they'll create a bug. Teach a person to sync up state, and they'll have bugs for life." In contrast, a more typical game loop might look like:
Or a reactive data store might look like:
In the second and third examples, there's no need to explicitly tell the creature about the state change. In example 2, But the current codebase is mostly like example 1. It's far from a full solution for the codebase, but fwiw, on my local, I've been poking at I haven't finished unraveling everything going on in
If abilities need logic to distinguish between important/unimportant mouseovers and clicks – e.g., the mouse is in the allowed movement range of the active creature – then they should bring that, either themselves or by invoking a separate system. Creatures could in turn watch something like Anyway, just some ideas. |
So, with all of the above laid out, where do we go? I've been working on making parts of the codebase less reliant on state – e.g. removing state from But I wonder if a bigger shift is in order. Thoughts? |
Can have an easier fix at first with a "// TODO" around. I wouldn't mind a data store via Vue.js or so in the long run. |
Sure thing. What do we do for a fix? My preference for fixing this is not to fix it, but to remove the bounce. That way, at least it doesn't get into an inconsistent state. It can be put back in when the underlying system is less brittle. RationaleFor fixes, I've mostly been going along with what's already in place, but fixes involving If we apply a fix over in hotkeys, we're just making it more tightly coupled to Note that the
|
I get it, but would rather have the feature as it is with some inconsistencies here in there...
Hmm, was expecting things like that to happen tbh, considering how things are currently coded. Feel free to open new issue for it. |
Ok. The on-the-ground problem here is that UI is changing and bits of the UI aren't getting notified of the change. For example:
Just code itSo a "just code it" solution could be:
It's just a few lines of extra code. It's a little hacky though. Down the line ... ?A more comprehensive solution might be something like a stack of |
Sounds good. There's always as struggle between hacky fixes and proper fixes. A lot of the code will get revamped down the line and to be honest, players don't really care about the underlying coding, but about features and functionality (provided stuff is not buggy as hell). |
The curve that technical debt follows means that hacky changes initially move fast. But as the technical debt builds up, things slow down because the codebase becomes fragile and hard to understand. Past a certain threshold, it means more bugs, fewer bugfixes, and fewer features: the things that players care about. |
True, I'm aware. But we'll need to make sure to have a nice enough balance in the bigger image of things :) |
For me anyway, the codebase is past the tipping point on tech debt. It's hard to fix bugs. It's easy to make new ones. That's not uncommon, especially for older JS projects. But I don't see how to move the project forward with new features before things get ironed out. That's why I've been focused on refactoring. |
Yeah, I totally get it. Codebase already looking way better atm 👍🏻 |
Hovering over active Dark Priest, pressing R and then materializing a unit somewhere will have the health/plasma indicator still bouncing.
The text was updated successfully, but these errors were encountered: