reeseschultz
commented
3 years ago Closing due to the package being added as of a75cbbd89df265601ef032a8bff7b566c8b15a9f. :partying_face:
Closed reeseschultz closed 3 years ago
reeseschultz
commented
3 years ago Closing due to the package being added as of a75cbbd89df265601ef032a8bff7b566c8b15a9f. :partying_face:
Is the improvement related to a problem? Please describe.
Oh, yes indeed. Again and again, either through issues or by contacting me directly, users have lamented they don't need most of the features in the navigation package. It usually has multiple features they don't want. With most libraries this wouldn't be a problem, but it is here because users are being forced to conduct processing they may not need, or at the very least they may want to otherwise specially handle something. (For anyone reading, do note that the navigation package does enable custom lerping.) Now, in the navigation package's defense, it amortizes its use of raycasting for surface detection and obstacle avoidance with a stateless(!) physics library nonetheless.
Still, all in all, I have reason to believe a separate, stripped-down fork of the nav package will greatly take pressure off me as the maintainer, because, when the pathing package is released, users can do whatever they want with it, and they're no longer required to process anything irrelevant to them. If they disagree about some way the navigation package handles something, they can do it themselves without having to reinvent the pointer-based hack I've used to smuggle NavMeshQueries into jobs.
Describe the solution you'd prefer:
To discuss a solution I'd prefer, I need to go on a long diatribe about the state of the Entities package. I'm honestly concerned about it for multiple reasons, notably for its lack of compatibility with 2021.1. I'm not going to mince words: Unity's messaging (or lack thereof) leaves much to be desired. Here's the most telling comment, made yesterday, by Laurent Gibert regarding DOTS audio (he's a senior product manager at Unity):
(To be clear, I am not employed by Unity; I'm just a user who made some open source software with their engine.)
When Laurent says "clarify what went wrong," I think this extends beyond the audio package. This obviously has to do with the Entities package upon which DOTS audio is intended to interoperate. Development started on the audio package a couple years ago, and just kind of fell off. There's an (un)official DOTS audio solution called Myri for those interested, but, uh, what exactly is going on at Unity? Relatedly, where is the official DOTS navigation? Why have there been no updates for it? I naively believed that Unity would have offered an ample replacement to my navigation package by now, so I didn't originally intend on maintaining it much at all this year. Maybe Unity should sponsor open source developers like me who are maintaining stopgaps for their proprietary engine in the meantime.
What's more mystifying is that Burst and Jobs, 2/3 of the DOTS pillars, have worked great for a long time. Burst still sees a lot of fixes in the changelogs, but, hey, it generally works like a charm. This brings me to my desire to create a pathing solution without Entities, using only Burst and Jobs, but it would require major architectural changes. Plus, I think most of my users still want to use Entities. ECS as a pattern is glorious, but Unity's implementation seems to be buckling under disparate use cases it didn't initially account for. It makes me wonder if there is some alternative or abstraction being developed to rectify the situation that we don't know about yet; I have no idea.
Anyway, I'll literally fork the navigation package for the pathing one, strip it down, and I'll continue to use Entities, but I'm wary as a maintainer. I would personally prefer only using Burst and Jobs, but I will continue using Entities for the sake of the users. If issues arise in the future because of this choice, I won't be keen on hearing complaints.
Describe alternatives or workarounds you've considered:
I could try to add a bunch of options and settings to the existing nav package, but that seems much more painful than just forking it into a new package. The flow for how components get passed around will be slightly different, I think, so it's more trouble than it's worth.