On the status of this project (no longer maintained)

[Pixellore]

It would be really nice to see this package updated using the latest Entities version 1.0.11

Any chance?

The current package does not work and produces many package dependency errors when imported into Unity using Entities 1.0.11

[reeseschultz]

I will not update this project again. As I mentioned in #95:

this project has run its course; it suffers from architectural choices that impede user choice and future growth.

So, my advice to anyone who would try updating one of the navigation packages, is to instead start from scratch and build for a specific use case. There are numerous reasons for this. Here are some:

• The runtime component change workflow, while convenient for the user and fundamental to the package APIs, was never maximally performant because of the memory model that Unity has stuck with. I was wondering if Unity would migrate to an approach akin to entt or specs, but they didn't. That means runtime component changes must be jettisoned in favor of enabling/disabling components. The ability to do that did not exist at the inception of this project.

• This project is a pain to maintain and use, because it's a monorepo. They are just as unwieldy to maintainers as they are to users, especially in an ecosystem where there is no native support for them. This project's flagrant disregard for Unix philosophy has accomplished nothing but confusion. At least in the Node and Python worlds, there is tooling for monorepos. There is no equivalent in Unity world. No conventions for version management either. And to my knowledge, Unity never added support for third-party packages to depend on other third-party packages, which is really kind of not awesome.

• The jumping and physics stuff should have never been introduced into this project (via the nav package), and it should not be supported at all. The path package came later, stripping that stuff away, giving users the control they need to handle complex situations, but at the same time, it did not provide a good-enough default. Also, the aforementioned bells and whistles would need to be reconciled with stand-alone tweening and physics modules, if done as a generic solution.

• Architecturally, Unity ECS is great for performance, but the developer experience leaves too much to be desired. First of all, there needs to be an event-driven, user-friendly API built atop DOTS for usability and maintainability. Even if polling is happening under the hood, it needs to be concealed from devs so they can focus on what's important (the game logic). Second, there are still too many gaps in the DOTS toolchain to accomplish anything nontrivial without the time/resources to fill those gaps. I would characterize the Entities package as indie-unfriendly for that reason alone. When you really get into game development with Unity, you discover that the gaps for MonoBehaviours/GameObjects are enormous, even provided an entire asset store with thousands of products supporting that paradigm. There is little comparable support for Entities.

I'll archive this project soon. Still, I want to say that I'm enormously appreciative of everyone who showed interest and helped with it.